Position of cursor goes to the front when submit
an error pin.
Bug:https://issuetracker.google.com/issues/67839176
Test:
1) Insert a sim card
2) Go to Settings -> Security -> Set up SIM card lock
3) press Lock SIM card checkbox
4) enter 123 and press OK button
Change-Id: I90655f3fa4cb3e4bda251cd0fc62e66300a4b66f
Signed-off-by: tiansiming <tiansiming@xiaomi.com>
To show latest payment service list on Tap&pay menu.
Test: install payment service and go back to Tap&pay menu
Bug: 67718335
Change-Id: I6f421176b9c461898224b50d06f67a49645f0d18
Symptom:
After manually pull out the removable sd card or usb storage in
StorageSettings screen, it automatically moves to
PrivateVolumeSettings screen. This time, launching
PrivateVolumeSettings Activity is triggered six times and end-user
has to press back key six times to exit PrivateVolumeSettings
screen.
Root cause:
When sd card is pulled out, StorageSettings got three state change
event (UNMOUNTED, BAD_REMOVAL and onDiskDestroyed) through
StorageEventListener that triggers launching PrivateVolumeSettings
screen. In addition StorageSettings register the listener two
times, then StorageSettings receives six event in total.
Therefore, PrivateVolumeSettings screen is launched six times.
Solution:
Skip launching PrivateVolumeSettings if it's already triggered.
And removed the duplicated listener registration.
Bug: 67612903
Change-Id: Iabef51677a393977b7be29fc54aa050434213500
Comparisons changed on the intent action. Sometimes an account
preference intent does not have an action specified.
Fixes: 67075850
Test: manual - go to Settings > Users & accounts and tap an account.
Change-Id: I54cebbc983b55aa1487a122d37ccd5c79bbf519d
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
