Using the back buttons can cause a crash in at least two cases. Skipping
face enrollment and then starting/stopping any enrollment can lead to
an invalid token and failed HAT request. Backing out of the activity and
restarting it can also lead to using a stale token that fails.
Fix: 179336333
Test: manual on device
Change-Id: I0c1133e4c3d9c97997043ddc9374aa3cfc4f1c97
There will be multiple biometrics authentications existing at the same
time, so we added a new page for multiple biometrics to control
biometrics settings.
Bug: 183449119
Test: manual test
Change-Id: I359082caf771e07dfd5b24973cb8a3cf372c1b30
Do a few things in this cl
- Use correct way to work with controller.
- Refactor xml file.
- Separate content of footer to two parts.
- First paragraph should become top intro.
- Rest should keep in footer.
Test: Build apk and see the screen
Bug: 173087905
Change-Id: Icb16dedf6b36542b833527471579aaadb5407d87
Screenshot: https://screenshot.googleplex.com/92Jx6zKyTZU8LJa.png
1) Adds a layout for multi-biometric selection in BiometricEnrollActivity
2) Adds widgets for checkboxes
3) Shows ConfirmLock*/ChooseLock* for multi-biometric devices in
BiometricEnrollActivity
4) finish()'s when loses foreground
5) Adds default string for ChooseLock* and multi-biometrics, e.g.
"Set up Password + Biometrics", as well as associated plumbing
to bring the user back to BiometricEnrollActivity once the
credential is enrolled
6) When max templates enrolled, checkbox becomes disabled and
description string is updated
Bug: 162341940
Bug: 152242790
Fixes: 161742393
No effect on existing devices with the following:
Test: adb shell am start -a android.settings.BIOMETRIC_ENROLL
Test: SUW
Test: make -j RunSettingsRoboTests
Exempt-From-Owner-Approval: Biometric-related change
to EncryptionInterstitial
Change-Id: I855460d50228ace24d4ec5fbe330f02ab406cc02
LockSettingsService returns a handle to the gatekeeper password
instead of the password itself now. As such, update areas of code
accordingly.
Bug: 161765592
Test: RunSettingsRoboTests
Run the following on face/fingerprint devices
Test: Remove credential
adb shell am start -a android.app.action.SET_NEW_PASSWORD
Set up credential + fingerprint
Test: Remove credential,
adb shell am start -a android.settings.FINGERPRINT_SETTINGS
This tests the ChooseLock* logic in FingerprintSettings
Test: Set up credential,
adb shell am start -a android.settings.FINGERPRINT_SETTINGS
This tests the ConfirmLock* logic in FingerprintSettings
Test: Remove device credential, enroll fingerprint/face. Succeeds.
This tests the ChooseLock* returning SP path from
BiometricEnrollIntro
Test: With credential and fingerprint/face enrolled, go to
fingerprint/face settings and enroll. This tests the
ConfirmLock* path in Fingerprint/FaceSettings
Test: Remove device credential, enroll credential-only, enroll
fingerprint/face separately. Succeeds. This tests the
ConfirmLock* returning SP path in BiometricEnrollIntro
Test: In SUW, set up credential, then biometric. This tests
the ChooseLock* path in SUW
Test: In SUW, set up credential, go back, then set up biometric.
This tests the ConfirmLock* path in SUW
Change-Id: Ibc71ec88f8192620d041bfd125f400371708b296
Test: make -j56 RunSettingsRoboTests
Face Tests:
Test: Open face settings, remove face, add face
Test: Open face settings, but cancel credential confirmation.
Face settings does not show up
Test: adb shell am start -a android.app.action.SET_NEW_PASSWORD
Able to enroll face
Fingerprint Tests:
Test: Open fingerprint settings, add button is shown
Test: Open fingerprint settings, but cancel credential confirmation.
Fingerprint settings does not show up
Test: adb shell am start -a android.app.action.SET_NEW_PASSWORD
Able to enroll fingerprint
Bug: 162533680
Change-Id: Ie448ed086e73b0b545bd3a2e62437c543f7aad6c
GenerateChallenge used to block when showing the credential screen.
Now that GenerateChallenge is moved to after the credential screen
is shown, we need to delay the next button instead. This is generally
non percievable to the user, but this is more robust against busy
system server.
Fixes: 161325267
Test: Enroll fingerprint/face device
Change-Id: I0fbbef8bf469e32bed251acf22556ad2ea8e2933
Biometric enrollment will not request a Gatekeeper HAT during
initial credential setup or credential confirmation anymore.
Instead, it is broken down into the following steps now.
Bug: 161765592
1) Request credential setup / confirmation to return a
Gatekeeper Password
2) Biometric enrollment will generate a challenge
3) Biometric enrollment will request LockSettingsService to
verify(GatekeeperPassword, challenge), and upon verification,
the Gatekeeper HAT will be returned.
Since both LockSettingsService and Biometric enroll/settings
make use of biometric challenges, this allows us to make the
challenge ownership/lifecycle clear (vs. previously, where
LockSettingsService has no idea who the challenge belongs to).
Exempt-From-Owner-Approval:For files not owned by our team,
(StorageWizard), this change is just a method rename
Test: RunSettingsRoboTests
Run the following on face/fingerprint devices
Test: Remove credential
adb shell am start -a android.app.action.SET_NEW_PASSWORD
Set up credential + fingerprint
Test: Remove credential,
adb shell am start -a android.settings.FINGERPRINT_SETTINGS
This tests the ChooseLock* logic in FingerprintSettings
Test: Set up credential,
adb shell am start -a android.settings.FINGERPRINT_SETTINGS
This tests the ConfirmLock* logic in FingerprintSettings
Test: Remove device credential, enroll fingerprint/face. Succeeds.
This tests the ChooseLock* returning SP path from
BiometricEnrollIntro
Test: With credential and fingerprint/face enrolled, go to
fingerprint/face settings and enroll. This tests the
ConfirmLock* path in Fingerprint/FaceSettings
Test: Remove device credential, enroll credential-only, enroll
fingerprint/face separately. Succeeds. This tests the
ConfirmLock* returning SP path in BiometricEnrollIntro
Test: In SUW, set up credential, then biometric. This tests
the ChooseLock* path in SUW
Test: In SUW, set up credential, go back, then set up biometric.
This tests the ConfirmLock* path in SUW
Change-Id: Idf6fcb43f7497323d089eb9c37125294e7a7f5dc
The multitude of slightly different launchConfirmationActivity(*)
methods are a big unsustainable pyramid. It's too difficult to
read, too difficult to track which clients are interested in which
parameters, and too difficult to add new parameters, since we need to
1) Read through all of them and find one that's the closest
2) Try not to affect other callers, so potentially add yet another
3) Modify the internal paths, which all basically call each other
until it reaches the biggest launchConfirmationActivity which
has ALL of the parameters
This change should have no behavioral change.
Note: CredentialStorage doesn't need returnCredentials anymore as of
ag/6073449
Test: make -j56 RunSettingsRoboTests
Test: Manually traced code paths for each invocation. A few hidden
dependencies (such as explicitly setting challenge=0 with
hasChallenge=true) were found. Left them the way they were in
case they were intended
Test: Enroll face, fingerprint
Test: Enable developer options
Test: Change to PIN, Pattern, Password, then back to PIN (so each
type requests confirmation)
Test: adb shell am start -a android.app.action.CONFIRM_DEVICE_CREDENTIAL,
authenticate
Test: adb shell am start -a android.app.action.CONFIRM_FRP_CREDENTIAL
(shows confirm credential screen)
Fixes: 138453993
Change-Id: Ic82ef3c3ac2e14d624281921f2d816bcdacbd82b
When accessibility services such as talkback are enabled, and the
user tries to start the non-accessibility enrollment flow, present
a confirmation dialog.
Fixes: 152633740
Test: Enable talkback, start enrollment
1) Accessibility flow --> no dialog, as expected
2) Non-accessibility flow --> new dialog shown
Test: No talkback, start enrollment. No dialog shown in either case
Change-Id: I0cd07a9d0012f6c9bea36e74365a6707755d3ab7
The internal implementation of generate/revoke in system_server is now
asynchronous. To keep existing clients working, the manager classes
introduce a blocking version of the generateChallenge calls. This change
updates Settings to use the backward-compatible blocking calls.
Bug: 157790417
Test: Enroll fingerprint/face
Test: After enrollment, toggle setFeature or do subsequent enrollment
in face/fingerprint settings
Change-Id: Ib4dfdc5f12530b938ab9b1745f5a19cd9e2eceee
Sometimes Settings Search show the items that are not supported by
the hardware. e.g. FaceLock.
Add log to check the HW status when the problem occurred.
Bug: 156667203
Test: watch the log output.
Change-Id: Ie6a89f338aac6f7bdefc69fc84cfa5bf848ed015
In current design, we only check the hardware support for face unlock to
show/hide the face unlock results in Settings Search. However the face
settings page is not launchable when the user doesn't enroll the face
unlock. It will cause user confused that face unlock results is no
response when they click them. Therefore, it's more making sense to add
enrolled status checking to index the face unlock results.
Test: manual and robotests
Fixes: 157954564
Change-Id: I5dd36e15fe48d537ee499c73cc172fc913b39554
setActiveUser is removed from the @hide API surface and is no longer
necessary. The framework ensures that the correct user is set without
an explicit call, since userId is sent as a parameter to each of the
methods already.
Bug: 157790417
Test: See testing from frameworks/base change (12/n) from the same
gerrit topic
Change-Id: Id88b818ed0bb1f75f18ac8e9ba7aff2a9b80b319
Add the check condition in the getNonIndexableKeys to
check if the FaceManager exist or not.
Fixes: 147076221
Test: manual
Change-Id: I898c936403ce90869a9da28aa14297eb6bf5d730
Currently, there are some biometric security setting and enrollment
screens which remain open after the user has backgrounded them. This
means that they can later be resumed without requiring the user to
confirm their device credential as normal.
This commit fixes the issue in AOSP by adding logic to the affected
biometric enrollment/setting activities in to finish() with
RESULT_TIMEOUT in onStop(). We don't want to finish() these activities
prematurely if the user is currently in a wizard setup flow, however. In
that case, this commit ensures that the newly added logic will not run.
Test: Pixel 3 - Background at each step of fingerprint enroll => finish
Test: Pixel 3 - Rotate at each step of fingerprint enroll => no finish
Test: Pixel 3 - Proceed though fingerprint setup wizard => no change
Bug: 142544519
Change-Id: I8ec0fa1e30bafe097d9dc82991ff786ebf24844b
- Index the delete face unlock preference and set up face unlock preference.
Fixes: 147031175
Test: manual
Change-Id: Ia984a116947d0c2e6a909f53914d081e25496f87
- FaceSettingsLockscreenBypassPreferenceController's preference key
is different from that in xml. Use DashboardFragment generic way to
create PreferenceController which bind the preference key defined in
xml.
- Also refine the way of fixing b/140878309
Fixes: 145893081
Test: manual check FaceSettings and Notification Settings
Change-Id: Ia80e755e3f86b44e771b0cf80c9bf53a8ef8f430
The check logic of this preference requires a page loading prior to
slice auto convertion, so it is not suitable to become a slice.
Converting it to a slice will lead to an app crash.
Fixes: 145723632
Test: robotests
Change-Id: Ie6eafb244e9a1cc9267f6b747c8e357d239e688e
Bug: 140878309
Test: the option is not grayed out for secondary user.
Change-Id: I2413aa3c634e89a90d104e9ad60df15e49c75ed2
(cherry picked from commit e17caeea3f)
- We destoryed the MediaPlayer when VideoPreference is onPause().
When VideoPreference is onResumed, MediaPlayer always start from
pause state, we don't need a data save/restore current video state.
Bug: 143270527
Test: robolectric, manual
Change-Id: I544e933e4237f6d92aeff8a7eb04b52e89d74a4a
