Invokes the new hidden API to allow the work authentication prompt to
supply specific text to BiometricPrompt for credential auth. This
allows the prompt to use work-specific language when verifying work
credentials, while retaining more generic language when authenticating
with biometrics.
Test: Work lock prompt shows "Enter your work ___" for credential
Test: Work lock prompt now shows "Verify it's you" for face
Bug: 149003660
Change-Id: Icab8e16702ca31d08fa8b0b00f0519c9a37f609f
Test: Verified disabling fingerprint will not allow
the user to unlock work apps with fingerprint. (But can use fingeprint
within apps.)
Test: Verified disabling face and/or iris on a fingerprint device will
continue to
allow the user to unlock work apps with fingerprint.
Test: Verified disabling face on a face authentication device
will not allow the user to unlock work apps with face authentication.
(But can use face
authentication within apps.)
Test: Verified disabling fingerprint and/or iris on a face
authentication device will continue to allow the user to unlock work
apps with face authentication.
Change-Id: I2f72a85f39ec539e6c6bc2cf710ed2f5ebeb5f9a
Bug: 140128468
Test: Verified with biometricpromptdemo that confirm device credential
still works correctly.
Change-Id: I0f608ba1256c696317402f56549452bf6933066b
Currently we always send cancel() if ConfirmDeviceCredentialActivity
goes into the background. However, if the biometric state is no longer
authenticating, requesting cancel() in this state will result in an
inconsistent state between BiometricService/client and
ConfirmDeviceCredentials.
BiometricService/client will receive the ERROR_CANCELED message incorrectly,
while ConfirmDeviceCredential is showing / pending user password. When
the password is entered, its result is ignored.
The correct behavior is for ConfirmDeviceCredentialActivity to invoke
cancel() only if it's still authenticating. Otherwise BiometricService
and its client will receive ERROR_CANCELED, instead of the actual password
auth result.
Bug: 138279856
Test: BiometricPromptDemo, enable device credential fallback, get into
lockout state, successfully enter password. API result is
success instead of "canceled" now.
Change-Id: I6521e896d0402fe856dc85476f51149c9b3084a8
Fixes: 128747871
Test: BiometricPrompt launched by ConfirmDeviceCredential is canceled
Test: ConfirmLock* can also now be canceled
Test: No effect on non-biometric related paths
Change-Id: I237de136e63d523fece87fad7a93f4ecd66d800b
If the value is unset, we should maintain the same default behavior
as BiometricPrompt, which is to dfeault to requiring confirmation.
Fixes: 123598496
Test: manual
Change-Id: Icaf27d184e0aea5eee077b8ec14bca27fd0ddad3
CDCA can be invoked with a bundle extra originating from BiometricService.
This allows us to add/forward new BP builder options to CDCA without having
duplicate API each time.
Bug: 111461540
Test: test app, receives correct callbacks
Test: CDC still works
Change-Id: Ia2080d161abba87949338176b34cdf440ed4ed53
1) Fixed the theme for CDCA$InternalActivity to be transparent
2) CDCA only cares about biometrics, which are tied to userId
3) Moved shared methods to a util class
Fixes: 119296586
Test: Followed the steps in comment#1 of the bug linked above
Change-Id: Ie47fc7c3a53dfb7780087937e1ca83287cc52d71
ConfirmDeviceCredentials now uses BiometricPrompt instead of
FingerprintManager
Bug: 111461540
Test: FRP does not display BiometricPrompt (as expected)
adb shell settings put global device_provisioned 0 && adb shell am start -a android.app.action.CONFIRM_FRP_CREDENTIAL
Test: Using KeyguardManager API to launch, all corner cases seem OK
Test: Tested with work profile + one lock enabled/disabled, seems OK
Test: Enroll normal FP but not work FP, BiometricPromptDemo for both works
OK
Test: Test CC on work version of BPD, then BP on normal version of BPD,
both accept correct FP's (no regression from P)
Change-Id: Iacdaf76ab76971850212dc79513bfa3f4b89eb9a
