aosp/2093046 cancels bonding unconditionally in onDestroy(), this
results in the user not being able to pair when the pair button is
pressed because onDestroy() is also called in that case.
Only cancel bonding if the user did not press the pair button.
Bug: 231554812
Test: Changed settings app is able to scan after dismissing the dialog
and is also able to pair when the pair button is pressed
Change-Id: I868af9b795f1bb0766656e4619bd06dc8028008a
Merged-In: I868af9b795f1bb0766656e4619bd06dc8028008a
Hide the running time information for "Android System" entry, since this
entry will combine multiple system components together. It will provide
incorrect running time information. The getRealUid() method maps many
UIDs to Process.SYSTEM_UID(1000), which results in combining all of
those UIDs into one "Android System" entry. This is the expected behavior.
Bug: 220717612
Test: make RunSettingsRoboTests -j56 ROBOTEST_FILTER="com.android.settings.fuelgauge"
Change-Id: I9d44fe8490ad5c684419b8ebf8d7d5576a42788a
- Don't let device be discovered when the user launch "Connected Devices
settings" through SliceDeepLinkTrampoline.
Bug: 228450811
Test: make -j42 RunSettingsRoboTests and use test apk to manually test
to verify the device is not discoversable when open "Connected settings"
through test apk.
Change-Id: I5490b58675b1fd9fc36305766867f65caa6ccb6c
- Close blank layout after title disappear when search bar is expanded.
Bug: b/227287277
Test: local, see b/227287277#6
Change-Id: I1a61bab9a046aa52e22c4ef2292c7ae703deab1e
Hide some Preference which requires mobile data on device didn't support
it.
Bug: 221999174
Test: local
Change-Id: I7dd6e13aea0ed4467c7c7edeada564e42ea78349
In the past, Settings didn't support resetting the disable status of
work profile apps, it doesn’t follow the behavior that the reset dialog
mentioned.
To fix it, we are going to check apps by enabling user profiles and user
id. If the work profile is enabled, we will also reset them when users
select to reset app preferences.
Bug: 187387211
Test: manual
Change-Id: I25fd0129335539a23ed2ee0af57fdd9714eddf74
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
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
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
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
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
Some pages that extend ManageApplications always display a loading
spinner when entering them. This is caused by that it takes over
100 ms to load all apps and to sort the apps. In addition, the task of
loading all apps might be invoked twice, which caused loading time
increasing.
This CL is to make sure the task of loading all apps execute only once
in those pages that extend ManageApplications.
Bug: 222985623
Test: manual test
Change-Id: I3b15bf2eee2a4c220f42da39a29f0014cc620898
