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
- Search box is hidden if user set intent extra isSetupFlow true
Fixes: 135717823
Test: search box is hidden in the following command
adb shell am start -a android.settings.SETTINGS --ez isSetupFlow true
Change-Id: Ia3d955c9390d6b0eef9391b9b35b6a483eb63d26
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
If the user currently doesn't have a password and transitions
into another empty lockscreen (none -> swipe or swipe -> none),
there is no need to call setLockCredential.
Bug: 142701762
Test: Not yet :(
Change-Id: I553c8b30c7414775185d632660d962a73607baca
Previously, the biometrics were only cleared if the password was cleared from the Settings.
Moved the logic from the Settings app to the system server side.
Now, the biometrics will be removed no matter how the password is cleared (Settings, adb, TestDPC).
Bug: 130653263
Test: Atest LockSettingsServiceTests
manual testing from Settings, adb and TestDPC
Change-Id: I864b93404ec5cadb0685ac5d41376bf64ebde6f7
Bug: 140128468
Test: Verified with biometricpromptdemo that confirm device credential
still works correctly.
Change-Id: I0f608ba1256c696317402f56549452bf6933066b
Fixes: 132156012
Test: Verified with BiometricPromptDemo that talkback now
announces the correct password type for PIN/Pattern/Pass.
Change-Id: I3a04fe691140abba40396f95a601f863d87ee394
Removed the FooterPreferenceMixin from the ChooseLockGeneric page.
Fixes: 139269907
Test: manual test
Test: make RunSettingsRoboTests ROBOTEST_FILTER=com.android.settings.password
Change-Id: I86e294015354c0a6a6311441892a770503382d1f
If user enters face settings but does not enter the password, then
turns off the screen, it's possible the challenge is invalidated. Instead,
we should finish() the device credential screen as well as FaceSettings.
This prevents
1) The user from being prompted for credential with lack of context
2) Credential returning a HAT that wraps an invalidated challenge
The user will be returned to the security settings screen, where they
have more context and can decide if they want to enter face settings again.
Fixes: 138273242
Test: 1) Open face settings, do not enter password
2) Press power button
3) Unlock keyguard
4) User is not presented with credential screen
Test: Go through SUW, turning on/off the screen at various security
screens. Able to enroll successfully
Change-Id: I3c3d4600138012821bb0eea7d2927df00011cdb0
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
For devices which provide biometric authentication options, such as
fingerprint or face, we should be showing different content on the lock
setup screen during the corp account setup wizard. Namely, the title
should read "Choose screen lock", and the "Not now" option should be
changed to "Continue without [auth method]". However, we currently only
check for whether fingerprint authentication is available, leading to
incorrect text for devices with face authentication.
This CL fixes the issue by changing the introducing a private method to
check for any biometric authentication (currently just mForFingerprint ||
mForFace). It then uses this method in place of the existing
mForFingerprint checks in SetupChooseLockGeneric.
Test: On a device with fingerprint auth and one with face auth:
1. Set a work profile with TestDPC and add some password quality requirement
2. adb shell settings put global device_provisioned
3. adb shell am start -a android.app.action.SET_NEW_PARENT_PROFILE_PASSWORD
4. Verify that the correct content is now shown (screenshot/xZPVtpa3j3Z)
5. Verify that setting lock with and without biometric auth still works
Fixes: 136556653
Change-Id: I46d3c964f05986aa97cc8ed77fe0ac125337ddd0
If the calling app has admin rights (DA/DO/PO), don't display footer
text that the calling app is 'recommending' that a password is set.
Fixes: 131888973
Test: atest com.android.settings.password.SetNewPasswordActivityTest --verbose
Test: atest com.android.settings.password.ChooseLockGenericTest --verbose
Test: manual
Change-Id: I32785d33e6425416fc1dbba24540ece8917b58f3
Converting to Soong will move some code from directly compiled
into the app to compiled into an Android library and then
shared between the app and the tests. This will cause resource
IDs in the library to become non-final, which means they can
no longer be used in case statements. Convert affect case
statements to if blocks.
Test: m RunSettingsRoboTests
Change-Id: I25742a374f06d3fa4decbfc0d223a350acc50881
These classes are casting view to LinearLayout unnecessarily. Later we
might change the root view away from LinearLayout. The cast will cause
crash.
Bug: 132182711
Test: go through SUW.
Change-Id: Iea31882f8edea0c87ef8e95b4da9b6bffa8ea7d0
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
This is to match the method name "getPasswordComplexity" as requested by API review feedback
Bug: 128030136
Test: N/A
Change-Id: Ia4ce1b0ceb581608615364b41a05ca71142ef2b7
Relating to packages/apps/Settings
Bug: 120484642
Test: manual - test setting and unlocking passwords/pins/patterns.
automated - 20 of about 500 tests fail due to fragile synthetic
password test code.
Change-Id: Idec8338d141c185bef67ade12035fdb2fa9d17ea
Bug: 123737250
Bug: 111072170
Bug: 111071972
Test: manual both with and without the feature flag
Test: make RunSettingsRoboTests
Change-Id: Iacefa95dce85d860633315e074cbf2772691cfdd
