"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
Fix the previously-missing case where the user elects to set
a password (instead of PIN), but still sets a numeric password
that contains repeated sequence which should be blocked by admin
policy.
Bug: 72039850
Test: Set NUMERIC_COMPLEX password quality, then attempt to
enroll a repeating numeric PIN as lockscreen *password*
Change-Id: I7c7525716b37a5330147b899b80026ca71c3ce0c
Use GLIF theme as the default for confirm lock screen, even for
"external" launches of the screen. Renamed the theme from "internal"
to "normal" to reflect this change.
Dark theme code will be cleaned up later.
Test: Existing tests pass
Bug: 62573742
Change-Id: I86958eb3a440d7274807f1cf453c3e53c16c23e7
So that the action performed is always the same as what the button
label says.
Test: m -j RunSettingsRoboTests
Bug: 72197171
Change-Id: Ia2a02b630a86874d002e462e41fdf676c2d27203
Fixes: 70561469
Test: try to setup a password/pin, but type in a wrong pw/pin
when confirming. the button should stay as "confirm" instead of
reverting to "next"
Change-Id: Iea570c2d869b9d561b26046d30d08f40abca0c93
On small screens < sw400dp,
- Don't show icon
- Don't show "Screen lock options" button
Test: cd tests/robotests && mma
Bug: 72764729
Change-Id: I8d9863d43c877fcc18f504d91d3183760b3fafc2
- for fragments that do not implement the preference screen, change them
to inherit from InstrumentedFragment instead.
Change-Id: I791c2634024bd2c248efea955be5c680180d735c
Fixes: 68277111
Test: make RunSettingsRoboTests
- Skip present during suw/deferred + non-fingerprint flow
- Skip hidden when opened from settings
- Skip hidden during suw/deferred when trying to setup up fingerprint
Test: Manually verified, robolectric tests updated
bug: 71763670
Change-Id: Ie3aac68a6d04c7727320af83532640580248bd47
When moving apps or shared storage between storage media on FBE
devices, we need all users to be unlocked to successfully move
the data. This change asks the user to enter the credentials for
any locked users as part of the moving/migration wizard flows.
To do this we relax Utils.enforceSameOwner() to let us prompt for the
credentials of unrelated users, but we carefully only extend this
capability to callers interacting with the "internal" activities,
which require the MANAGE_USERS permission.
Test: builds, boots, users are unlocked before moving
Bug: 29923055, 25861755
Change-Id: Ifaeb2557c4f8c4354e1d380eaa0e413768ee239f
If the password is valid by all other checks, see if it is present on
the blacklist and disallow it if it is.
Test: set a password blacklist, try and set a blacklisted password and
see an explanation, set a non-blacklisted password successfully.
Test: make ROBOTEST_FILTER=ChooseLockPasswordTest RunSettingsRoboTests
Bug: 63578054
Fix: 65659151
Change-Id: Id155b824ad4b5839c23b6f5fd3fdfdcfc78c3df1
This is a clean up to action bar menu item pattern, we will use the same
pattern to build search icon on all pages in a later change.
Bug: 68814716
Test: robotests
Change-Id: Iedd3ec263e8ccb63ed75ec7a95b28c00878b1de4
