When switching to a secondary user, Settings will disable all extra
categories that aren't configured in SETTINGS_FOR_RESTRICTED.
As the result, Default apps settings disappear.
To fix this issue, AdvancedAppsActivity class of Default apps settings
should be added to SETTINGS_FOR_RESTRICTED.
Fixes: 65616610
Test: manual - switch to a secondary user
and go to Settings > Apps & notifications.
Change-Id: Ie9f3b1d215e2e43bf25b8dd2971f86bd60e94d04
Enter into the fingerprint list screen and can authenticate fingerprint still when the list is empty.
Test: manual - enrolling some fingerprints and remove all fingerprintd, touch the fingerprint touch panel and no response.
Display "IMS registration state" in Status menu. Introduce carrier
config to enable/disable the feature for customization. Since some
carriers require, this feature is necessary.
Test: manual Checked "IMS registration state" in Status menu
Bug: 28806101
Merged-In: I6c452c512f03cf41704b91331e44141ed3050cf9
Change-Id: I6c452c512f03cf41704b91331e44141ed3050cf9
Display "IMS registration state" in Status menu. Introduce carrier
config to enable/disable the feature for customization. Since some
carriers require, this feature is necessary.
Test: manual Checked "IMS registration state" in Status menu
Bug: 28806101
Merged-In: I6c452c512f03cf41704b91331e44141ed3050cf9
Change-Id: I6c452c512f03cf41704b91331e44141ed3050cf9
[Cause of Defect]
TrustedCredentialsSettings#mKeyChainConnectionByProfileId is get/set by
more than one thread. Main thread would set it in onDestroy method, and
AsyncTask would get and set in the doInBackground method. So
mKeyChainConnectionByProfileId.get(profileId) would get null after
onDestroy method get called.
Bug: N/A
Test: Debugger to simulate concurrency
Change-Id: I0664d1e9b88b079855354ce0e6fe014a98a22327
Signed-off-by: daqi <daqi@xiaomi.com>
Enter into the fingerprint list screen and delete and identification of operation at the same time, when the item of the fingerprint verification was deleted, highlighting the item to be deleted, just so NullPointerException occurred.
Test: manual - enrolling a fingerprint and do above steps.
It is possible in certain build configurations to have an invalid
link. Instead of crashing, swallow the error and write to logs.
Fixes: 64322876
Test: manual - go to Settings > Security & Location > Fingerprint
and then tap "Learn more"
Change-Id: I70beca880261df0ee3eef94f5469f44130ffd95a
Test: Manually added APN and verified read-only and non-wildcardable
types are not included
Bug: 38186417
Change-Id: I07bcf1c2a950a1257446f0a7beb602fed79423b3
When the media stream is set, initialize the preference max and progress
with the streams current value. Otherwise, when we initialize the seekbar
volumizer, it will first set the seekbar max to 0 and progress to 0,
then update with the correct value, which will result in the jank that
is seen when the sound settings are displayed.
Change-Id: I515c97bbc6ec38bbe92755e3d7cb53bb13ac52d0
Fix: 34035654
Test: make RunSettingsRoboTests
(cherry picked from commit b7490bea28)
There are two problems with the Bluetooth settings and pairing pages
that are fixed by this CL:
(1) We advertise on the page that the local device is visible to other
devices, but that only lasts for the length of the default timeout (120
seconds) for the local adapter being in discoverable mode.
(2) Both the BluetoothSettings and BluetoothPairingDetail fragments
enter discoverable mode in their onStart handler and exit it in their
onStop handler. Unfortunately when doing a fragment navigation the
onStart and onStop events interleave in a non-intuitive manner. When you
go from BluetoothSettings to BluetoothPairingDetail, we see the onStop
event for BluetoothSettings *after* the onStart event for
BluetoothPairingDetail, and similarly when going back from
BluetoothSettings to BluetoothPairingDetail. What this means in practice
is that if you go to the BluetoothSettings page, the device will be
discoverable, but once you navigate to BluetoothPairingDetail or back
again you won't be discoverable again until you go somewhere else or end
the settings activity.
This CL adds a new object called AlwaysDiscoverable which can be used to
start and stop a mode of "always being discoverable". While started, it
will listen for changes to the discoverable state, and return to
discoverable mode. This fixes (1) by returning to discoverable mode
whenever the normal timeout expires, and (2) similary by returning to
discoverable mode when we accidentally exit it due to the onStop/onStart
mismatch.
A better fix for (2) would be to avoid the "glitch" of briefly exiting
discoverable mode only to re-enter it, but the implementation of that is
a little more complicated so that's being left as future work in order
to keep this CL as small as possible.
Bug: 64130265
Test: make RunSettingsRoboTests
Change-Id: I559dd8187263ea6a0008be1a8abdfffac97cb87a
Add the main looper to the handler created with each
DataSaverBackend to avoid crashes when the objects are
created on background threads.
Bug: 62022517
Test: make RunSettingsRoboTests
Change-Id: I7396107e4ed06982c8cd300912ce1f4e3c63df4c
Merged-In: Ie5ffabbfbe7660761527b3ecd51e6bc5a43c1ace
