In several circumstances, the ConfirmDeviceCredentialActivity
may be started while the device is being unlocked - particularly, when
the managed profile on the device has a separate challenge and the user
is attempting to start an activity associated with the locked, managed
profile. For example, by double-tapping a notification from the managed
profile or trying to reply to such a notification.
When the ConfirmDeviceCredentialActivity is started after the user has
entered the primary lockscreen challenge but before the keyguard is
fully dismissed, the activity may be started and immediately paused.
If the activity then calls finish() in onPause(), the biometric prompt
will disappear and the user will not have a chance to authenticate.
Fix the issue by only calling finish() in onPause() if the biometric
prompt has not been shown.
The flag indicating whether the activity is waiting for biometric
prompt or not needs to be cleared whenever the biometric prompt invokes
the callback, so that the activity will correctly call finish() if the
user does abort authentication.
Bug: 153689182
Bug: 141470517
Test: Manual, set up a work profile and double-tap a work notification
or try to Reply to a work GMail notification.
Change-Id: I9d3d3000b99d0eb4b44b90f5a0c2856db5f32144
Root cause:
App info page will load application icon and content description in
onBindViewHolder(), it will query PackageManager and UserManager many
times in scrolling. Actually these actions will become time consuming if
there is a large app list.
Solution:
To relieve the janky scrolling, cache the icon and content description
if it has been loaded once.
Bug: 156527207
Test: manual test and robotests
Change-Id: I997179834511f86b3155c7d54989a873ac8e2559
- The "Google Account" item will launch the
AccountDetailDashboardFragment.
To launch the account detail page, we need the intent extras, account,
account label and account type.
- Currently, SI doesn't support to index the intent extras, so we launch
AccountDashboardFragment instead of AccountDetailDashboardFragment.
Fixes: 153626405
Test: manual test the search result and run Settings robotest
Change-Id: I081bd447c3f8422fb8859146b1ed4d7fcbc06810
WifiSettings2 should create a new WifiEntryPreference for a cached
WifiEntry key in case the underlying object has changed, so that updates
to the WifiEntry are still being listened to. This may happen
in situations where WifiPickerTracker swaps WifiEntries objects with the same
key in the getWifiEntries() list, such as when handling network
suggestions (which are kept as separate objects from the non-suggestion
entries).
Bug: 157174114
Test: manual visual verification in wifi picker of adding a network
suggestion and seeing the entry summary for that SSID change to the
suggestion summary.
Change-Id: I9cfdae8207ae919e9e1cbf4c200eaa951a229b3f
Merged-In: I48ac11364b06887cc4059bcda863b456e206c9bd
WifiSettings2 should create a new WifiEntryPreference for a cached
WifiEntry key in case the underlying object has changed, so that updates
to the WifiEntry are still being listened to. This may happen
in situations where WifiPickerTracker swaps WifiEntries objects with the same
key in the getWifiEntries() list, such as when handling network
suggestions (which are kept as separate objects from the non-suggestion
entries).
Bug: 157174114
Test: manual visual verification in wifi picker of adding a network
suggestion and seeing the entry summary for that SSID change to the
suggestion summary.
Change-Id: I48ac11364b06887cc4059bcda863b456e206c9bd
This reverts commit daf6c9e85b.
Reason for revert: Broken build 6513883 on aosp-master on errorprone
Change-Id: I5e473863c2669a3c89014e12cc952c5c72a12cb7
bug:157138919
