We mixed both primary and work profile CA certs into single entry
previously which is not aligned with the CTS requirement.
Separate them from now.
Test: m -j RoboSettingsTest
Test: Run related manual test in CtsVerifier
Bug: 64567417
Change-Id: Iaff2d9f25ef15b96c11727e7075bdae8e90ec8ce
Previously, DonutView used Canvas.drawText with a Paint with default
bidi directions, which is LTR. This meant that even in RTL locales,
text was displayed assuming the direction of the paragraph the text
was appearing in was LTR. This caused an incorrect display of Arabic
percentages.
Now we set the Paint bidiFlags according to the Locale's direction.
Change-Id: Ic10228b8a23dc49de60246c37adfbaf7f8fd4e9e
Fixes: 63767043
Test: Manual (tested in ar-EG, ar-MA, fa-IR, ur-PK, and he-IL locales)
When the user enters a wrong pattern/pin/password, a "Wrong
pattern/pin/password" text shows up on ConfirmLockPattern or
ConfirmLockPassword screen. In ConfirmLockPassword, it disappears
automatically after 3 seconds, whereas it doesn't in ConfirmLockPattern.
In this change, we make the prompt in ConfirmLockPattern disappear
automatically as well.
Bug: 64781905
Test: manual
Test: make RunSettingsRoboTests
Change-Id: I53a25576413671ced4197064d51fbcc397733265
BluetoothPairingDialogFragment has code that makes the OK button on the
dialog disabled until the user has entered at least one character into
the PIN field. However it didn't properly handle the case where the user
had entered some text and then rotated the screen - because it always
marked the OK button as disabled during onShow even if it already had
some content. This CL fixes that by looking at the text content and only
disabling the OK button if the content is empty.
Bug: 36514895
Test: make RunSettingsRoboTests
Change-Id: I4e8e70089a862e67b20ff614bbaa64fc2b641fd4
The source string was removed but there are still references to it.
Updating the references as well in this CL.
Test: mma with ANDROID_AAPT_IGNORE on locale files
Bug: 64763091
Change-Id: I43ef63207e884cbaa92ff3853b0f1fd690cf05f8
When ChooseLockGeneric is recreated, don't automatically launch
ChooseLock[Password/Pattern] even if the corresponding intent extras
are specified, because one would have been launched in the previous
onCreate.
Test: Manual
Bug: 64605627
Change-Id: I227a14abb2f4dd6c4577186a3d8164df0bec7791
The preference controller shouldn't be shared between the
"Assist Gesture" parent setting, and the child setting within
Fixes: 64318213
Test: manual test of settings && make -j RunSettingsRoboTests
Change-Id: I2d2437e2036881a08977924dc1386aa1fab67070
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
FingerprintSettings should not start listening for fingerprints until
after Pin/Pattern/Pass is entered
Fixes: 63437524
Fixes: 63739006
Test: open FP settings, touch an invalid finger 5 times
close FP settings, re-enter FP settings, enter Pin/Pattern/Pass
touch FP with valid finger, should not be in lockout mode
Change-Id: Ia2e219824c33169a5610b36123c42aa3d6ff22c5
Convert input device search into a search query loader
And remove old logic from DynamicIndexableContentMonitor
Change-Id: If652b1ea7c8add9185bbd025055e14925d3a8eec
Bug: 64310452
Bug: 63831980
Test: robotests
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
- After the user finished adding lock screen, if the user tries to skip
fingerprint setup, show a confirmation dialog
bug: 64092225
Test: Manually tested; robolectric tests also added
Change-Id: Iba5088a9db93153988942cf78f11077f427e50cb
