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
ConfirmDeviceCredentials now uses BiometricPrompt instead of
FingerprintManager
Bug: 111461540
Test: FRP does not display BiometricPrompt (as expected)
adb shell settings put global device_provisioned 0 && adb shell am start -a android.app.action.CONFIRM_FRP_CREDENTIAL
Test: Using KeyguardManager API to launch, all corner cases seem OK
Test: Tested with work profile + one lock enabled/disabled, seems OK
Test: Enroll normal FP but not work FP, BiometricPromptDemo for both works
OK
Test: Test CC on work version of BPD, then BP on normal version of BPD,
both accept correct FP's (no regression from P)
Change-Id: Iacdaf76ab76971850212dc79513bfa3f4b89eb9a
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
When an app uses KeyguardManager.createConfirmDeviceCredentialIntent to ask
the user to confirm credentials, it first goes into ConfirmDeviceCredentialActivity
and then goes into ConfirmLockPattern/ConfirmLockPassword, that incorporates
a derivative of ConfirmDeviceCredentialBaseFragment to deal with the actual credential
and fingerprint checking.
There are two bits of logic that are changed:
1) ConfirmDeviceCredentialBaseFragment gets target user id from the intent,
then uses UserManager.getCredentialOwnerProfile to find the credential owner
user id. If the target user is a work profile with unified challenge,
profile owner will be primary user, otherwise it will be the same user.
When credential confirmation dialog is invoked via
KeyguardManager.createConfirmDeviceCredentialIntent, mUserId will already
correspond to credential owner because ConfirmDeviceCredentialActivity already
calls getCredentialOwnerUserId(), so real target user is not available.
With this CL ConfirmDeviceCredentialActivity doesn't query credential owner because
it will be handled later anyway.
2) Currently when confirming credentials for work profile with unified challenge
we use mEffectiveUserId (credential owner) for fingerprints, which is incorrect,
since fingerprints are per-user and primary profile fingerprints cannot unlock
work profile apps' auth-bound keys. With this CL work profile user is used for
fingerprints.
Bug: 111821299
Test: manual, tried ConfirmCredential sample app in both profiles
Test: manual, tried CA certificate installation in both profiles
Test: manual, tried separate work challenge
Change-Id: I074f773de1bd6207b01664f259bdd04766f32d41
This CL only changed AlertDialog imports.
So, reviewer can review it easily.
Change-Id: I097bc44394195b14287f4f920c570ac8653f356a
Fixes: 111413092
Test: This CL can't pass Robo test.
Bug: 110589286
Test: make -j56 RunSettingsRoboTests
Test: adb shell am start -a android.settings.FINGERPRINT_ENROLL still works
Test: adb shell am start -a android.settings.FINGERPRINT_SETUP still works
Change-Id: If33b557137cae7b57e4a0e906ee95032bc589436
- 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 moving apps or shared storage between storage media on FBE
devices, we need all users to be unlocked to successfully move
the data. This change asks the user to enter the credentials for
any locked users as part of the moving/migration wizard flows.
To do this we relax Utils.enforceSameOwner() to let us prompt for the
credentials of unrelated users, but we carefully only extend this
capability to callers interacting with the "internal" activities,
which require the MANAGE_USERS permission.
Test: builds, boots, users are unlocked before moving
Bug: 29923055, 25861755
Change-Id: Ifaeb2557c4f8c4354e1d380eaa0e413768ee239f
1. Move getPreferenceScreenResId() from individual subclass to
InstrumentedPreferenceFragment.
2. Removed InstrumentedPreferenceFragment.getTitle() and let the
preference fragments that do not have preference screen set the activity
title directly instead.
3. Removed OptionsMenuFragment as all it does is call
setHasOptionMenu().
- changed subclasses of OptionsMenuFragment to extend from
InstrumentedPreferenceFragment directly.
- none of the exisitng subclasses actually implements the option menu
related methods to provide any option menu. So, the setHasOptionMenu()
call is not added to the subclasses.
4. Update Languages preference title.
- launch the fragment from the preference controller instead of from the
default handling, as we need the title res id at launch time to get it
work properly when retrieving the title from back stack.
Bug: 64564191
Test: blaze-bin/screenshots/android/i18nscreenshots/i18nscreenshots
Change-Id: Ibecdcab32cbaed8bf604ec5ebe0a926b4e489a7d
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
Bug: 36814845
Test: adb shell settings put global device_provisioned 0 && adb shell am start -a android.app.action.CONFIRM_FRP_CREDENTIAL
Change-Id: Id6ce6bc5ebd9c9e2a88790cc800678aff50e580f
Previously, failed ConfirmDeviceCredential attempts only counted towards the
wipe limit if it is used as a separate work challenge.
In this CL, we additionally make these failed attempts count towards the total
failures in the following scenarios:
1) when unified work challenge is enabled
2) for the primary user (e.g. when a wipe limit is set by a DO)
3) for secondary users
Bug: 27238008
Test: manual, by entering wrong credentials multiple times
Test: make SettingsRoboTests
Change-Id: Ie5a099bb3fd46245c13ccf4c8f91c4d935412a4e
Consolidated the many variants of ChooseLock*.createIntent, so that
it will take the same set of arguments.
Also modified SetupChooseLock*.createIntent to modifyIntentForSetup,
which will take the intent created by ChooseLock* and modify it for
use with setup.
Test: cd tests/robotests && mma
Change-Id: I5ff033f459c33ec9980872a536b3996d89f2bbbb
