Skip button is now shown when ChooseLock is launched by
BiometricEnroll, otherwise users are forced to use passwords
(maybe good thing?)
Bug: 111548033
Test: Pin/pattern/pass must be set/confirmed before enrollment
Test: Able to enroll FP in SUW and Settings
Change-Id: Ic4bbeb539e4bf01c1c402dec308943292b43406d
1. remove the dependence of setupwizardlib.
2. add to use setupcompat and setupdesign.
3. modify new footer button in following up cl.
Bug: 120805516
Bug: 120872944
Test: RunSettingsRoboTests
Change-Id: I463dd35b799d4250b2aabce0cb0b8102cf9dd7d6
1) Fixed the theme for CDCA$InternalActivity to be transparent
2) CDCA only cares about biometrics, which are tied to userId
3) Moved shared methods to a util class
Fixes: 119296586
Test: Followed the steps in comment#1 of the bug linked above
Change-Id: Ie47fc7c3a53dfb7780087937e1ca83287cc52d71
- override the internal activity for picking screen lock from setup
wizard, so that when adding corp account, it can skip fingerprint even
when device is not yet provisioned.
Change-Id: I9485c54d097c82a584297fcaeb63b3271e05c1b6
Fixes: 112706989
Test: atest com.android.settings.password.SetupChooseLockGenericTest
ConfirmDeviceCredentials now uses BiometricPrompt instead of
FingerprintManager
Bug: 111461540
Test: FRP does not display BiometricPrompt (as expected)
adb shell settings put global device_provisioned 0 && adb shell am start -a android.app.action.CONFIRM_FRP_CREDENTIAL
Test: Using KeyguardManager API to launch, all corner cases seem OK
Test: Tested with work profile + one lock enabled/disabled, seems OK
Test: Enroll normal FP but not work FP, BiometricPromptDemo for both works
OK
Test: Test CC on work version of BPD, then BP on normal version of BPD,
both accept correct FP's (no regression from P)
Change-Id: Iacdaf76ab76971850212dc79513bfa3f4b89eb9a
CDC is going to use BiometricPrompt instead. This change
removes FingerprintManager from CDC. BiometricPrompt
will show before pin/pattern/pass is shown.
Bug: 111461540
Test: modified BiometricPromptDemo to use
KeyguardManager#createConfirmDeviceCredentialIntent,
Test: Fingerprint is gone from CDC, rotation works
Test: atest SettingsRoboTests
Change-Id: I9ce2aad71961af8a0d5ee636600e2fbdb6154e47
We need to show the encryption opt-in in non-FBE cases.
Test: atest RunSettingsRoboTests
Bug: 115847373
Change-Id: I3a92b265c9c8ecf5d4af009943b5b9483e25a738
Settings page should not show if device credential is not confirmed
Bug: 111548037
Fixes: 116531896
Test: adb shell settings get secure face_unlock_app_enabled
Test: make -j56 RunSettingsRoboTests
Change-Id: I651ee88e9ee4017ee3dc52fa8a5d05cb8f092e1d
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
When requestCode is 0, we will not finish activity.
Change-Id: Ib630951739031b05c83efe189875a4a41c8e51ec
Fixes: 113372155
Test: make RunSettingsRoboTests ROBOTEST_FILTER="com.android.settings.password"
Having consistent import order will reduce chance of merge
conflict between internal and external master
Test: rebuild
Change-Id: I0b1a170967ddcce7f388603fd521f6ed1eeba30b
"None" doesn't make sense for work profiles because it makes
profile insecure even if primary user is secure. If the user
wants to get rid of separate challenge, it will be offered in
previous Settings page, "Use one lock", so this shouldn't cause
any confusion.
Test: atest tests/robotests/src/com/android/settings/password/ChooseLockGenericControllerTest.java
Test: manual, tried setting personal an work challenges from Settings and via Intent.
Bug: 33656033
Change-Id: I830b3e372c1fe200fc4e02d59e3c3805bac5f9bb
When an app uses KeyguardManager.createConfirmDeviceCredentialIntent to ask
the user to confirm credentials, it first goes into ConfirmDeviceCredentialActivity
and then goes into ConfirmLockPattern/ConfirmLockPassword, that incorporates
a derivative of ConfirmDeviceCredentialBaseFragment to deal with the actual credential
and fingerprint checking.
There are two bits of logic that are changed:
1) ConfirmDeviceCredentialBaseFragment gets target user id from the intent,
then uses UserManager.getCredentialOwnerProfile to find the credential owner
user id. If the target user is a work profile with unified challenge,
profile owner will be primary user, otherwise it will be the same user.
When credential confirmation dialog is invoked via
KeyguardManager.createConfirmDeviceCredentialIntent, mUserId will already
correspond to credential owner because ConfirmDeviceCredentialActivity already
calls getCredentialOwnerUserId(), so real target user is not available.
With this CL ConfirmDeviceCredentialActivity doesn't query credential owner because
it will be handled later anyway.
2) Currently when confirming credentials for work profile with unified challenge
we use mEffectiveUserId (credential owner) for fingerprints, which is incorrect,
since fingerprints are per-user and primary profile fingerprints cannot unlock
work profile apps' auth-bound keys. With this CL work profile user is used for
fingerprints.
Bug: 111821299
Test: manual, tried ConfirmCredential sample app in both profiles
Test: manual, tried CA certificate installation in both profiles
Test: manual, tried separate work challenge
Change-Id: I074f773de1bd6207b01664f259bdd04766f32d41
When the device is not yet provisioned and settings is launched:
- disable the entry point for changing device lock
- remove the search panel from settings home page
- remove the search menu
Bug: 110034419
Test: make RunSettingsRoboTests
Change-Id: Ieb7eb0e8699229ec0824ccc19d7b958ac44965a2
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.
This patch focused on fixing compile errors and some runtime errors.
Test: We can't test it now. But we will have an integration test later.
Bug: 110259478
Change-Id: I16c471ddcd0fa1460c665b7f74d86fcace5ee67b
Bug: 110589286
Test: set up fingerprint + pass, change lock screen to swipe
no regression, fingerprints are all removed, activity is finished()
Change-Id: Ie5e586b2f9d2c982d929e5c5b80911897889e7a4
Bug: 110589286
Test: manual
Test: make -j56 RunSettingsRoboTests
Test: setting up new fingerprint still works
Change-Id: I1b7d2bb6bb417dae2c99e5abeb68d3f694cb3cb8
This change refactors common biometric settings code as well to minimize
duplicated code in areas such as:
Preference Controller
EnrollBase
EnrollIntro
This change also updates ChooseLock to have Face + Pin/Pattern/Pass
Bug: 110589286
Test: Fingerprint settings/enrollment still works
Test: make -j56 RunSettingsRoboTests
Change-Id: Ie35406a01b85617423beece42683ac086e9bc4a7
Bug: 110589286
Test: make -j56 RunSettingsRoboTests
Test: adb shell am start -a android.settings.FINGERPRINT_ENROLL still works
Test: adb shell am start -a android.settings.FINGERPRINT_SETUP still works
Change-Id: If33b557137cae7b57e4a0e906ee95032bc589436
- in onActivityResult(), the intent data can be null. Check for non null
intent data before trying to read the extra string from the intent.
Change-Id: I14c42725a7885a84688ae39fde63e30ad0536001
Fixes: 109675331
Test: make RunSettingsRoboTests
Removed unused constant and member that was set and retained across instances
but never actually used.
Test: manual, set password
Bug: 30558331
Change-Id: I575bf1f0508b9441b220641715e9ca7372d9b32c
Currently minimum password length policy is queried twice:
1. When constructiong the intent in
ChooseLockGenericFragment.getIntentForUnlockMethod and then
passed into setPasswordLengthRange in getLockPasswordIntent
2. in ChooseLockPasswordFragment.processPasswordRequirements via
LockPatternUtils.getRequestedMinimumPasswordLength().
These two values are then combined in processPasswordRequirements
using Math.max(), which doesn't make sense since it is the same
value.
With this CL it is only queried once in processPasswordRequirements.
+ cleaned up code filling in unused list.
+ removed unused extras, since they are never set anywhere.
Bug: 30558331
Test: atest ChooseLockPasswordTest
Test: atest SetupChooseLockPasswordTest
Test: atest ChooseLockGenericTest
Test: manual, set password policy and change password.
Change-Id: Ifc4946d5b3b26131da01178fa9c827de7a52c7c6
Add more check for stages of Patern input. Make sure that button "Screen lock options" is visiable.
Test: atest SetupChooseLockPatternTest
Bug: 76431549
Change-Id: Iec7d0eb4a3c16ebd2a504fbbc6de465c341ca43a
When a number of min length of a string is singular,
the definition of <plurals> can show a localization with a correct
grammar for singular.
Bug: http://b/78537276
Test: Manual
Change-Id: Ic5d94078f1c80a81a37ff7c11d5d5e106a764bed
This is part of the fix that upgrades the hashing of password history
to a more secure design.
Bug: 32826058
Test: manual
Change-Id: Ib022c8db1f7b63f75b69d0177fa5f6be528a83c5
This step is redundant since clearLock() would set the flag internally anyway.
In fact setting the flag before calling clearLock() is wrong since it will
lead LockSettingsService.setLockCredential() to think that the target profile
does not have a unified challenge, causing it to use an incorrect existing
credential for password change, leading to untrusted credential change.
Bug: 77892111
Test: Create profile; set separate empty work challenge; observe no crash
Change-Id: I4d76b20706a796654f9389f31ae8c46d51d7adac
When a DPC fires ACTION_SET_NEW_PASSWORD to set a work challenge
for an existing work profile with unified challenge, require the
user to confirm exisiting device lock first. This is not only for
increased security, but also a functionality requirement: the
system can only re-derive the current work profile password needed
by the password change after a fresh confirm credential operation.
Test: Add device lock, create work profile, then execute:
adb shell su 1010000 am start --user 10 -a android.app.action.SET_NEW_PASSWORD
Verify the device is prompting for current password.
Bug: 65910682
Change-Id: Ib4b4c88c1551cfff626f707d5f3182160a1ec46c
This CL disables fading the pattern during the pattern setup flow.
Test: The pattern fades everywhere but during the pattern setup flow.
Bug: 72798512
Change-Id: I959270cf39bc35080cce21777f0e168373406a17
