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
in initial setup and deferred setup
Bug: 301383804
Test: manually test with reproduciable steps in PO mode:
1. Set up offline and skip initial setup.
2. Navigate to home screen.
4. Connect to WiFi.
3. Sign in corp account during deferred setup.
5. Navigate to screen lock setup.
4. When landing on Choose screen lock, observe the behavior.
Change-Id: I5d9d1d30d280311875d8bd8604aed0fd0c08ab2c
Test: Manually verified that the patterns text does not get
set to the empty string.
Fixes: 301214189
Change-Id: I768c9693b6be28a4cabaadc404465a172e2e5564
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
Merged-In: I5f1822a34688473cb103eb64dca56e4c19d4dd08
(cherry picked from commit b547094366)
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
setup and deferred setup
Make the style the same as DO mode SUW's Choose screen lock.
Bug: 237347124
Test: manually test with reproduciable steps in PO mode:
1. Set up offline and skip initial setup.
2. Navigate to home screen.
4. Connect to WiFi.
3. Sign in corp account during deferred setup.
5. Navigate to screen lock setup.
4. When landing on Choose screen lock, observe the behavior.
Change-Id: I03c7ba5e129fab121b4144fef0aa9a32dd95bcb5
When LockPatternUtils#setLockCredential() fails, it can either return
false or throw an exception. Catch the exception and treat it the same
way as a false return value, to prevent crashing com.android.settings.
Bug: 253043065
Test: Tried setting lockscreen credential while in secure FRP mode using
smartlock setup activity launched by intent via adb. Verified
that com.android.settings no longer crashes due to the exception
from LockPatternUtils#setLockCredential().
(cherry picked from commit 05f1eff1c9)
(moved change into ChooseLockPassword.java and ChooseLockPattern.java,
which are merged into SaveAndFinishWorker.java on udc-qpr-dev and main)
(cherry picked from https://googleplex-android-review.googlesource.com/q/commit:8f3ca8daeb583b8d46ad0d1045c2b953b83f5903)
Merged-In: I48b9119c19fb6378b1f88d36433ee4f4c8501d76
Change-Id: I48b9119c19fb6378b1f88d36433ee4f4c8501d76
useDefaultSubtitle has to be set explicitly from promptInfo rather than being assumed true
remove subtext for managed profile challenge screen to create space for emergency call button
Test: manually tested
Bug: 286391641
Bug: 286422726
Change-Id: I848e00dcd0013124e59ef711c3615e6773c3d210
Remove the code that set LOCK_PATTERN_VISIBLE to true the first time a
pattern was set, since LOCK_PATTERN_VISIBLE now defaults to true when
unset (ag/22912136). The explicit defaulting to true was only needed
before because the low-level default value was wrong.
Bug: 270013005
Test: Set a pattern. Verified that Keyguard uses visible pattern.
Disabled the "Make pattern visible" option in Settings. Verified
that Keyguard doesn't use visible pattern.
Change-Id: I63f29c68f9a508fee0ee2f03f2cca33317fb8a32
Merged-In: I63f29c68f9a508fee0ee2f03f2cca33317fb8a32
(cherry picked from commit 6c3de30086)
When LockPatternUtils#setLockCredential() fails, it can either return
false or throw an exception. Catch the exception and treat it the same
way as a false return value, to prevent crashing com.android.settings.
Bug: 253043065
Test: Tried setting lockscreen credential while in secure FRP mode using
smartlock setup activity launched by intent via adb. Verified
that com.android.settings no longer crashes due to the exception
from LockPatternUtils#setLockCredential().
Change-Id: I48b9119c19fb6378b1f88d36433ee4f4c8501d76
(cherry picked from commit 05f1eff1c9)
Merged-In: I48b9119c19fb6378b1f88d36433ee4f4c8501d76
Move the screen lock message selection logic to Utils and update the
related strings as suzannechen@ suggested.
Test: manual (see bug)
Test: atest UtilsTest
Fixes: 291307701
Change-Id: I346c25426395eea1320edc07ce2d962efeb8daa6
When LockPatternUtils#setLockCredential() fails, it can either return
false or throw an exception. Catch the exception and treat it the same
way as a false return value, to prevent crashing com.android.settings.
Bug: 253043065
Test: Tried setting lockscreen credential while in secure FRP mode using
smartlock setup activity launched by intent via adb. Verified
that com.android.settings no longer crashes due to the exception
from LockPatternUtils#setLockCredential().
Change-Id: I48b9119c19fb6378b1f88d36433ee4f4c8501d76
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
