This does the following:
Simply opening Settings > Multiuser no longer
globally enables multiuser. The user would have
to actively toggle that switch to globally
enabled it.
(This reverts ag/7002640; a different solution for
that cl's bug is in the same topic as this cl.)
Bug: 137943217
Bug: 141372193
Bug: 149973281
Bug: 130270878
Test: manual: Settings > Multiuser doesn't turn on the systemui avatar
Test: manual: adb shell pm create-user A, does turn on sysui avatar
Change-Id: Ibfdd1dee408c7214d0a097c8d814dae87ffa82ac
API provided by SwitchBar widget would lead to callback when
SIM toggle switch operation failure and set UI back.
However, set UI back (rollback the UI) would lead to another
trigger to SIM toggle switch. This would generate endless
events and keep system budy.
To avoid from this callback, a check need to be done prior to UI
take action. Therefore, changing APIs to fit into this concept.
Bug: 155770954
Test: make RunSettingsRoboTests -j ROBOTEST_FILTER=MobileNetworkSwitchControllerTest
Change-Id: Iaea1012acdbe449a882ced08b596c64b9f99256f
AppPicker used in devceloper options, it will show apps list with
package name in a dialog.
But sometimes it will mis-alignment with package name.
So we change theme from dialog to full screen and set widget_frame
visibility to GONE.
Bug: 151150544
Test: manual
Change-Id: I8f04ab7967288801e5e13ecccf037d6ed09ec71c
The sound panel and media panel are using the same window, so when it
transit from the sound panel to media panel, no window-change event will
be sent. Therefore, Talkback won't be able to re-focus the panel header
which lead to the lack of the announcement.
Fix this by adding setAccessibilityPanelTitle() to trigger Talkback.
Fixes: 140459762
Test: rebuild and test talkback on the media output panel.
Change-Id: I1442434315374dbbfe1d47ca8638180577c93168
Bug: 157102550
Test: Manually open the PIN toggle dialog and PIN edit dialog, then
remove SIM from DUT
Change-Id: Ied875909e9cbcb1cad1ae045578747a0a5810491
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
