Should set the talkback focus to the header text when the "Draw your
pattern again" page is shown.
Bug: 275728120
Test: 1. enable talk back
2. Setup pattern lock
3. In "Draw your pattern again" page, make sure the talkback focus
is set to the header view
Change-Id: If99a950488039840e8486ebb634f0070a9403916
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
Legacy choose lock options was hard coded description.
1. In T-QPR when device do not support Face enroll in SUW flow,
We should remove "Face" from the description.
2. Use BidiFormatter to handle RTL string combination.
3. Define a new string for "Fingerprint"
4. Add workaround crash in ChooseLockGenericTest/SetupChooseLockGenericTest
Test: Manual login corp, and observe the UI in Choose screen lock
Test: adb shell settings put system system_locales ar check RTL
Test: m RunSettingsRoboTests -j ROBOTEST_FILTER=com.android.settings.password
Bug: 269786629
Bug: 277361320
Change-Id: I2b26b7cc229f66300bb23ca190bb21f86f1caa01
validation state.
Currently, if ConfirmDeviceCredentialBaseFragment is ever re-created due
to orientation change, screen getting turned off, etc., relevant state
gets lost. This led to the old ConfirmDeviceCredentialBaseFragment
handling results which led to issues such as lockscreen not getting set.
By addiing a retained RemoteLockscreenValidationFragment,
we're able to update the new ConfirmDeviceCredentialBaseFragment
that will handle results. We can also retain other important state like
the device credential guess to be set after successful validation.
Some smaller changes include:
* If the activity is finished for any reason other than "Back" getting
pressed, RESULT_FIRST_USER is returned instead of RESULT_CANCELED.
* CheckBox, "Forgot [LSKF]?" button, and EditText/LockPatternView
gets disabled during validation.
* The above also stay disabled if ConfirmDeviceCredentialBaseFragment
gets re-created and remote lockscreen validation is still in progress.
Test: m RunSettingsRoboTests -j
ROBOTEST_FILTER=com.android.settings.password
Test: Manual
Bug: 274983372
Bug: 274991889
Bug: 274792310
Bug: 270395807
Change-Id: Ib6d47430e233a43e6985ab83abae45713c49771f
- 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
Handle is returned when LSKF is set after successful verification.
It is used by SUW to add biometrics without asking for LSKF.
Bug: 272807192
Test: manual
Change-Id: I3fe6ed7fd6401421090ccd684509dfede9106076
WorkLockActivity is added on top of each task that has any work
activity when the profile is locked. This activity is a task
overlay meaning it stays on top of other activities. It then starts
ConfirmDeviceCredentialActivity, also as an overlay because
otherwise it will sink under WorkLockActivity. But when CDCA
launches CofirmLockPattern, it is not set as an overlay and as a
result is not visible. These CLs add a boolean extra to instruct
CDCA to launch CLP (or other activities) as an overlay.
Bug: 271840143
Bug: 234002331
Test: manual, with TestDPC setting password reset token.
Test: m RunSettingsRoboTests -j ROBOTEST_FILTER=com.android.settings.password
Change-Id: Ie9b593696a24ad0c435b36eef80e3fe760c588ba
- 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
Test: Manual - navigate to the activity mentioned in the bug and observe
the background
Bug: 264993674
Change-Id: I21c8143099e4c76ed5744cff12f31f578320a871
- 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
Since the SetupChooseLockPattern include header icon
header title, header sub-title, pattern state description,
LockPatternView and FooterBar, there was a limited room
for LockPatternView especially in the confirm steps which
both header title and pattern description occupy 2 lines space.
Hance the PatternView size used to inconsistence in-between
1st draw and 2nd confirm draw, besides it's visual looks
jumping and small on some device which have smaller display.
This solution includes 3 changes:
1. Organized the pattern view message to leverage
header sub-title view, then we can resever more space.
(Set minHeight=2 for sub-title)
2. Set screen_lock_options button visibilty to GONE when
the stage in 2nd confirmation.(Previously it's INVISIBLE
and reserve additional space)
3. Let LockPatternView align bottom of FrameLayout to prevent
the view juming and flicker.
4. Clean up unused forAnyBiometric flag and code.
5. GlifLayout.getDescriptionTextView() == mHeaderView
Need setDescriptionText() to make the view from GONE -> VISIBLE
6. Polish the stage flow and ensure IntroductionStage show
correct message
7. Add ChooseLockPattern into embeded activity white list
Force show ChooseLockPattern in fullscreen in case the Pattern
view truncated in `NeedToConfirmStage` where the title showing
2 lines and push pattern view down, and get bad UX in the
device which integrate a shorter display.
8. Add test cases for all stage and polish legacy test code.
Test: make RunSettingsRoboTests ROBOTEST_FILTER= \
"com.android.settings.password.SetupChooseLockPatternTest"
Test: make RunSettingsRoboTests ROBOTEST_FILTER= \
"com.android.settings.password.ChooseLockPatternTest"
Bug: 249974175
Bug: 260027850
Change-Id: I868af9b14ba99af5d78a05f6c2a570ccc07aea15
Temporary remove the redundant padding from ChooseLockPattern and
ConfirmLockPattern as a workaround solution.
Bug: 243008023
Test: make and check visual on foldable
Test: make RunSettingsRoboTests
Change-Id: I0baa2be65b797ca70f9de43bc8c5e3187a2d28ad
Merged-In: I0baa2be65b797ca70f9de43bc8c5e3187a2d28ad
Since the SetupChooseLockPattern include header icon
header title, header sub-title, pattern state description,
LockPatternView and FooterBar, there was a limited room
for LockPatternView especially in the confirm steps which
both header title and pattern description occupy 2 lines space.
Hance the PatternView size used to inconsistence in-between
1st draw and 2nd confirm draw, besides it's visual looks
jumping and small on some device which have smaller display.
This solution includes 3 changes:
1. Organized the pattern view message to leverage
header sub-title view, then we can resever more space.
(Set minHeight=2 for sub-title)
2. Set screen_lock_options button visibilty to GONE when
the stage in 2nd confirmation.(Previously it's INVISIBLE
and reserve additional space)
3. Let LockPatternView align bottom of FrameLayout to prevent
the view juming and flicker.
4. Clean up unused forAnyBiometric flag and code.
5. GlifLayout.getDescriptionTextView() == mHeaderView
Need setDescriptionText() to make the view from GONE -> VISIBLE
6. Polish the stage flow and ensure IntroductionStage show
correct message
7. Add ChooseLockPattern into embeded activity white list
Force show ChooseLockPattern in fullscreen in case the Pattern
view truncated in `NeedToConfirmStage` where the title showing
2 lines and push pattern view down, and get bad UX in the
device which integrate a shorter display.
8. Add test cases for all stage and polish legacy test code.
Test: make RunSettingsRoboTests ROBOTEST_FILTER= \
"com.android.settings.password.SetupChooseLockPatternTest"
Test: make RunSettingsRoboTests ROBOTEST_FILTER= \
"com.android.settings.password.ChooseLockPatternTest"
Bug: 249974175
Bug: 260027850
Change-Id: I868af9b14ba99af5d78a05f6c2a570ccc07aea15
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
