* 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
Show different titles and description messages when
enrolling password under various conditions:
* personal lock verus work lock
* adding a new lock versus updating existing lock
* enrolling a PIN verus password versus pattern
Add icons to options in screen lock picker.
Add an option to redirect to work lock flow if the admin
has set device-wide password requirement.
Bug: 183922696
Test: m RunSettingsRoboTests -j ROBOTEST_FILTER=com.android.settings.password
Change-Id: I40417b113814659d3226a44eb7f9d553386e3c58
When set, only enforce password requirement explicitly set device-wide.
As part of the change, restructure the code such that ChooseLockGeneric
becomes the central place for aggregating password requirements from
different parties, while ChooseLockPassword only enforces whatever
password reuirement it is told (by ChooseLockGeneric via intent extras)
Bug: 169832516
Test: m RunSettingsRoboTests ROBOTEST_FILTER=com.android.settings.password
Change-Id: I0acbea4819c13d4a8444c7b06928baccead18837
Bug: 123737250
Bug: 111072170
Bug: 111071972
Test: manual both with and without the feature flag
Test: make RunSettingsRoboTests
Change-Id: Iacefa95dce85d860633315e074cbf2772691cfdd
When an app that has the permission GET_AND_REQUEST_PASSWORD_COMPLEXITY
launches ACTION_SET_NEW_PASSWORD, it can use the DPM PASSWORD_COMPLEXITY_*
constants to specify the complexity it wants in a new extra
EXTRA_PASSWORD_COMPLEXITY.
The screen lock type picker would then filter out the options which
cannot fulfil the min complexity (and DPM restrictions) and will show a
footer with a brief description of the calling app and the requested type.
The same password requirements UI is used in ChooseLockPassword screen
to display the minimum requirements that can fulfil both DPM
restrictions and the min complexity.
The app must have permission GET_AND_REQUEST_PASSWORD_COMPLEXITY
otherwise the extra would be ignored.
ACTION_SET_NEW_PASSWORD is also updated to always display the calling app
name in the screen lock type picker if it is not launched by Settings,
with or without the new extra.
Bug: 111173457
Test: atest packages/apps/Settings/tests/robotests/src/com/android/settings/password/ChooseLockGenericControllerTest.java
atest packages/apps/Settings/tests/robotests/src/com/android/settings/password/ChooseLockGenericTest.java
atest packages/apps/Settings/tests/robotests/src/com/android/settings/password/ChooseLockPasswordTest.java
atest packages/apps/Settings/tests/robotests/src/com/android/settings/password/PasswordUtilsTest.java
atest packages/apps/Settings/tests/robotests/src/com/android/settings/password/SetNewPasswordActivityTest.java
atest packages/apps/Settings/tests/robotests/src/com/android/settings/password/SetupChooseLockGenericTest.java
manual test with TestDpc (ag/5901733)
Change-Id: I21a25d28669bf1223c3b02ba85c0755e59feee2e
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
- 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
