This happens when user has different accounts with same account name. For
example: user@domain.com for type1 and same email for type2, etc. When
we refresh the account list during onResume(), the same account name
incorrectly causes the logic to think they are the same account and
updates the account list by mistake.
- Introduced a util method to generate unique key from Account object.
And set it as preference key.
- when updating preference on screen, use key to find preference instead
of the preference instance itself.
Change-Id: I0aa692cb965b7037155a746389a919cd155843da
Fix: 34035653
Test: make RunSettingsRoboTests
Default UserManager caches instance across entire test suite, so
test becomes flakey depending on the order they are run. Using a
a ShadowUserManager without the cache ensures each test class gets
a UserManager with clean state.
Change-Id: Ia54f6a3259859add5a1e5d0101829497fb985ab1
Fix: 38393235
Test: make RunSettingsRoboTests
Cherry-pick of 436256c36d
Test: 1) make and run SettingsTests. It passes.
2) Manual test 1
a) On a device supports fingerprint, set a password but not fingerprint.
b) adb shell am start -a android.app.action.SET_NEW_PARENT_PROFILE_PASSWORD
c) Confirm Lock password screen is shown
d) Select "Skip fingerprint". There isn't a second lock password confirmation screen.
e) A new password can be set successfully.
3) Manual test 2
a) Repeat step 2)a) - 2)c)
b) Select "Fingerprint + PIN". There isn't a second lock password confirmation screen.
c) A new password and fingerprint can be enrolled successfully.
Bug: 33059280
Change-Id: I1078c6e303fc41aeeb370e5d6518d1f16b5837f1
Merged-In: I1078c6e303fc41aeeb370e5d6518d1f16b5837f1
Don't show managed profile version of shortcut
picker as it lunaches same activities as personal
one.
Test: manual - check badged shortcut isn't present in launcher.
Bug: 38333213
Change-Id: Iade6595255524a8dbf223a70a6c8312087258c23
Test: make ROBOTEST_FILTER=TelephonyMonitorPreferenceControllerTest
RunSettingsRoboTests -j40
Use enable, disable, user_enable, user_disable four statuses to
replace the old boolean value,
Bug:36704500
Change-Id: I5d3fd36aecaf36bb6969a6f6354c85bb162a0293
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
