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
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)
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
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
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
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
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
This property was copying the HAPTIC_FEEDBACK_ENABLED deprecated user
setting. Starting from Android T this setting will be applied by the
Vibrator service for vibration with USAGE_TOUCH.
Bug: 185351540
Test: manual
Change-Id: Ifeee5a56b80a04bcf605defe9a310374dce68146
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
So the views won't relayout and cause the pattern
to render in a strange way.
Test: manual
Bug: 194368020
Change-Id: If6fd7ade4fd6783fe5d1ef78acc847928e01bd29
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
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
- Using GlifLayout api to set title and description
- Hide the header area for landscape mode
Bug: 179317709
Test: visual verified
1) Settings -> Security -> Screen lock -> Pattern
2) Try setting screen lock if there's no pattern
3) Rotate the screen during the settings flow and see if there's
an empty space leaving in the left side
4) Settings -> Security -> Fingerprint
5) Device will display a confirm lock pattern page
6) Rotate the screen and see if there's an empty space left
Change-Id: I16f614eceb873f40b7c48583223aedcbcbd7447d
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
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
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
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
Having consistent import order will reduce chance of merge
conflict between internal and external master
Test: rebuild
Change-Id: I0b1a170967ddcce7f388603fd521f6ed1eeba30b
