Every launch of the activity with either ACTION_SET_NEW_PASSWORD
or ACTION_SET_NEW_PARENT_PROFILE_PASSWORD is logged, regardless
of whether extra EXTRA_PASSWORD_COMPLEXITY is used or whether
the caller has the required permisssion or not
- action: ACTION_SET_NEW_PASSWORD or
ACTION_SET_NEW_PARENT_PROFILE_PASSWORD
- pageId: SET_NEW_PASSWORD_ACTIVITY
- key: calling app package name
- value: raw value of intent extra EXTRA_PASSWORD_COMPLEXITY, or
Integer.MIN_VALUE if it does not exist
Bug: 120840632
Test: 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
Change-Id: I57dc55110f7f284ddad7d3fc971d1f2298b46cbd
1. Change to FooterBarMixin
2. Move FooterButton to the same package with FooterBarMixin
Bug: 120805516
Test: RunSettingsRoboTests
Change-Id: Ic6937e3cbc515dd7bf877c9193932cd5800ac801
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
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
The resources available to tests are now exactly the merged resources
located in the APK under test.
Bug: 74359828
Test: make -j56 RunSettingsRoboTests
Change-Id: I050db81a92decefea23314b5ec7a62f77ff4bb2b
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
* changes:
3/n: Make CDCA transparent and add BiometricPrompt
2/n: Add comments to launchConfirmationActivity parameters
1/n: Prepare ConfirmDeviceCredentials to use BiometricPrompt
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
We need to show the encryption opt-in in non-FBE cases.
Test: atest RunSettingsRoboTests
Bug: 115847373
Change-Id: I3a92b265c9c8ecf5d4af009943b5b9483e25a738
We directly use Robolectric/ActivityController to
setup an FragmentActivity lifecycle.
So, I removed the custom Robolectric in robotests/testutils.
Change-Id: Ib93265f719e1eb9606c9ad6f05c1dd1957302e8b
Fixes: 111195450
Test: robotests
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
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 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
- Let test cases can be compatible with AndroidX AlertDialog.
- Theme of Transparent needs to support AndroidX AlertDialog.
Change-Id: I0789b66f52feef30ebab7fb824d0e39d5ae9cc96
Fixes: 111413092
Test: make RunSettingsRoboTests -j56
- AndroiX AlertDialog needs to use Theme.AppCompat.
- Create a ShadowAlertDialogCompat which can be compatible with AndroidX AlertDialog.
Fix: 111247403
Test: make RunSettingsRoboTests -j56 ROBOTEST_FILTER=com.android.settings.password.ChooseLockTypeDialogFragmentTest
Change-Id: I3e4bca285ecaefa5705c8d170050c21d1bc649e0
Fix all Roboletric test cases.
In this CL, some test cases are broken.
So, We ignored these test cases temporarily.
Test: make RunSettingsRoboTests -j56
Bug: 110259478
Change-Id: I1a3075438a614432a2de4f2d96d8abf9a83ce58c
Bug: 110589286
Test: manual
Test: make -j56 RunSettingsRoboTests
Test: setting up new fingerprint still works
Change-Id: I1b7d2bb6bb417dae2c99e5abeb68d3f694cb3cb8
- 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
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
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
The minimal layout was sw400dp, but some smaller phones still have
enough space to display the icon and button decently, so we're
reducing the trigger threshold for the "minimal" layout to sw320dp.
Test: m -j RunSettingsRoboTests
Bug: 74527018
Change-Id: Ibfca1828870058301cca302554ce3d932c8ba70b
