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
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
Every launch of the activity with either ACTION_SET_NEW_PASSWORD
or ACTION_SET_NEW_PARENT_PROFILE_PASSWORD is logged, regardless
of whether extra EXTRA_PASSWORD_COMPLEXITY is used or whether
the caller has the required permisssion or not
- action: ACTION_SET_NEW_PASSWORD or
ACTION_SET_NEW_PARENT_PROFILE_PASSWORD
- pageId: SET_NEW_PASSWORD_ACTIVITY
- key: calling app package name
- value: raw value of intent extra EXTRA_PASSWORD_COMPLEXITY, or
Integer.MIN_VALUE if it does not exist
Bug: 120840632
Test: atest packages/apps/Settings/tests/robotests/src/com/android/settings/password/PasswordUtilsTest.java
atest packages/apps/Settings/tests/robotests/src/com/android/settings/password/SetNewPasswordActivityTest.java
Change-Id: I57dc55110f7f284ddad7d3fc971d1f2298b46cbd
