Align the behavior of frp and repair to have them
support the alternate button.
Bug: 339735656
Test: presubmit
Change-Id: Ib785db5ef16a68df4980dee451c6b638692adc5f
All activities that use biometric login through the CDCA class show a
Settings icon in the prompt. This cl adds a capability for the client of
the CDCA to set icon and icon description as extras to the unlock
intent.
Screenshot: http://shortn/_OpKTYFtddM
Bug: 333528540
Test: Manually verified on the device
Change-Id: Id7b5a3fe575069bef1810769e4f437e717d2d3c6
Fix face unlock confirmation button behavior to respect "always
require confirmation" setting. Adjust the description of the
confirmation toggle in private space face unlock settings to
reflect this change.
Screenshot: https://screenshot.googleplex.com/4uHfm9Z3ZE56ZaT.png
Bug: 342383195
Test: Tested manually by flashing local build
Change-Id: I0f742839a862fe66cacad9f5704dbe8b0df3a0c2
When turning off quiet mode for work profiles, ACTION_CONFIRM_DEVICE_CREDENTIAL_WITH_USER is fired
to confirm the device/profile PIN in order to decrypt the profile's storage. For work profiles with
unified challenge, we are expected to call LockPatternUtils.verifyTiedProfileChallenge() that
specifically decrypts the work profile's storage using the device PIN. This code flow is only reachable
when mForceVerifyPath is true in ConfirmDeviceCredentialActivity. In
I8b61e7d2df5792cbdb2e12b19e5a5582ea2290b7 a regression was introduced that caused the wong condition
to be used, and as a result work profile with unified challenge is no longer unlocked correctly in
this unlock flow. This bug is normally masked since we cache the unified work profile's password and
don't ask the user for device PINs most of the time. It's only reproducible when turning on work
profile from the keyguard, when we don't use the password cache. Fix this by using the right condition.
Bug: 328640625
Test: m RunSettingsRoboTests -j ROBOTEST_FILTER=com.android.settings.password
Change-Id: I5eb9379dc140c9803f033beee38fcd63aa9a85c0
This a layer of flag guarding only for the implementation of Private Space features excluding the APIs. The MVP flag allow_private_profile still guards all the features including the APIs.
Bug: 326060689
Test: Manual - a few verifications that some feeatures are unavailable when this flag is disabled
Test: Run presubmits and verify that nothing breaks
Change-Id: I05f7e2f20c6132b33484bb133ce03a933ece485f
isUserKeyUnlocked() is being renamed to isCeStorageUnlocked() to make it
clear what it does (considering that there are many types of user keys).
Temporarily, the method exists under both names. Change
ConfirmDeviceCredentialActivity to use the new name. No change in
behavior.
Bug: 306204742
Flag: exempt, mechanical refactoring
Test: presubmit
Change-Id: I9a3f686b57cfbf99b6c915565e5ecc38ddfe9b22
This change ensures the ConfirmCredentialActivity allows biometric
authentication to unlock (or disable quiet mode for) a profile if
the profile storage is unlocked when in quiet mode.
Test: atest SettingsRoboTest
Bug: 312184187
Change-Id: Iefcebf2f93403591a1a4c50ff5da8d6055a37b03
This change adds a separate block to handle auth checks for all profiles
that have the property alwaysRequireAuthenticationToDisableQuietMode set
to true. The force verify path is to be invoked for all such profiles
that share credentials with parent.
Test: m -j RunSettingsRoboTests or atest SettingsRoboTest
Bug: 293571176
Change-Id: Iec133bd9dfb22299cbd56ab811f341fa3957ead3
useDefaultSubtitle has to be set explicitly from promptInfo rather than being assumed true
remove subtext for managed profile challenge screen to create space for emergency call button
Test: manually tested
Bug: 286391641
Bug: 286422726
Change-Id: I848e00dcd0013124e59ef711c3615e6773c3d210
Move the screen lock message selection logic to Utils and update the
related strings as suzannechen@ suggested.
Test: manual (see bug)
Test: atest UtilsTest
Fixes: 291307701
Change-Id: I346c25426395eea1320edc07ce2d962efeb8daa6
To make the status bar content clearly visible we should set the light
status bar flag if the device is not in dark mode.
Bug: 241274551
Test: 1. Add an account and setup fingerprint unlock
2. Go to "Settings>Passwords & accounts>add account" to add
another account
3. Wait for BiometricPrompt to pop up and check the status bar.
Change-Id: I7208b9c18c3734d150dfaaef6724948bd197066a
Handles the ACTION_CONFIRM_REPAIR_MODE_DEVICE_CREDENTIAL
intent to launch the confirm device credential activity for
users to exiting repair mode. The activity passes a special
user id USER_REPAIR_MODE to the framework and verify credentials
that the user enrolled in normal mode.
Bug: 277561275
Test: am start -a android.app.action.PREPARE_REPAIR_MODE_DEVICE_CREDENTIAL
settings put global repair_mode_active 1
am start -a android.app.action.CONFIRM_REPAIR_MODE_DEVICE_CREDENTIAL
The credential is verified successfully.
Change-Id: I9ffe32f9925ee2b990c49d5674d27196a4c9edf7
Handles the ACTION_PREPARE_REPAIR_MODE_DEVICE_CREDENTIAL intent to
prompt the user for device credentials. Passing the writing repair
mode password flag to the verify credential api when the user is
authenticating.
Bug: 277561275
Test: am start -a android.app.action.PREPARE_REPAIR_MODE_DEVICE_CREDENTIAL
Change-Id: Id018586b0ed535555c157b7516c9571b049978ad
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
WorkLockActivity is added on top of each task that has any work
activity when the profile is locked. This activity is a task
overlay meaning it stays on top of other activities. It then starts
ConfirmDeviceCredentialActivity, also as an overlay because
otherwise it will sink under WorkLockActivity. But when CDCA
launches CofirmLockPattern, it is not set as an overlay and as a
result is not visible. These CLs add a boolean extra to instruct
CDCA to launch CLP (or other activities) as an overlay.
Bug: 271840143
Bug: 234002331
Test: manual, with TestDPC setting password reset token.
Test: m RunSettingsRoboTests -j ROBOTEST_FILTER=com.android.settings.password
Change-Id: Ie9b593696a24ad0c435b36eef80e3fe760c588ba
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
