in the wrong position on PIN/Password/Pattern in the landscape mode.
1. Move the description position under the GlifLayout header
2. Move the position "Screen lock options" button under the
GlifLayout header
Bug: 272676038
Bug: 285271342
Test: manully test with reproducible steps:
STEPS TO REPRODUCE:
1. Go through the setup flow
2. Continue steps until “set pin” page
3. The “screen lock option” is in the wrong position
Test: make RunSettingsRoboTests ROBOTEST_FILTER="com.android.settings
.password.SetupChooseLockPasswordTest"
Change-Id: I24464e6b7e93f20abbeb59426919ed7fec5c7cbb
- set accessibilityLiveRegion as Polite mode to allow talkback to announce the state of checkbox even if is not in focus
Bug: 281950677
Test: Manual test by flashing on device and checking in talkback mode
Change-Id: Ia1066e2df1f40e6c339a4cd63f92acf0858f8f3d
- Fix the logic to set the pin_auto_confirm setting before triggering the password save workflow in ChooseLockPassword
Bug: 275385372
Test: atest AutoPinConfirmPreferenceControllerTest
Test: Manual Test
Change-Id: Id6774bc9afcd6d3161e023dc52911ae3e1f556c9
- Save and restore the autoPinConfirmOptionSetManually field during activity restart (because of orientation change)
- This helps to retain the state of the auto confirm unlock checkbox during an orientation change during set PIN stage.
Bug: 268592440
Test: Manual Test
Test: atest ChooseLockPasswordTest
Change-Id: I48ce9080b6007fb4e3a5ca5013d6c21ed4ba664f
- The method isAutoPinConfirmFeatureAvailable is changed to static, so refactoring the code to use it properly.
Bug: 270315296
Test: Manual Test
Test: atest AutoPinConfirmPreferenceControllerTest
Test: atest ChooseLockPasswordTest
Change-Id: Idecaeca296b9ae9acdd0c094dcbb736db31b74b3
- Add SwitchPreference to allow user to control the pin auto confirm feature
- Add Checkbox option during the PIN setup in Security app
- Disable the opt-in checkbox during SUW entry point for PIN setup
- Update SwitchPreference availability appropriately according to current PIN length
- Update the pin_auto_confirm setting appropriately according to state of switchPreference or checkbox state (in PIN setup)
- Update the error-message when PIN Too short to let user know six digit is recommended
Bug: 262926000
Bug: 262936383
Bug: 262934702
Bug: 262935305
Test: Manual Test
Test: atest SettingsRoboTests
Change-Id: Ib9e09bd5ce44652158e77f80e8be19c4dd50f3bf
Change <one> to <1> in string res file, and update related java files.
Test: Update, existing test still pass.
bug: 199230342
Change-Id: Idd0ba3c6adc060da21574d98f8ed765fae00cef8
Support for Full Disk Encryption was removed in Android 13, since now
File Based Encryption is always used instead. It turns out that I
missed a fairly large chunk of obsolete code: EncryptionInterstitial,
which is the screen that asks whether the device will require the
primary user's lockscreen credential when it starts up. This used to be
shown when setting the primary user's lockscreen credential, to
determine whether the full-disk encryption key would be tied to that
lockscreen credential or not. But now it's unused code.
This CL removes all this unused code.
This should not change any behavior, with one very minor exception:
Settings will no longer explicitly set the REQUIRE_PASSWORD_TO_DECRYPT
setting to 0 whenever the primary user's lockscreen credential is
changed. (This happened in SaveChosenLockWorkerBase.) This setting is
a @SystemApi, but it no longer has any meaning, since it is never set to
1 anymore. If there is a reason to keep it explicitly set to 0, instead
of unset, we should make LockSettingsService in system_server set it.
Test: Went through SUW, set a PIN, cleared the PIN, set a PIN again (all
using the UI). Nothing unusual seen.
Bug: 208476087
Change-Id: I039cc7a284e3f43e1e284970a5869958c909d1b7
Since legacy hideSoftInputFromWindow() for IME hiding animation
will be scheduled on the focus app's UI thread, so if activity
transition has running the animation on UI thread, the
IME hiding animation will be delayed until the animation finish.
Make sure calling WindowInsetsController#hide(ime()) before starting
activity transition to prevent flicker issue.
Bug: 204732064
Test: adb shell am start -a android.settings.BIOMETRIC_ENROLL
Test: SUW set/confirm pin and move to setup fingerprint(back and forth)
Test: make -j RunSettingsRoboTests
Change-Id: I33278dd5c993c0bc299ebd065011e5d18c7242e0
Prevent ChooseLockPassword and ChooseLockPatten being projected to
remote views, add FLAG_SECURE for these screens.
Bug: 179725730
Test: Check these 2 screens not projected to chromecast
Test: robo test for SetupChooseLockPatternTest ChooseLockPatternTest
SetupChooseLockPasswordTest ChooseLockPasswordTest
Change-Id: I7449a24427c966c1aa4280a7b7e7e70b60997cca
To distinguish the requirement between all numeric
and not all numeric when COMPLEXITY_HIGH.
Fix: 227149118
Fix: 173167839
Test: manual & robolectric
Change-Id: I1f682625d8e86963218dda43b626a9e55d169fb3
Replaces instances of the old fingerprint icon shown during Setup Wizard
or in Settings with either an updated version or an entirely different
icon.
Test: Manual
Fixes: 196600265
Change-Id: If78e8f0dbdb033f557614a019d4c9dde4493b6c6
Ensures that the existing subtitle strings for the choose lock
password/pattern screens are shown during SUW and from Settings.
Test: Manually tested PIN/pattern/password in SUW and Settings
Fixes: 193802664
Change-Id: Ibbb5f0c7bcd3885e63c02d8b68cd3205ffb529fd
- Fix the problem with invisible title
- Fix the wrong layout for landscape mode
- Apply color extraction
Fix: 185076320
Fix: 182339941
Fix: 182440016
Fix: 184715547
Fix: 183710293
Test: robotests and visual verified
Change-Id: Ib8e2a015bc52fcac2d285777972177e53bde7489
* 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
Need to make a copy of the LockscreenCredential in
onSaveInstanceState() since the credential will be
zeroized in onDestroy() while Bundle.putParcelable()
only keeps a reference of the object without any
copying.
Bug: 179108398
Test: manual
Change-Id: I090b691630f82406d1ae2f625dd2e0d578b83707
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
After applying collapsing toolbar in the Settings app, the toolbar title
will be shown in every subsetting pages. However some pages in the
security category don't need the title, like set screen lock page and
lock screen page. This CL is to disable these titles through overriding
isToolbarEnabled method.
Bug: 176883575
Test: manual test and visual verified
1) Navigate to Settings -> Security -> Screen lock ->
Pattern/PIN/Password
2) Observe and check if there is a duplicated title.
Change-Id: I6dfa4fbe1b5e2ac3582804ba1e125196f3bdba6c
Enforce a lock screen that adheres with the required complexity set by
the admin.
This is done by querying the DevicePolicyManager for the complexity set
for the given user, and merging it with the complexity from the "change
lock screen" intent (if any).
If the admin sets a higher complexity requirement than the app
triggering the lock screen change request, then the admin-set complexity
is enforced and the user is not shown information about the requesting
app.
Bug: 165573442
Test: Manually, set complexity using TestDPC and see it applies.
Test: m RunSettingsRoboTests ROBOTEST_FILTER=com.android.settings.password.ChooseLockGenericTest
Test: m RunSettingsRoboTests ROBOTEST_FILTER=com.android.settings.password.ChooseLockPasswordTest
Change-Id: If3f24f7430bdcbcd34265339f7d2a1ff82a44fc1
1) Adds a layout for multi-biometric selection in BiometricEnrollActivity
2) Adds widgets for checkboxes
3) Shows ConfirmLock*/ChooseLock* for multi-biometric devices in
BiometricEnrollActivity
4) finish()'s when loses foreground
5) Adds default string for ChooseLock* and multi-biometrics, e.g.
"Set up Password + Biometrics", as well as associated plumbing
to bring the user back to BiometricEnrollActivity once the
credential is enrolled
6) When max templates enrolled, checkbox becomes disabled and
description string is updated
Bug: 162341940
Bug: 152242790
Fixes: 161742393
No effect on existing devices with the following:
Test: adb shell am start -a android.settings.BIOMETRIC_ENROLL
Test: SUW
Test: make -j RunSettingsRoboTests
Exempt-From-Owner-Approval: Biometric-related change
to EncryptionInterstitial
Change-Id: I855460d50228ace24d4ec5fbe330f02ab406cc02
LockSettingsService returns a handle to the gatekeeper password
instead of the password itself now. As such, update areas of code
accordingly.
Bug: 161765592
Test: RunSettingsRoboTests
Run the following on face/fingerprint devices
Test: Remove credential
adb shell am start -a android.app.action.SET_NEW_PASSWORD
Set up credential + fingerprint
Test: Remove credential,
adb shell am start -a android.settings.FINGERPRINT_SETTINGS
This tests the ChooseLock* logic in FingerprintSettings
Test: Set up credential,
adb shell am start -a android.settings.FINGERPRINT_SETTINGS
This tests the ConfirmLock* logic in FingerprintSettings
Test: Remove device credential, enroll fingerprint/face. Succeeds.
This tests the ChooseLock* returning SP path from
BiometricEnrollIntro
Test: With credential and fingerprint/face enrolled, go to
fingerprint/face settings and enroll. This tests the
ConfirmLock* path in Fingerprint/FaceSettings
Test: Remove device credential, enroll credential-only, enroll
fingerprint/face separately. Succeeds. This tests the
ConfirmLock* returning SP path in BiometricEnrollIntro
Test: In SUW, set up credential, then biometric. This tests
the ChooseLock* path in SUW
Test: In SUW, set up credential, go back, then set up biometric.
This tests the ConfirmLock* path in SUW
Change-Id: Ibc71ec88f8192620d041bfd125f400371708b296
Biometric enrollment will not request a Gatekeeper HAT during
initial credential setup or credential confirmation anymore.
Instead, it is broken down into the following steps now.
Bug: 161765592
1) Request credential setup / confirmation to return a
Gatekeeper Password
2) Biometric enrollment will generate a challenge
3) Biometric enrollment will request LockSettingsService to
verify(GatekeeperPassword, challenge), and upon verification,
the Gatekeeper HAT will be returned.
Since both LockSettingsService and Biometric enroll/settings
make use of biometric challenges, this allows us to make the
challenge ownership/lifecycle clear (vs. previously, where
LockSettingsService has no idea who the challenge belongs to).
Exempt-From-Owner-Approval:For files not owned by our team,
(StorageWizard), this change is just a method rename
Test: RunSettingsRoboTests
Run the following on face/fingerprint devices
Test: Remove credential
adb shell am start -a android.app.action.SET_NEW_PASSWORD
Set up credential + fingerprint
Test: Remove credential,
adb shell am start -a android.settings.FINGERPRINT_SETTINGS
This tests the ChooseLock* logic in FingerprintSettings
Test: Set up credential,
adb shell am start -a android.settings.FINGERPRINT_SETTINGS
This tests the ConfirmLock* logic in FingerprintSettings
Test: Remove device credential, enroll fingerprint/face. Succeeds.
This tests the ChooseLock* returning SP path from
BiometricEnrollIntro
Test: With credential and fingerprint/face enrolled, go to
fingerprint/face settings and enroll. This tests the
ConfirmLock* path in Fingerprint/FaceSettings
Test: Remove device credential, enroll credential-only, enroll
fingerprint/face separately. Succeeds. This tests the
ConfirmLock* returning SP path in BiometricEnrollIntro
Test: In SUW, set up credential, then biometric. This tests
the ChooseLock* path in SUW
Test: In SUW, set up credential, go back, then set up biometric.
This tests the ConfirmLock* path in SUW
Change-Id: Idf6fcb43f7497323d089eb9c37125294e7a7f5dc
Bug: 161765592
Test: Accept/Reject/Lockout on the following
1) Owner profile
2) Managed profile with separate challenge
3) Managed profile with unified challenge
Change-Id: Ia7b670a29e9e8ee1fe65bd09965a454601a06871
This change adds the plumbing on Settings side for ConfirmLock*.
ChooseLock* will be done in a follow-up CL. The changes in this CL
are not invoked by any code path yet. This will also be integrated
in a follow-up CL.
Bug: 161765592
Perform the following with a local change to use
ChooseLockSettingsHelper#setRequestGatekeeperPassword(true)
Test: GK PW is received when setRequestGatekeeperPassword(true)
Test: GK PW + Challenge sent to GK, GK verifies and caller receives
GK HAT successfully
Change-Id: Ibd809784b5599343f34836bc5f3e709627b7f22a
The multitude of slightly different launchConfirmationActivity(*)
methods are a big unsustainable pyramid. It's too difficult to
read, too difficult to track which clients are interested in which
parameters, and too difficult to add new parameters, since we need to
1) Read through all of them and find one that's the closest
2) Try not to affect other callers, so potentially add yet another
3) Modify the internal paths, which all basically call each other
until it reaches the biggest launchConfirmationActivity which
has ALL of the parameters
This change should have no behavioral change.
Note: CredentialStorage doesn't need returnCredentials anymore as of
ag/6073449
Test: make -j56 RunSettingsRoboTests
Test: Manually traced code paths for each invocation. A few hidden
dependencies (such as explicitly setting challenge=0 with
hasChallenge=true) were found. Left them the way they were in
case they were intended
Test: Enroll face, fingerprint
Test: Enable developer options
Test: Change to PIN, Pattern, Password, then back to PIN (so each
type requests confirmation)
Test: adb shell am start -a android.app.action.CONFIRM_DEVICE_CREDENTIAL,
authenticate
Test: adb shell am start -a android.app.action.CONFIRM_FRP_CREDENTIAL
(shows confirm credential screen)
Fixes: 138453993
Change-Id: Ic82ef3c3ac2e14d624281921f2d816bcdacbd82b
Force a garbage collection and zeroize some fields after Activity finishes
Test: Goes through password change flow, then grab a heap dump via
adb shell 'am dumpheap $(pidof com.android.settings)
/data/local/tmp/settings.hprof'
And grep for password in the dump
Bug: 144537463
Change-Id: Idd0a04ada98900aeb2a6d20bb1270a4a4aec2cfd
Allows it to be used in more projects
Bug: 154161590
Test: Manually opened each setting that was impacted
Change-Id: Ife59074e5f8ffa76c2c81cca4022ca200bb59526
When unifying work profile challenge, keep the device lock
as long as it will still meet password requirement after unification.
If not, prompt the user to set a new device lock and only unify
work challenge after a compliant device lock is set.
Bug: 148630506
Fix: 149682344
Test: make RunSettingsRoboTests
ROBOTEST_FILTER='ChooseLockGenericTest|ChooseLockPasswordTest|ChooseLockPatternTest|LockUnificationPreferenceControllerTest'
Change-Id: I99cde2650902927f6a4cc7c0cc7c6016e0dc283f
These classes are casting view to LinearLayout unnecessarily. Later we
might change the root view away from LinearLayout. The cast will cause
crash.
Bug: 132182711
Test: go through SUW.
Change-Id: Iea31882f8edea0c87ef8e95b4da9b6bffa8ea7d0
Relating to packages/apps/Settings
Bug: 120484642
Test: manual - test setting and unlocking passwords/pins/patterns.
automated - 20 of about 500 tests fail due to fragile synthetic
password test code.
Change-Id: Idec8338d141c185bef67ade12035fdb2fa9d17ea
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
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
