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
Bug: 110589286
Test: manual
Test: make -j56 RunSettingsRoboTests
Test: setting up new fingerprint still works
Change-Id: I1b7d2bb6bb417dae2c99e5abeb68d3f694cb3cb8
This CL disables fading the pattern during the pattern setup flow.
Test: The pattern fades everywhere but during the pattern setup flow.
Bug: 72798512
Change-Id: I959270cf39bc35080cce21777f0e168373406a17
On small screens < sw400dp,
- Don't show icon
- Don't show "Screen lock options" button
Test: cd tests/robotests && mma
Bug: 72764729
Change-Id: I8d9863d43c877fcc18f504d91d3183760b3fafc2
- for fragments that do not implement the preference screen, change them
to inherit from InstrumentedFragment instead.
Change-Id: I791c2634024bd2c248efea955be5c680180d735c
Fixes: 68277111
Test: make RunSettingsRoboTests
- Skip present during suw/deferred + non-fingerprint flow
- Skip hidden when opened from settings
- Skip hidden during suw/deferred when trying to setup up fingerprint
Test: Manually verified, robolectric tests updated
bug: 71763670
Change-Id: Ie3aac68a6d04c7727320af83532640580248bd47
