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
Allow the activity object to become unreachable before
iniating a gargabe collection to sanitize memory.
Bug: 189315376
Test: add device lock, confirm device lock in Settings,
then a memory dump and search for password shards.
Change-Id: I807d74628e1355814807855ad309d86ca1fb38a1
The choose screen lock page didn't apply the right theme during the
enterprise flow. That is because an intent extra of setup wizard wasn't
properly passed to the next page. In this change we made sure the intent
extra is able to properly pass to the next page.
We also removed the wrong theme for setup choose a screen lock page
since the wrong theme made this page broken. The setup choose a screen
lock is a sub setting page that wasn't implemented by using SUW library,
so it should not use GlifLayout theme. With this update, the choose a
screen lock page still keeps the background color of Settings, that is
different from the one of setup flow.
Bug: 190499041
Test: manual test
Change-Id: I9dceee6a398c7e7b487dd8e4046f71f76cc50e36
PIN and face dialog of Set a PIN screen to avoid flash during transition.
bug:191181054
Test: SUW
Test: make -j RunSettingsRoboTests
Change-Id: I229b190de5e6dc714bbb8408e91c363e90b18f30
The collapsing toolbar is introduced on S, which caused the Choose a
screen lock page has two different header. This CL is to supress the
collapsing toolbar from this page and also apply color extraction to the
page.
Bug: 190499041
Test: manual test
Make sure there's no collapsing toolbar in the page.
Change-Id: I8b7ea089bd9e9e7acdf0236099b1eb6270f0a816
The flow of changing lock screen is combined with Settings and SUW pages
together where their implementation are different, which causes the
page-to-page transition inconsistent. Sub-setting pages will apply
shared axis transition while SUW pages will keep the slide in/out
transition. In order to make these 2 types of page work together, we
intent to use slide in/out transition in the lock screen.
Fix: 174434707
Test: visual verified
Change-Id: I827211e45bcbfdfc558c9d95e6814e62b339b4aa
Makes the following changes to strings related to Face Unlock:
- Standardize capitalization of "Face Unlock"
- Use latest versions of traffic light face enroll strings
- Use latest versions of combined biometrics settings strings
- Set SUW description strings programmatically instead of in XML
Test: Manually tested Face Unlock traffic light and grid UIs
Bug: 183649070
Change-Id: Ie67978ae2630493a5b03b00c3f8a639066ab8f3a
- Using the SUW library API to enable the new style
- Removing some obsolete layouts which are using in landscape mode
- Verifying that these pages are using the new style
Fix: 188438375
Test: visual verified
1) Register a screen lock
2) Navigate to Settings > Security > Screen lock
2) See and check if the Pattern/PIN/Password confirmation page is using
the new style
Change-Id: I076dbf36388fa3badf4da409bcda83a5b368f13c
- 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
1) Credential can no longer be removed for separate challenge profiles,
so strings and supporting logic are also now removed
2) Updates existing strings for credential and fingerprint
3) Adds new strings for face
4) Adds new strings for face + fingerprint
Bug: 185180691
Test: manual on device
Change-Id: I2a850eb6644103e14ef2a670222e500c705a16cd
It is safe to always attempt to copy SUW intent extras, as they will
only be applied if they exist.
Fixes: 171950236
Fixes: 181212237
Fixes: 183711331
Test: SUW FRP verify, settings confirm existing PIN
Change-Id: I6d35683abdc864aea7b1ed0190d6776a75b3e116
* If there is a managed profile but a separate
profile challenge is not enabled, use the device
title and subtitle in ConfirmDeviceCredentialActivity.
Manual testing
* Set device PIN
* Create a work profile using TestDPC
* adb shell am start --user 10 -a android.app.action.CONFIRM_DEVICE_CREDENTIAL
* Verify title says 'Enter your device...'
* Add a work profile PIN
* adb shell am start --user 10 -a android.app.action.CONFIRM_DEVICE_CREDENTIAL
* Verify title says 'Enter your work...'
* Do the same for pattern and password
Bug: 163108636
Test: manual testing
Change-Id: I8b61e7d2df5792cbdb2e12b19e5a5582ea2290b7
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
FRP ConfirmDeviceCredentialActivity launched in initial setup flow should belong to internal flow, so it needs to set the external flag to false. It can transmit setup intent extra to the stencil library to make the screen be applied to the stencil and BC layout.
Bug: 171950236
Test: Manual test & RunSettingsGoogleRoboTests
Change-Id: Ia98d1bb4fc3a1687992b202b1e58afc1463efaf4
ConfirmLockPassword enforces that ForceVerifyPath
can only be set when caller is launching InternalActivity,
so the builder needs to launch that activity instead.
This is regressed from Idf6fcb43f7497323d089eb9c37125294e7a7f5dc
Bug: 179172552
Test: m RunSettingsRoboTests -j ROBOTEST_FILTER=com.android.settings.password
Change-Id: I8e03fc69c4748d09f17c29edaa77594e233f79ea
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
