Creates new setting on SFPS to require screen on before unlocking a
device. Also sets up toggles for this setting at the end of fingerprint
enrollment and on the fingerprint settings page, and adds tests to
verify expected behavior.
Test: make RunSettingsRoboTests ROBOTEST_FILTER=FingerprintSettingsRequireScreenOnToAuthPreferenceControllerTest
Fixes: 249169615
Fixes: 245343077
Fixes: 248530806
Change-Id: Id588796426d071860b3cc2af9ec5798c0027c202
Merged-In: Ia44604b059c4847c40608419b2e16219976ced3e
When FingerprintSettings got correct activity result from ConifrmLock or
ChooseLock, and ready to add first fingerprint automatically, it shall
set sud_slide_next_in and sud_slide_next_in in
overridePendingTransition.
Bug: 249981049
Test: Manually credential in FingerprintSettings
Change-Id: If63441cf1a72c30d558e9f50a0aada36a08b211d
1. on udfps + faceunlock devices, fingerprint settings shall not be
launched if no fingerprint enrolled.
2. on udfps device, after first fingerprint enrollment successfully,
fingerprint settings shall be shown.
3. Update FingerprintEnrollFindSensorTest to support udfps cases.
Bug: 243701933
Bug: 243003012
Test: manully adding first fingerprint on udfps + faceunlock device
Test: manully suw on udfps + faceunlock device
Test: run robotest for FingerprintEnrollFindSensorTest
and SetupFingerprintEnrollFindSensorTest
Merged-In: I62d945f2c2e980edf2a885234e54acae109e7672
Change-Id: I62d945f2c2e980edf2a885234e54acae109e7672
(cherry picked from commit 936dd31312)
Change to use FingerprintSetting as base activity when use launch
"Fingerprint Unlock" from Settings -> Security. And then we can prevent
that necesssary pop-up activites become full-screen.
Bug: 243701933
Bug: 232874879
Test: manual test following cases on fp-only devices, and enable don't
keep activity and test them again.
1. fp enrollment on SUW
2. fp add another on SUW
3. add first fp on Security Settings
4. add another fp on Security Settings
Test: atest FingerprintStatusUtilsTest BiometricsSafetySourceTest
Test: robo test for SetupFingerprintEnrollFindSensorTest
SetupFingerprintEnrollFinishTest
FingerprintEnrollFindSensorTest FingerprintEnrollEnrollingTest
Merged-In: Ib1c2ef9f93fb910eed2930f871c0c69bdb94bcbd
Change-Id: Ib1c2ef9f93fb910eed2930f871c0c69bdb94bcbd
(cherry picked from commit 84b39c3ed0)
FooterPreference doesn't support linkify in order to have better
accessibility. So we need to separate original 1 Footer into 2 Footers
in Fingerprint settings.
Bug: 230625178
Test: test fingerprint setting footer links with admin mode or non-admin
mode
Change-Id: I07263a1faaf7dddf79ba96dd9fcb4fce4cf8981b
Old span text shall not be used in preference footer. Change
implementation to use footer learnMore APIs
Bug: 228101275
Test: Make sure "Learn more" can be clicked on Fingerprint setting page
Change-Id: Ied2326b1a75fc02e7a3fe2321735f2f9f5ac066f
Test: Verified that AIDL FP devices honor the maximum number
of fp's allowed according to the HAL.
Fixes: 223617233
Change-Id: Ia0c46647d77ce52d4fe95154eae8d8b656456f53
* Move all logics around aggregating password policies
to the controller
* Replace HIDE_DISABLED_PREFS and MINIMUM_QUALITY_KEY
with HIDE_INSECURE_OPTIONS as all call sites are just
using them to hide insecure screenlock options.
* Remove password policy aggregation logic from
ChooseLockPassword and make it use policies passed in.
* Remove padlock from disabled screen lock options,
per UX mock.
* Increase char limit for some strings
Bug: 177638284
Bug: 177641868
Bug: 182561862
Test: m RunSettingsRoboTests -j ROBOTEST_FILTER=com.android.settings.password
Test: 1. set profile password quality/complexity and enroll device lock
2. set profile password quality/complexity and enroll work challenge
3. set parent password quality/complexity and enroll device lock
4. set parent password quality/complexity and enroll work challenge
5. set profile and parent password complexity, then enroll work challenge
6. set profile and parent password complexity, then unify work challenge
7. Enroll device lock during SUW
Change-Id: Iba1d37e6f33eba7b7e8e1f805f8e37aaec108404
1) Adds a layout for multi-biometric selection in BiometricEnrollActivity
2) Adds widgets for checkboxes
3) Shows ConfirmLock*/ChooseLock* for multi-biometric devices in
BiometricEnrollActivity
4) finish()'s when loses foreground
5) Adds default string for ChooseLock* and multi-biometrics, e.g.
"Set up Password + Biometrics", as well as associated plumbing
to bring the user back to BiometricEnrollActivity once the
credential is enrolled
6) When max templates enrolled, checkbox becomes disabled and
description string is updated
Bug: 162341940
Bug: 152242790
Fixes: 161742393
No effect on existing devices with the following:
Test: adb shell am start -a android.settings.BIOMETRIC_ENROLL
Test: SUW
Test: make -j RunSettingsRoboTests
Exempt-From-Owner-Approval: Biometric-related change
to EncryptionInterstitial
Change-Id: I855460d50228ace24d4ec5fbe330f02ab406cc02
LockSettingsService returns a handle to the gatekeeper password
instead of the password itself now. As such, update areas of code
accordingly.
Bug: 161765592
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: Ibc71ec88f8192620d041bfd125f400371708b296
Test: make -j56 RunSettingsRoboTests
Face Tests:
Test: Open face settings, remove face, add face
Test: Open face settings, but cancel credential confirmation.
Face settings does not show up
Test: adb shell am start -a android.app.action.SET_NEW_PASSWORD
Able to enroll face
Fingerprint Tests:
Test: Open fingerprint settings, add button is shown
Test: Open fingerprint settings, but cancel credential confirmation.
Fingerprint settings does not show up
Test: adb shell am start -a android.app.action.SET_NEW_PASSWORD
Able to enroll fingerprint
Bug: 162533680
Change-Id: Ie448ed086e73b0b545bd3a2e62437c543f7aad6c
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
The internal implementation of generate/revoke in system_server is now
asynchronous. To keep existing clients working, the manager classes
introduce a blocking version of the generateChallenge calls. This change
updates Settings to use the backward-compatible blocking calls.
Bug: 157790417
Test: Enroll fingerprint/face
Test: After enrollment, toggle setFeature or do subsequent enrollment
in face/fingerprint settings
Change-Id: Ib4dfdc5f12530b938ab9b1745f5a19cd9e2eceee
Allows it to be used in more projects
Bug: 154161590
Test: Manually opened each setting that was impacted
Change-Id: Ife59074e5f8ffa76c2c81cca4022ca200bb59526
Currently, there are some biometric security setting and enrollment
screens which remain open after the user has backgrounded them. This
means that they can later be resumed without requiring the user to
confirm their device credential as normal.
This commit fixes the issue in AOSP by adding logic to the affected
biometric enrollment/setting activities in to finish() with
RESULT_TIMEOUT in onStop(). We don't want to finish() these activities
prematurely if the user is currently in a wizard setup flow, however. In
that case, this commit ensures that the newly added logic will not run.
Test: Pixel 3 - Background at each step of fingerprint enroll => finish
Test: Pixel 3 - Rotate at each step of fingerprint enroll => no finish
Test: Pixel 3 - Proceed though fingerprint setup wizard => no change
Bug: 142544519
Change-Id: I8ec0fa1e30bafe097d9dc82991ff786ebf24844b
Fixes: 139163212
Test: manual test
Test: make RunSettingsRoboTests ROBOTEST_FILTER=com.android.settings.bluetooth
Test: make RunSettingsRoboTests ROBOTEST_FILTER=com.android.settings.accounts
Change-Id: I861434b81c07db785e6f1cfb3e34871ffba41e5f
Use the new FooterPreference and removed the old FooterPreferenceMixin
from the FingerprintSettings page.
Fixes: 139050306
Test: manual test
Change-Id: Ia4a2dda57512e30ee8628ad18d9c4263b88d13fc
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
Like we did the same thing in the Settings app [1][2][3],
FingerprintSetting is another instance that should use
ImeAwareEditText to make sure InputMethodManager#showSoftInput() is
called after the EditText gains IME focus.
This approach should be more robust and easier to maintain than trying
to control the software keyboard visibility with
SOFT_INPUT_STATE_ALWAYS_VISIBLE, which is more complicated that people
think.
This CL also removes RenameDialog#mTextHadFocus since
RenameDialog#mDialogTextField is always focused when the dialog is
shown [4].
This CL also removes the following fields since they can just be a
local final variables that will be captured into callback.
* RenameDialog#mFingerName
* RenameDialog#mTextSelectionStart
* RenameDialog#mTextSelectionEnd
[1]: I182b05d3ff59fb3b4732d60d0d5a464f0e0e0235
f6af093e2d
[2]: I892d639f3cc5d43db553b682d5278b8ce2fe72da
4803267106
[3]: Ib75ba0f361b8b46c3b717cc1ffb864726958ed82
b0bcbed372
[4]: I5bb1b7227c1323595bf7f483e11e87e2c3550093
7a1d52eb06
Fix: 118473687
Test: Manually verified as follows.
1. Build and flash aosp_taimen-userdebug to Taimen
2. Set up a fingerprint unlock.
3. Rotate the device to landscape mode.
4. Open Settings -> Security & location -> Fingerprint
5. Re-enter password if necessary
6. Tap "Finger 1"
7. Make sure that AOSP Keyboard shows up
Change-Id: I2a137aa8f6a1ee2b67923bcf40e82320a56c7b59
This means that in some cases RestrictedLockUtils has to be used and in
some RestrictedLockUtilsInternal.
This causes a lot of trivial code changes.
I also updated the ordering of the imports in all affected files.
Bug: 110953302
Test: Built
make -j RunSettingsRoboTests
Change-Id: I9bdf8b89134f853bae4f38c81af436715c73e924
Having consistent import order will reduce chance of merge
conflict between internal and external master
Test: rebuild
Change-Id: I0b1a170967ddcce7f388603fd521f6ed1eeba30b
This change connects the face status preference controller with the
settings fragment/activity. This change also implements the basic settings
page showing a video, a toggle for keyguard, improve/remove targets,
and footer.
Bug: 111321762
Test: manual
Change-Id: Ifc65f5acbf6551679074df63ef22ffba75229f37
This CL only changed AlertDialog imports.
So, reviewer can review it easily.
Change-Id: I097bc44394195b14287f4f920c570ac8653f356a
Fixes: 111413092
Test: This CL can't pass Robo test.
