Handle is returned when LSKF is set after successful verification.
It is used by SUW to add biometrics without asking for LSKF.
Bug: 272807192
Test: manual
Change-Id: I3fe6ed7fd6401421090ccd684509dfede9106076
When managed profile gets wiped Settings may crash with SecurityException
when trying to retry authentication for no longer valid user.
Test: manually with TestDPC
Bug: 201513984
Change-Id: Ib7309abf89be76fcc1bf756c37c09d6b60c6b95c
* If there is a managed profile but a separate
profile challenge is not enabled, use the device
title and subtitle in ConfirmDeviceCredentialActivity.
Manual testing
* Set device PIN
* Create a work profile using TestDPC
* adb shell am start --user 10 -a android.app.action.CONFIRM_DEVICE_CREDENTIAL
* Verify title says 'Enter your device...'
* Add a work profile PIN
* adb shell am start --user 10 -a android.app.action.CONFIRM_DEVICE_CREDENTIAL
* Verify title says 'Enter your work...'
* Do the same for pattern and password
Bug: 163108636
Test: manual testing
Change-Id: I8b61e7d2df5792cbdb2e12b19e5a5582ea2290b7
FRP ConfirmDeviceCredentialActivity launched in initial setup flow should belong to internal flow, so it needs to set the external flag to false. It can transmit setup intent extra to the stencil library to make the screen be applied to the stencil and BC layout.
Bug: 171950236
Test: Manual test & RunSettingsGoogleRoboTests
Change-Id: Ia98d1bb4fc3a1687992b202b1e58afc1463efaf4
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
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
In several circumstances, the ConfirmDeviceCredentialActivity
may be started while the device is being unlocked - particularly, when
the managed profile on the device has a separate challenge and the user
is attempting to start an activity associated with the locked, managed
profile. For example, by double-tapping a notification from the managed
profile or trying to reply to such a notification.
When the ConfirmDeviceCredentialActivity is started after the user has
entered the primary lockscreen challenge but before the keyguard is
fully dismissed, the activity may be started and immediately paused.
If the activity then calls finish() in onPause(), the biometric prompt
will disappear and the user will not have a chance to authenticate.
Fix the issue by only calling finish() in onPause() if the biometric
prompt has not been shown.
The flag indicating whether the activity is waiting for biometric
prompt or not needs to be cleared whenever the biometric prompt invokes
the callback, so that the activity will correctly call finish() if the
user does abort authentication.
Bug: 153689182
Bug: 141470517
Test: Manual, set up a work profile and double-tap a work notification
or try to Reply to a work GMail notification.
Change-Id: I9d3d3000b99d0eb4b44b90f5a0c2856db5f32144
This moves the dependency to PromptInfo, which isn't optimal but
is still much more readable / manageable
Bug: 149067920
Test: adb shell am start -a android.app.action.CONFIRM_DEVICE_CREDENTIAL
Change-Id: I7d9ba2084db76284d08f68dd2005190f06412a1e
CDCA is a transparent activity with the sole purpose of
requesting authentication. Since authentication is all drawn
by SystemUI, we should also stop this activity from drawing
the StatusBar.
Register to receive biometric system events (early user canceled),
so that we can finish() and start the activity transition
simultaneously. This fixes some navigation bar jank.
Bug: 148273355
Test: Set up a work profile, then install BiometricPromptDemo
Disable one-lock and set up a password/biometric for the
work profile. Lock/unlock screen, then open the work
profile version of the app. No status bar jank seen.
Change-Id: I54a352527ed007dcaf1bea14a51711e4022fe028
With an associated change to the UI of the BiometricPrompt credential
view, this commit preserves the current appearance of the CDC auth flow
by promoting the "details" string from the description to the subtitle
field of the prompt.
Test: Manually, using the TestDPC app
Bug: 152053691
Change-Id: If1d773f7f9a7b141520eac70a6cd64c09eb27f20
For work challenges, do not reset incorrect password attempts if
challenge is resolved via biometric authentication. This is the
behaviour for personal keyguard and work challenge should be
consistent.
Bug: 139438785
Test: manual: enroll work challenge with fingerprint, set failed wipe
count (3) via TestDPC and attempt two failed attempts (via cmd
lock_settings). Resolve work challenge with fingerprint and attempt one
last failed attempt. Verify work profiel is wiped.
Change-Id: Ic64d3e44f3faa5adf8ac43db09e33c8403427990
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
* Updated text and description for PIN, password and pattern
* Added enterprise logo to work profile lock
Bug: 141290838
Test: Manual testing
atest com.android.systemui.biometrics.AuthBiometricViewTest
atest com.android.systemui.biometrics.AuthContainerViewTest
Change-Id: Iac6c9ca15e7446cbd7cce9fc1a1ac4e1c867bf31
CDCA no longer needs to cancel authentication in onPause. Since it
internally invokes BiometricPrompt, and BiometricPrompt's components e.g.
BiometricService and AuthController are aware of the "top-ness" of its
client, this code is redundant.
Fixes: 145991060
Test: Follow comment#3 in the bug above, repeat 10+ times
Test: Set up work profile, set up work profile password. Open work profile
app, but before entering password, swipe up to go to home screen.
Authentication is cancelled as expected.
Change-Id: I0b4d7d89cb9801ddbb6e3bd07f71191035cc75ec
* Updated FrameLayout of work profile lock in Settings to use GlifLayout
* Removed old background image of work profile lock
* Updated text for PIN, password and pattern
* Added enterprise logo to work profile lock
Bug: 141290838
Test: Manual testing
atest com.android.settings.password
Change-Id: Ie09974857b6c76a182a8075b9e1964a2e0af0de9
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
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.
Bug: 141382589
Change-Id: I74135dd9f6afb1b789302ad0af3daf8a73a4181b
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
Merged-In: I6521e896d0402fe856dc85476f51149c9b3084a8
(cherry picked from commit 49c7d07650)
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
Escrow tokens can only be activated by user confirming their LSKF,
while ConfirmCredential allows both LSKF and biometrics by default.
By requiring LSKF, it simplifies the DPC's flow of requesting the user
to activate a pending escrow token.
This change tweaks the ConfirmCredential UI to skip biometrics if pending
token exists.
Bug: 127377026
Bug: 76084679
Bug: 79547502
Test: manual
Change-Id: Iee9b2d57d7f4de98e225b3aeff7cc35cc8e3d36a
The description field handles longer strings more gracefully
Fixes: 124001277
Test: 1) Open Wi-Fi picker
2) Select gear on the connected network
3) Select share button
4) On BiometricPrompt, text is not cropped
Change-Id: I945830a137a0dc203bba04728b507ceff020dfdc
Fixes: 123502937
Test: Followed steps in comment #1 of the first bug above
Note that the test should be done with unified lock disabled, e.g.
have separate pin/pattern/pass for owner and work profile
Change-Id: I01d66a8a1d3ed1811497c2acb7db6158d99727a0
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
When an app uses KeyguardManager.createConfirmDeviceCredentialIntent to ask
the user to confirm credentials, it first goes into ConfirmDeviceCredentialActivity
and then goes into ConfirmLockPattern/ConfirmLockPassword, that incorporates
a derivative of ConfirmDeviceCredentialBaseFragment to deal with the actual credential
and fingerprint checking.
There are two bits of logic that are changed:
1) ConfirmDeviceCredentialBaseFragment gets target user id from the intent,
then uses UserManager.getCredentialOwnerProfile to find the credential owner
user id. If the target user is a work profile with unified challenge,
profile owner will be primary user, otherwise it will be the same user.
When credential confirmation dialog is invoked via
KeyguardManager.createConfirmDeviceCredentialIntent, mUserId will already
correspond to credential owner because ConfirmDeviceCredentialActivity already
calls getCredentialOwnerUserId(), so real target user is not available.
With this CL ConfirmDeviceCredentialActivity doesn't query credential owner because
it will be handled later anyway.
2) Currently when confirming credentials for work profile with unified challenge
we use mEffectiveUserId (credential owner) for fingerprints, which is incorrect,
since fingerprints are per-user and primary profile fingerprints cannot unlock
work profile apps' auth-bound keys. With this CL work profile user is used for
fingerprints.
Bug: 111821299
Test: manual, tried ConfirmCredential sample app in both profiles
Test: manual, tried CA certificate installation in both profiles
Test: manual, tried separate work challenge
Change-Id: I074f773de1bd6207b01664f259bdd04766f32d41
Bug: 36814845
Test: adb shell settings put global device_provisioned 0 && adb shell am start -a android.app.action.CONFIRM_FRP_CREDENTIAL
Change-Id: Id6ce6bc5ebd9c9e2a88790cc800678aff50e580f
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
