When pairing dialog is dismissed using the back gesture, we do not call
cancelBondProcess() for the remote device. Since bonding is not
cancelled and the dialog is dismissed, when the user tries to pair again
and scans for devices, nothing shows up. This is because in case of a
pending bond or pending SDP, the request to search for new devices is
queued.
The correct behavior is to cancel bonding if the pairing dialog is
dismissed using the back gesture. This is similar to what
happens when the pairing dialog is dismissed using the cancel button.
Bug: 231554812
Test: Changed settings app is able to scan after dismissing the dialog
Change-Id: Ia790e345be811be1b60762ff819544d03c5a18fd
Merged-In: Ia790e345be811be1b60762ff819544d03c5a18fd
When pairing dialog is dismissed using the back gesture, we do not call
cancelBondProcess() for the remote device. Since bonding is not
cancelled and the dialog is dismissed, when the user tries to pair again
and scans for devices, nothing shows up. This is because in case of a
pending bond or pending SDP, the request to search for new devices is
queued.
The correct behavior is to cancel bonding if the pairing dialog is
dismissed using the back gesture. This is similar to what
happens when the pairing dialog is dismissed using the cancel button.
Bug: 231554812
Test: Changed settings app is able to scan after dismissing the dialog
Change-Id: Ia790e345be811be1b60762ff819544d03c5a18fd
If there is the active esim slot in SS mode, the settings should
reuse it and does not change the sim slot mapping.
Bug: 229803628
Test: manually test.
Change-Id: I6daa38f54abfaf67c7640d9dc8be0da02eb59554
Prior to this cl, we allow user to tap on those
setting items which belong to another user profile app.
However, we already observed some functional broken cases now.
Such as, device can't get the storage data/screen time/mobile data
battery, notification for those apps from another user profile.
Therefore, we decide to grey out those setting items,
and we don't allow user to tap on unsupported setting items.
Test: Download apk in different user profile, and see setting items
is disabled/enabled correctly. and run robo test.
Fix: 230303570
Change-Id: I1bb6b1d8b52f6a00088b2f0e4279b896d568f8a6
Root Cause: Change design in Android T to show left-side and right-side
in one summary line.
Bug: 224323976
Test: manual test
Change-Id: Ia43b491d571787d356240593b221d6fe8dd1453c
FooterPreference doesn't support linkify in order to have better
accessibility. So we need to separate original 1 Footer into 2 Footers
in Fingerprint settings.
Bug: 230625178
Test: test fingerprint setting footer links with admin mode or non-admin
mode
Change-Id: I07263a1faaf7dddf79ba96dd9fcb4fce4cf8981b
Screen update been requested while querying data usage and response not
yet available.
This change tried to avoid from updating the UI in this case.
Bug: 210664126
Test: local
Merged-In: Id055fbd441936a9842b4acc978a894a855165bb7
Change-Id: Ia57f831d78b12754d60f920a9dbe057400dc4ce2
This is caused by I7175c966fbbfbf5d6331f5ac26c06b60d59a4e0d.
updateList() should be called in updateState() to refresh the latest
app status.
Fix: 231113758
Test: manual visual test
Change-Id: I9dc082c829020841ccd76bc4787855c8301f1154
- Currently per app language use opt-out by default. This change is to
add a new idea to have a way to change opt-out to opt-in, and let
user be able to use LocaleConfig.xml to control the feature more
precise.
- If app does not support locale picker or there is no locale provided, remove entries' UI.
Bug: b/231396734
Bug: b/230688538
Test: local
Change-Id: I2661fffab804a2816744711130b26aa2ec47f820
The injection dynamic data was loaded in the background and then post to
main thread to update UI. However, it usually updates after
Fragement.onResume(), which causes the flicker.
To make it more smooth, DashboardFragment to wait for the dynamic data
observers to update UI for a short period, which eliminates the flicker
in most cases.
Also skip the repeated tiles refresh called by onCategoriesChanged in
onResume after all preferences refreshed.
Test: robotest, visual
Bug: 229177114
Change-Id: I04650af9692703f1fc1e6e5ad2090f051b1eeb81
RouteInfo has several status values, such as unavailable status. But according to current logic, unavailable status will be displayed as connnected. it is not reasonable.
Update and optimize the route preference summary with the real WFD status value.
Change-Id: Iacd10e0133d06ef0b86da38cf763fe7def6ed7de
Buganizer: 231656030
Force use the system package for the SYSTEM_UID, since the SYSTEM_UID is
used for multiple packages. The getPackageWithHighestDrain() method may
get different packages to represent it, since it will use the highest
battery drain to represent the SYSTEM_UID if there are multiple packages
use the same UID value to make users confuse about the usage data.
_
$ adb shell pm list packages --uid 1000
package:android uid:1000
package:com.android.dynsystem uid:1000
package:com.android.frameworks.core.batterystatsviewer uid:1000
package:com.android.inputdevices uid:1000
package:com.android.keychain uid:1000
package:com.android.localtransport uid:1000
package:com.android.location.fused uid:1000
package:com.android.providers.settings uid:1000
package:com.android.server.telecom uid:1000
package:com.android.settings uid:1000
package:com.android.wallpaperbackup uid:1000
Bug: 202682426
Test: make RunSettingsRoboTests -j56 ROBOTEST_FILTER="com.android.settings.fuelgauge"
Change-Id: I447bfa1b32037763a2194c0639abcc334c7d8b78
