When strong auth (PIN, password, or pattern) is removed from a user,
fingerprints enrolled for that user should also be removed. Then, if the
user has a work profile guarded by a unified work challenge, the work
profile's fingerprints should also be removed.
Previously, when removing the fingerprints of the current user,
ChooseLockGeneric checked the finger id of the onRemovalSucceeded() and
onRemovalError() callbacks, and assumed the removal had completed when
the id was 0. Only after this would it initiate the removal of work
profile fingerprints, if any.
However, the finger id is actually non-zero even for the user's last
fingerprint. This means the work profile fingerprints (under unified
challenge) were never removed. Another more visible symptom was that
when the user removed the device lock by choosing "None" or "Swipe" in
ChooseLockGeneric, the activity failed to exit, since finish() is called
only at the end of the removal flow which was not executed.
In this CL, we check the number of remaining fingerprints instead of
relying on the finger id, thus allowing the removal flow to complete and
the activity to finish().
Bug: 37938345
Test: manual, both with and without work profile
Test: make SettingsRoboTests
Change-Id: Ic04fd01177ad6d4a061023a4b6889af585f8f2b7
Adding a title to contentDesciption of the seekbar.
The title is helpful to indicate which seekbar user is changing when
talkback is enabled.
Also move SeekBarPreference from root package to widget packge.
Change-Id: I793f41c4902e350b6bc6d62761362779cc3722a9
Fix: 35421942
Test: make RunSettingsRoboTests
Secondary users could not see the support preference in the
settings home screen because it was missing from the list of
whitelisted activities. This CL adds the SupportDashboardActivity
to the list so that secondary users can see it.
Test: Robotests still pass for SettingsGateway
Change-Id: Ia48dbd5b8d396c1bdf050c102fee0a5cd5300ed2
Apparently in cursor loaders you don't need to manually close
the cursor because it does it for you at the end. doing so can
also cause crashes on device configuration changes since it
will call the method again with the same cursor.
Test: robotests still pass
Bug: 38208727
Change-Id: I285e56546daf726e74b903856b17dc034d6fd538
- Change all yes/no or on/off strings in special app access to
Allowed/Not allowed
- Remove some dead code in related files
- Add a toast string in DevelopmentSettingsDisabledActivity to prompt
user enable dev options before use.
- Add search in SpecialAccessSettings
Change-Id: I8b2535e037a86e76bdbcd3fb6e1cf2e0347bedbf
Fix: 38290299
Fix: 37469224
Test: make RunSettingsRoboTests
This preference lives in paired category. When clicked, it will
go to the pairing page.
Bug: 35877041
Test: RunSettingsRoboTests
Change-Id: I64706c49c8d303a494d4c1827e1f86b59effd54c
Sleep options are not relevant any more. This CL removes them from the
settings code.
Bug: 35994481
Test: make RunSettingsRoboTests
Change-Id: Ibd0b33ded3aa2da3df73c519611c915deed6310f
Consolidated the many variants of ChooseLock*.createIntent, so that
it will take the same set of arguments.
Also modified SetupChooseLock*.createIntent to modifyIntentForSetup,
which will take the intent created by ChooseLock* and modify it for
use with setup.
Test: cd tests/robotests && mma
Change-Id: I5ff033f459c33ec9980872a536b3996d89f2bbbb
