summaryrefslogtreecommitdiff
path: root/packages/SystemUI/src/com/android/systemui/biometrics/AuthCredentialPatternView.java
Commit message (Collapse)AuthorAgeFilesLines
* Merge tag 'android-13.0.0_r35' of ↵George Zacharia2023-04-031-1/+2
|\ | | | | | | | | | | | | | | https://android.googlesource.com/platform/frameworks/base into t13.0 Android 13.0.0 release 35 Change-Id: I709958b2f015d1774b2ece25894467c3a279f93c
| * [DO NOT MERGE]Fix AuthCredentialPatternView#onErrorTimeoutFinish() buglbill2022-10-311-4/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 1. When user auth fail on pattern view many times, the pattern view would be locked and disabled and wait for 30s timeout. Once timeout finish invoke, re-enabled pattern view is necessary. 2. Add AuthCredentialViewTest.java to extend PIN/Password/Pattern unit test coverage. Bug: 243699695 Test: atest com.android.systemui.biometrics.AuthCredentialViewTest Test: manual setup Pattern lock, try to wrong auth many times device locked for 30s patter view disabled once timeout, re-enabled pattern view Change-Id: I2fd26f6310e31e130d52a7c34a02a3ddf02b9166
| * Fix AuthCredentialPasswordView inputfield overlap issuelbill2022-10-201-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 1. SubTitle or descriptionView may not set by 3P app, so we should check visibility of subTitle and descriptionView only count it's position when view is visible. 2. Adjust landscape layout margin to ensure IME pop-up the auth header container can show title & description expectedly. 3. Set Title view with marquee when device in landscape mode and IME pop-up(mBottomInset > 0). Note:select to enable marquee unless a screen reader is enabled. Bug: 243115550 Test: atest AuthContainerViewTests Test: manual check visual, set display & font scale > largest check the PIN/Password inputfield should not overlap desc Change-Id: I5f3798b31749a1184bcbd9895b1b0820a1029d81
* | Forward port CM Screen Security settings (1/2)Michael Bestas2022-10-261-1/+3
|/ | | | | | | | | | | | | | | | | | | | | * Variable size pattern lockscreen * Toggle dots/error pattern visibility Change-Id: Ie109e82c1fb2fd96b07e977e1cd76ae3acb865ff Fix pattern visibility settings (1/2) Change-Id: Ic627953c5df854c442671a98b5da539b994da18b LockPatternUtils: Use the actual user id to set pattern size Ticket: CYNGNOS-2462 Change-Id: Ia68e26ec2dfc23317135d933bc25204c1380bb02 LockSettings: fix build Change-Id: Ic65b1a2af398faffb83776ee4013d47f79ab6619 Signed-off-by: Roman Birg <roman@cyngn.com>
* Deprecate boolean settings for haptic feedback and vibrate when ringingLais Andrade2022-01-181-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Deprecate HAPTIC_FEEDBACK_ENABLED in favor or HAPTIC_FEEDBACK_INTENSITY, and VIBRATE_WHEN_RINGING in favor or RING_VIBRATION_INTENSITY. Introduce hidden flag VibrationAttributes.FLAG_BYPASS_USER_VIBRATION_INTENSITY_OFF to represent HapticFeedbackConstants.FLAG_IGNORE_GLOBAL_SETTING in the vibrator service. This is applied by: - PhoneWindowManager, that converts HapticFeedbackConstants into (VibrationEffect, VibrationAttributes). - CellBroadcastAlertAudio, that triggers alerts using AudioAttributes with flags FLAG_BYPASS_INTERRUPTION_POLICY (that translates to same flag in VibratorManager, to bypass DnD) and FLAG_BYPASS_MUTE (that translates to this new flag, to bypass the new alarm intensity settings). The new flag is erased from request that are not from privileged apps, similar to the other bypass flag. The public HapticFeedbackConstants.FLAG_IGNORE_GLOBAL_SETTING has also been deprecated in T with a documentation explaining the removal of platform support. Remove SysUI dependencies on the deprecated settings, it should use the USAGE_TOUCH attribute and rely on the vibrator service to apply the user settings. Keep other SysUI dependencies that needs to run in older Android versions (like Launcher3). Bug: 185351540 Test: VibrationSettingsTest + manual Change-Id: I0372e4db19e09523795d7e79b9f7a15ae48a8cd9
* Return handle to gatekeeper password instead of actual passwordKevin Chyn2020-08-181-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This allows 1) LockSettingsService to ensure the password isn't valid forever. 2) Password to stay in system_server Also, adds ILockSettings#removeGatekeeperPasswordHandle so that callers can clean up after themselves. Bug: 161765592 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: I76534acc7af1e0f2e4d8af369fee31d1e19ddba9
* 3/n: Remove challenge from verifyCredentialKevin Chyn2020-08-071-2/+4
| | | | | | | | | | | | | | | | | Decouples the remainder of challenges from LockSettingsService. Clients that require Gatekeeper HATs that wrap challenges should request the Gatekeeper Password, then request LockSettingsService to verify(GatekeeperPassword, Challenge). If the challenge is biometric-related, it must be generated after LockSettingsService completes verifyCredential, since LockSettingsService internally does generateChallenge/resetLockout/revokeChallenge. Bug: 161765592 Test: CtsVerifier biometric portion Test: Reset fingerprint/face lockout Test: atest com.android.server.locksettings Change-Id: Icb384194ce5007b264068e697113d55cbf94945b
* 1/n: Allow LockSettingsService to return Gatekeeper PasswordKevin Chyn2020-08-071-3/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | For certain scenarios, it's ideal if a single prompt for the user's credential could generate multiple Gatekeeper HATs, each containing a distinct challenge. To do so, we expose the gatekeeper password to the caller, which can then be sent to LockSettingsService to mint a Gatekeeper HAT with a challenge specified by the caller. Functionally, this is split into two pieces: 1) ILockSettings#verifyCredential* has a new flags parameter, which if contains VERIFY_FLAG_RETURN_GK_PW, returns the gatekeeper password 2) ILockSettings introduces a new method, verifyGatekeeperPassword, which takes the Gatekeeper Password and challenge, from which Gatekeeper creates a HardwareAuthToken. This is different than the rest of spBasedDoverifyCredential and __only__ requests Gatekeeper to create the HardwareAuthToken. It does not proceed to do other things such as unlocking keystore keys, unlocking managed profiles, etc. Slightly cleaned up VerifyCredentialResponse: moved to builder pattern, cleaned up serialization/deserialization Returning a VerifyCredentialResponse object (instead of a byte[]) also makes it easier to debug failure cases (e.g. credential was verified but HAT was null, vs originally we have no idea). Similarly, this allows us to remove RequestThrottledException, which can help make it easier to reason about code flow (less unexpected nullness) Test: Clients with VERIFY_FLAG_RETURN_GK_PW have correct "accept, reject, timeout" behavior Test: Current biometric enrollment works and not affected Test: PIN/Pattern/Password verifyGatekeeperPassword works (see ag/12222644) Bug: 161765592 Change-Id: I6e2a7ea234aac1a278b35cdaff62b1c7e3e9f205
* Pass operationId to LSS, add HAT to KeyStoreKevin Chyn2020-03-121-5/+6
| | | | | | | | | | | | | | Since we're now allowing auth-per-use credential keys, we need to pass the operationId to SystemUI, which owns the call to verify credential. Upon receiving a non-null HAT, it should be sent to KeyStore. Bug: 148425329 Test: atest com.android.systemui.biometrics Test: atest com.android.server.biometrics Change-Id: Iea737bf2dc0d81d87419df96d5cb43d51f10c6e3
* Fix stealth mode for managed profilesKevin Chyn2020-02-201-3/+3
| | | | | | | | | | | | | | | | | | | | | | Stealth mode should not use effectiveUserId. Instead, it needs to use the original userId. Secondly, the pattern view should be setting stealth mode only after the configuration is received (e.g. onFinishInflate is too early, and the params are not passed in from its owner yet). Fixes: 148382970 Test: 1) Make pattern visible for managed profile 2) Reboot device 3) Open work profile app - pattern is shown when entered 4) Enter pattern 5) Lock screen, unlock screen 6) Open work profile app - pattern is shown when entered 7) Repeat 1-6 with pattern set to not be visible. pattern should not be shown during 3) and 6) Change-Id: I3e81cd31484fb0b7a99d554c3c274e8088df5ec7
* Use effectiveUserId for credentialsKevin Chyn2020-01-171-2/+3
| | | | | | | | | | | | | Credential-related stuff should use effectiveUserId instead of userId. Otherwise, authenticating for work profile will not work when one-lock is enabled. Fixes: 147653255 Test: Comment1 and Comment2 in the bug linked above Test: atest com.android.systemui.biometrics Change-Id: Icd9ad3fc69695cec509e3532b2b54d93833b94b5
* Introduce LockscreenCredentialRubin Xu2019-10-081-5/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * Wrap credential bytes and type into one single object. * Update all external APIs dealing with lockscreen passoword to use the LockscreenCredential class. Remove existing variants that handles pin/password/pattern separately. * Coerce password quality passed to LockSettingsService into one of UNSPECIFIED, PATTERN, NUMERIC or ALPHABETIC (explained below). * Update all clients & tests to interface with LockscreenCredential. Note: LockscreenCredential distinguishes between PIN and password in its public interfaces, this is to pave the way for the next patch of formally introducing a CREDENTIAL_TYPE_PIN type and getting rid of the requestedQuality being passed along (whose sole purpose nowadays is to distinguish between PIN and password) For now LockscreenCredential still uses the quality value internally to make that distinction. This does result in a change to what quality values LockSettingsService receives as part of credential change: after this CL LSS will only see the quality being one of UNSPECIFIED, PATTERN, NUMERIC or ALPHABETIC, while it used to receive other qualities (NUMERIC_COMPLEX, ALPHANUMERIC etc) if device admin sets a password policy. This shouldn't make any behaviour changes though, because the new range of values is still sufficient to distinguish between PIN/Pattern/Password, which is what the consumers of the stored quality care about. Bug: 65239740 Test: atest com.android.server.locksettings Test: atest com.android.server.devicepolicy.DevicePolicyManagerTest Test: atest com.android.internal.widget.LockPatternUtilsTest Test: atest com.android.internal.widget.LockscreenCredentialTest Test: make RunSettingsRoboTests ROBOTEST_FILTER=com.android.settings.password Test: atest MixedManagedProfileOwnerTest#testResetPasswordWithToken Test: atest MixedDeviceOwnerTest#testResetPasswordWithToken Test: manually set an PIN/Pattern/Password; then change to PIN/Pattern/Password; finally remove password Test: manually create a work profile; try unify and ununify work challenge. Test: manually test lockscreen FRP flow (change password via Settings / DPC) Change-Id: I04cc04057c96292a7b1b672bff2a09d594ea9b3c
* 16/n: Add PIN/PasswordKevin Chyn2019-10-041-0/+102
Bug: 140127687 Make AuthCredentialView abstract, and have the following subclasses 1) AuthCredentialPatternView 2) AuthCredentialPasswordView Back button cancels password authentication Test: manual test with pattern, pin, password Test: atest com.android.systemui.biometrics Change-Id: I95e42144616a59827da25d10d063990452714f76
generated by cgit v1.2.3 (git 2.25.1) at 2026-01-12 03:12:23 +0000