- 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
We need to show the encryption opt-in in non-FBE cases.
Test: atest RunSettingsRoboTests
Bug: 115847373
Change-Id: I3a92b265c9c8ecf5d4af009943b5b9483e25a738
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
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.
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
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 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
Currently the only way mUserPassword can be set is when it comes
from onActivityResult. This way when the user chooses "Continue
without Pixel Imprint", and we switch ChooseLockGeneric->InternalActivity,
mUserPassword becomes null (it is not preserved in intent extras).
And then this null is used in getLockPasswordIntent which causes the issue.
Another issues is that when the user chooses to use fingerprint,
mHasChallenge is set to true and password is not forwarded to
ChooseLock(Password|Pattern). I changed the intent builders so that both
old password and challenge can be sent at the same time, so the password
is not lost when fingerprint is set.
Bug: 67672081
Test: cd packages/apps/Settings/tests/robotests/ && mma
Test: manual, adb shell am start -a android.app.action.SET_NEW_PASSWORD,
tried setting pin/password with and without fingerprint.
Test: manual, tried to change lock via Settings -> Security&Location
Test: manual, set pin + fingerprint in Setup Wizard, FBE and FDE devices
Test: manual, set pin + added account, used pin to unlock FRP in SUW
Change-Id: I38d56d84f95c63fef24c2aa1a031d629f22756a1
When ChooseLockGeneric is recreated, don't automatically launch
ChooseLock[Password/Pattern] even if the corresponding intent extras
are specified, because one would have been launched in the previous
onCreate.
Test: Manual
Bug: 64605627
Change-Id: I227a14abb2f4dd6c4577186a3d8164df0bec7791
When setting up fingerprint's backup screen lock, show a different
header text that says
"To use fingerprint, set {PIN/pattern/password}" instead of
"Choose your {PIN/pattern/password}".
Test: Manual. Existing tests pass
Bug: 62187833
Change-Id: If1084e64b99291a0eda63c174793b5a091ab4bae
- Added "Screen lock options" button in PIN screen, controlled by
extra EXTRA_SHOW_OPTIONS_BUTTON, which will create a dialog to ask
the user to choose another screen lock type.
- Extracted ScreenLockType enum and ChooseLockGenericController that
can be shared by ChooseLockGeneric and the dialog
ChooseLockTypeDialogFragment.
- The intent extra EXTRA_SHOW_OPTIONS_BUTTON will be set if
ChooseLockGeneric screen starts ChooseLockPassword /
ChooseLockPattern without asking the user. (Although the extra is
ignored by ChooseLockPattern currently)
- Fix layout alignment for the password entry field to remove the
extra 4dp padding on the sides.
Test: cd tests/robotests && mma
Bug: 35442933
Bug: 38002299
Change-Id: I877fbe08a0c05bb97175e1cbf0260ea6dbda22e2
Consolidated the many variants of ChooseLock*.createIntent, so that
it will take the same set of arguments.
Also modified SetupChooseLock*.createIntent to modifyIntentForSetup,
which will take the intent created by ChooseLock* and modify it for
use with setup.
Test: cd tests/robotests && mma
Change-Id: I5ff033f459c33ec9980872a536b3996d89f2bbbb
