Handles the ACTION_CONFIRM_REPAIR_MODE_DEVICE_CREDENTIAL
intent to launch the confirm device credential activity for
users to exiting repair mode. The activity passes a special
user id USER_REPAIR_MODE to the framework and verify credentials
that the user enrolled in normal mode.
Bug: 277561275
Test: am start -a android.app.action.PREPARE_REPAIR_MODE_DEVICE_CREDENTIAL
settings put global repair_mode_active 1
am start -a android.app.action.CONFIRM_REPAIR_MODE_DEVICE_CREDENTIAL
The credential is verified successfully.
Change-Id: I9ffe32f9925ee2b990c49d5674d27196a4c9edf7
Handles the ACTION_PREPARE_REPAIR_MODE_DEVICE_CREDENTIAL intent to
prompt the user for device credentials. Passing the writing repair
mode password flag to the verify credential api when the user is
authenticating.
Bug: 277561275
Test: am start -a android.app.action.PREPARE_REPAIR_MODE_DEVICE_CREDENTIAL
Change-Id: Id018586b0ed535555c157b7516c9571b049978ad
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
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
Since legacy hideSoftInputFromWindow() for IME hiding animation
will be scheduled on the focus app's UI thread, so if activity
transition has running the animation on UI thread, the
IME hiding animation will be delayed until the animation finish.
Make sure calling WindowInsetsController#hide(ime()) before starting
activity transition to prevent flicker issue.
Bug: 204732064
Test: adb shell am start -a android.settings.BIOMETRIC_ENROLL
Test: SUW set/confirm pin and move to setup fingerprint(back and forth)
Test: make -j RunSettingsRoboTests
Change-Id: I33278dd5c993c0bc299ebd065011e5d18c7242e0
This intent data was only used by CryptKeeperSettings, which has been
removed. This is also one of the only remaining users of the
StorageManager.CRYPT_TYPE_* constants which were only ever intended to
be used with vold's Full Disk Encryption APIs, which have been removed.
Bug: 208476087
Test: m RunSettingsRoboTests -j ROBOTEST_FILTER=com.android.settings.password
(No regressions seen; 2 tests fail both before and after.)
Change-Id: Id6e2c0f5ecc79f7372b29393e66ffbd66d52d7a2
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
- 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
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
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
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
* If organization name has been set for
a managed profile, work challenge
should display it as the header.
Bug: 155274026
Test: manual testing
Manual Testing Steps
* Set up device with managed profile
* Set organization name via TestDPC
* Go Settings > Security > Work profile security
and add a work profile lock
* Select 'Work profile lock' and verify
organization name is shown in header
Change-Id: I83209383fd2cf9179c34ccfdf8c097c379ec933e
Allows it to be used in more projects
Bug: 154161590
Test: Manually opened each setting that was impacted
Change-Id: Ife59074e5f8ffa76c2c81cca4022ca200bb59526
For work challenges, do not reset incorrect password attempts if
challenge is resolved via biometric authentication. This is the
behaviour for personal keyguard and work challenge should be
consistent.
Bug: 139438785
Test: manual: enroll work challenge with fingerprint, set failed wipe
count (3) via TestDPC and attempt two failed attempts (via cmd
lock_settings). Resolve work challenge with fingerprint and attempt one
last failed attempt. Verify work profiel is wiped.
Change-Id: Ic64d3e44f3faa5adf8ac43db09e33c8403427990
Currently if a work profile with a separate lock is turned off
(a.k.a. in quiet mode), and the user has forgotten the password,
profile owner app cannot use DPM.resetPasswordWithToken because
the profile user is not running.
In BYOD case the user can remove and re-provision the profile but
in the new COPE mode (a.k.a. on an organization owned device with
work profile) it is not possible to remove the profile. So full
factory reset is required.
This CL allows the user to start the profile in locked state
(a.k.a direct boot mode) so that the admin can reset the password.
This CL adds "Forgot my password" button to work profile credential prompt
if all of the following conditions are true:
* Work profile is turned off
* Profile owner app is capable of running in direct boot mode.
* Profile owner app has an active password reset token.
* The device is an FBE device (otherwise profile will be unlocked).
Clicking this button starts the profile in locked state and shows an
activity to the user that instruct them to go to their IT admin.
Bug: 143516540
Test: manual
Change-Id: I832f7121b43e39161c5afa816f44ce89584b66e2
* The incorrect string was being displayed when the user
was asked to enter their pin/password.
* Updated the string to include **work** instead of
**device** when entering a work pin/password.
Bug: 148211118
Test: Manual testing
Change-Id: I2239a5011dec62fd63574bbf75495548ddd0d907
* Updated FrameLayout of work profile lock in Settings to use GlifLayout
* Removed old background image of work profile lock
* Updated text for PIN, password and pattern
* Added enterprise logo to work profile lock
Bug: 141290838
Test: Manual testing
atest com.android.settings.password
Change-Id: Ie09974857b6c76a182a8075b9e1964a2e0af0de9
Bug: 140128468
Test: Verified with biometricpromptdemo that confirm device credential
still works correctly.
Change-Id: I0f608ba1256c696317402f56549452bf6933066b
Fixes: 132156012
Test: Verified with BiometricPromptDemo that talkback now
announces the correct password type for PIN/Pattern/Pass.
Change-Id: I3a04fe691140abba40396f95a601f863d87ee394
Converting to Soong will move some code from directly compiled
into the app to compiled into an Android library and then
shared between the app and the tests. This will cause resource
IDs in the library to become non-final, which means they can
no longer be used in case statements. Convert affect case
statements to if blocks.
Test: m RunSettingsRoboTests
Change-Id: I25742a374f06d3fa4decbfc0d223a350acc50881
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
CDCA can be invoked with a bundle extra originating from BiometricService.
This allows us to add/forward new BP builder options to CDCA without having
duplicate API each time.
Bug: 111461540
Test: test app, receives correct callbacks
Test: CDC still works
Change-Id: Ia2080d161abba87949338176b34cdf440ed4ed53
1) Fixed the theme for CDCA$InternalActivity to be transparent
2) CDCA only cares about biometrics, which are tied to userId
3) Moved shared methods to a util class
Fixes: 119296586
Test: Followed the steps in comment#1 of the bug linked above
Change-Id: Ie47fc7c3a53dfb7780087937e1ca83287cc52d71
CDC is going to use BiometricPrompt instead. This change
removes FingerprintManager from CDC. BiometricPrompt
will show before pin/pattern/pass is shown.
Bug: 111461540
Test: modified BiometricPromptDemo to use
KeyguardManager#createConfirmDeviceCredentialIntent,
Test: Fingerprint is gone from CDC, rotation works
Test: atest SettingsRoboTests
Change-Id: I9ce2aad71961af8a0d5ee636600e2fbdb6154e47
Having consistent import order will reduce chance of merge
conflict between internal and external master
Test: rebuild
Change-Id: I0b1a170967ddcce7f388603fd521f6ed1eeba30b
This patch focused on fixing compile errors and some runtime errors.
Test: We can't test it now. But we will have an integration test later.
Bug: 110259478
Change-Id: I16c471ddcd0fa1460c665b7f74d86fcace5ee67b
Use GLIF theme as the default for confirm lock screen, even for
"external" launches of the screen. Renamed the theme from "internal"
to "normal" to reflect this change.
Dark theme code will be cleaned up later.
Test: Existing tests pass
Bug: 62573742
Change-Id: I86958eb3a440d7274807f1cf453c3e53c16c23e7
- for fragments that do not implement the preference screen, change them
to inherit from InstrumentedFragment instead.
Change-Id: I791c2634024bd2c248efea955be5c680180d735c
Fixes: 68277111
Test: make RunSettingsRoboTests
When the user enters a wrong pattern/pin/password, a "Wrong
pattern/pin/password" text shows up on ConfirmLockPattern or
ConfirmLockPassword screen. In ConfirmLockPassword, it disappears
automatically after 3 seconds, whereas it doesn't in ConfirmLockPattern.
In this change, we make the prompt in ConfirmLockPattern disappear
automatically as well.
Bug: 64781905
Test: manual
Test: make RunSettingsRoboTests
Change-Id: I53a25576413671ced4197064d51fbcc397733265
The ConfirmLockPassword screen (responsible for both PIN and password
locks) should not accept any input during the lock-out period after
consecutive incorrect unlock attempts. However, this is broken if the
activity is resumed from a paused state (e.g. from Recents).
In this CL, we clean up the logic around updating the UI controls, which
fixes the issue above and also hopefully simplifies potential future
work.
Bug: 63277910
Test: make RunSettingsRoboTests
Test: manual, both unified and separate work challenge
Change-Id: I752a5911d4445bf0caeea299ca3eb182e1defc62
Due to incorrect strings, we temporarily disabled the prompt strings for
strong auth and instead used the generic ones as a short-term fix. In
this CL, we correct the strong auth prompt strings and add them back to
the lock screen UI. The new strings are in line with those in keyguard.
Bug: 36511626
Test: manual
Test: make RunSettingsRoboTests
Change-Id: Ifba689db37cc7d331eb1a774814f6b6235977ff9
These screens are used whenever setting or confirming the
lockscreen PIN or password. Set them to a consistent textSize (24sp)
and a consistent fontFamily.
Would have set the fontFamily in the style, but unfortunately
setInputType is called on the TextViews after inflation which blows
away the fontFamily. Instead, we set it in code right after that
call.
Change-Id: I77c3f94e2b1ce6d1f19697394c5caa09aac423b0
Fixes: 62873478
Test: manual
The prompt strings on the confirm credentials screen (pin, password,
pattern) are incorrect. They currently say strong auth is "required
after device restarts". But instead they should be "required for
additional security" because strong auth can be enforced not only after
device or profile restarts, but also after profile key eviction, for
example.
Unfortunately, we've already missed the window for string changes.
Therefore, as an alternative, we use generic prompt strings in this CL,
to avoid conveying the incorrect (and misleading) information. We'll
follow up with another CL in master with a proper string change to fix
the issue.
Bug: 36511626
Test: manual
Test: make SettingsRoboTests
Change-Id: I44f84420b88bb4933ad0afa6e8032af465de0cd3
