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
There is another autofill service for work profile.
Make this preference unsearchable to avoid duplicate result.
Bug: 155838971
Test: manual
Change-Id: I7f614ead1c0f898964775c03e81f1102583b04dc
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
1. Enable airplane mode before start testing.
2. Reset airplane mode after testing.
3. Add all_results tag to track results we have.
4. Add result_count tag to track how many results we have.
5. Add shell command result details to log.
Test: atest SettingsPerfTests:LaunchSettingsTest
Change-Id: I24ed167599b660b2aa94b4a3f8ddae1dcf3d04ff
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
- 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
This reverts commit daf6c9e85b.
Reason for revert: Broken build 6513883 on aosp-master on errorprone
Change-Id: I5e473863c2669a3c89014e12cc952c5c72a12cb7
bug:157138919
