This a layer of flag guarding only for the implementation of Private Space features excluding the APIs. The MVP flag allow_private_profile still guards all the features including the APIs.
Bug: 326060689
Test: Manual - a few verifications that some feeatures are unavailable when this flag is disabled
Test: Run presubmits and verify that nothing breaks
Change-Id: I05f7e2f20c6132b33484bb133ce03a933ece485f
The change adds private profile checks in addition to the exisiting
managed profile check to show customized message while choosing lock for
private profile in Pattern, PIN and Password screens.
Bug: 311343571
Test: Verify lock screen message for private space
Change-Id: Ic8173ff8c1af23fc593390acaff4c67390f99b9c
Bug: 297959385
Test: 1. Enable talkback
2. Change or Set a password/pattern/pin
3. Check if there is a feedback after setting complete
Change-Id: I9a63bc99575e27b504dd3130e416f65dac068b4e
Whenever launching
ChooseLockGeneric/ChooseLockPassword/ChooseLockPassword the activity
will finish itself when it goes into the background. This is to ensure
that a user only has an opporunity to complete this process once the
activity is shown. (It cannot be resumed after a power button press, or
sending the activity to the background)
Test: Verified in Settings that the ChooseLockGeneric,
ChooseLockPassword and the ChooseLockPattern activities now exit if they
are sent to the background.
Test: Same as above but in SUW
Test: m -j40 RunSettingsRoboTests ROBOTEST_FILTER=com.android.settings.password.ChooseLockPatternTest
Test: m -j40 RunSettingsRoboTests ROBOTEST_FILTER=com.android.settings.password.ChooseLockPasswordTest
Fixes: 287473148
Change-Id: Icc9142ff4672ab3669b2f425ff351b03ce7a223a
This CL removes explicitly setting the disabled state of the confirm
button while reconfirming the PIN in the setting of PIN flow. We do this
since otherwise a11y services announces the state of the button which is
confusing for users.
Bug: b/281953347
Test: Tested by building and installing Settings APK on local device,
and checking a11y announcement. Also setup a PIN to see if the setup
flow is working properly.
Change-Id: I91b592310e240c3994049330c8a881740a3a0d59
So the new password can be saved per caller's request.
This will remove the additional step to ask the user
to enter the new credential again and thus simplifying
the UI flow.
Bug: 271968977
Bug: 277561275
Test: atest SettingsUnitTests:SaveAndFinishWorkerTest
Test: atest ChooseLockPasswordTest
Change-Id: I20232619225b17edda0a72dad43b120d5a249203
* Extract common code of ChooseLockPassword.SaveAndFinishWorker and
ChooseLockPattern.SaveAndFinishWorker to the parent class.
* Make setters return this to make it easy to chain setter calls.
* Rename SaveChosenLockWorkerBase to SaveAndFinishWorker.
This will make the code changes in the next CL much easier.
Bug: 271968977
Bug: 277561275
Test: 1. Add screen lock (password/PIN/pattern) using Settings
2. check screen lock works correctly
Change-Id: I98acd25f2dd81ab4608cc6943e4f238070003c17
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
Fix the check for invalid characters in new passwords by switching from
PasswordMetrics#validatePassword() to
PasswordMetrics#validateCredential(). For more information, see
frameworks/base change I5c3c55367c3a294578cd0f97ac0e315a11ed517e.
Bug: 219511761
Bug: 232900169
Bug: 243881358
Test: Verified no regressions in 'atest ChooseLockPasswordTest'. Note,
this test is currently @Ignored and has 2 failures. I didn't
attempt to address that.
Test: Set a password containing non-ASCII characters on a device running
an older build. Upgraded and verified unlocking still works.
Tested that setting a new non-ASCII password is not allowed.
Change-Id: I5f1822a34688473cb103eb64dca56e4c19d4dd08
- 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
