This CL is trying to put the enrollment error messages into the title
area for UDFPS, and left the red text for the older devices with a rear
fingerprint.
Fixes: 178432748
Test: visual verified
Change-Id: Ib3a81531219dc963723ad0de99f079a230c580f5
- Refine the portrait layout to be reused for landscape
- Add strings for UDFPS enrollment
- Remove the landcaspe layout since it is no longer used.
Fixes: 171294253
Test: visual verified
Change-Id: Ibbfa5515437e2c2a348db9b621b4e60ba922a383
SUW library can support landscape mode. It reuse the portrait layout to
render the screen for landscape. So we don't need to have a layout for
it. This change is to move the description to a subtitle and remove the
unused layout.
Bug: 179234361
Bug: 171294253
Bug: 179317709
Test: visual verified
Change-Id: Icfb3be799c1b4e190691731638aaa3467cadf624
The sud_layout_description text view has been removed and being replaced
with a subtitle of GlifLayout. This is why Settings crash during setup
flow. Removing the text view and putting the string in the right place
can fix this issue.
Fixes: 182095350
Test: robotest
Change-Id: I05ea6fe5a404a20a46cf17ab212e6f736a119fe4
- Move top description into subtitle for landscape mode
- Update the button text
Bug: 177591560
Test: robotest and visual verified
1) Settings -> Security -> Fingerprint
2) Rotate the device and check if the description is on the right side
Change-Id: Ie20597fce48f73aa83c5d637682db1860c384a7a
During the setup flow, the enrolling animation will be shown in the
touch sensor page. This was caused by using the old layout during the
setup flow. Removing the overrided method getContentView to fix this
issue.
Fixes: 179447737
Test: visual verified
1) adb shell am start -n
com.google.android.setupwizard/.SetupWizardTestActivity
2) Follow the setup flow and check if the touch sensor page has an
animation
Change-Id: I249535d6c0e8a5f12d86aeeac5308489e469bf71
The BC theme didn't work in the fingerprint enrollment page since this
page was using a customized layout and wasn't following the SUD
template. Also the fingerprint sensor icon has been moved to SysUI so
it's unnecessary to have the customized layout.
This CL is trying to merge two layouts together and make BC theme apply
to the fingerprint enrollment page.
Bug: 177026664
Test: visual verified
Change-Id: Ia22ea14244cd4b508a1fa6341aa15bd741c195f4
Moving it to SystemUI, which handles rotation and position calculation
much easier.
Bug: 177965281
Test: manual
Change-Id: I9b7aadce95aae26330192074295d91283e49a24d
Since the education page of UDFPS is different from the one for rear
fingerprint, it's necessary to create a new education page for UDFPS and
update the decription.
Bug: 177026524
Test: visual verified
Change-Id: I70eb80484cccfbb583c32dbaadbc6c2744b5db60
SysUI is now responsible for showing the fingerprint icon and
circle (when finger is not down). This changes makes slight tweak
so the progress indicator is not covered by SysUI.
Fixes a few corner cases when onConfigurationChange occurs
Bug: 177026664
Bug: 177275693
Test: No effect on existing devices
Change-Id: Id06eab00861878a867804a27f4778f1e3fbd174e
Test: Verified regular fingerprint enrollment correctly logged
enrollment.
Test: Verified that the find fingerprint sensor activity no longer
falsely reports a failed enrollment.
Bug: 175316123
Fingerprint enrollment shows a find sensor screen which makes a call to
FingerprintManager.enroll(), the purpose is to get the user to locate
the sensor. The consequence was that logging built into the framework
was incorrectly logging a failed enrollment after cancellation.
Change-Id: I4777613fe521f04cc97c471e0a1e85e5809d7f06
Fixes: 169629017
Test: Wipe device, go through setup flow with a managed account.
Successfully set up credential and fingerprint
During the conversion to GkPwHandle (instead of HAT), the code in
Choose/ConfirmLock* and most of the biometric paths were updated, with
the exception of 2a below.
1) Only multi-biometric devices request Choose/ConfirmLock in
BiometricEnrollActivity.
2) Single-biometric devices (in almost all paths) request credentials
in their intro activities (FingerprintEnrollIntro, etc).
2a) However, there is a special path used by work profiles where
credentials are first set up, and the GkPwHandle is passed into
BiometricEnrollActivity, with the request to skip the fingerprint
enroll introduction page. In this case, we must remember to
forward the GkPwHandle to the relavent enrollment page
(FingerprintEnrollFindSensor).
At some point in the future we should have all credential stuff
done in BiometricEnrollActivity. However, due to legacy APIs, etc,
it may be more work than it's worth right now.
Change-Id: I3f95876de6969fee7130d7a19c8db363da69c4c2
1) Do not request enrollment until activity animation is complete
2) Do not show fingerprint icon until activity animation is complete
Bug: 171353506
Test: manual
Change-Id: I7cdf5fc4888e35c0a7ba38ea622ae9f3fe1a3abf
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
Test: fingerprint and face enroll via
adb shell am start -a android.settings.BIOMETRIC_ENROLL
Test: credential enroll via
adb shell am start -a android.settings.BIOMETRIC_ENROLL --ei android.provider.extra.BIOMETRIC_AUTHENTICATORS_ALLOWED 32768
Bug: 162341940
Bug: 152242790
Change-Id: Idfdf96891ba9a2394f61eedb0adde2adf9fd85e6
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
Fixes: 162486392
Test: Remove all fingerprints/credentials, tap fingerprint settings,
rotate device when setting credential. Finish credential
setup and biometric enrollment. Only prompted to set up credential
once.
Test: 1) Wipe device
2) Proceed to set up credential in SUW, but pause on first
credential screen (choose lock)
3) adb shell cmd uimode night yes // triggers activity recreate
4) Proceed with credential/biometric setup
Notice not re-prompted for credentials
Change-Id: I65fc0265acad98b18b152070b85cc4f71693cc68
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
