Fix an issue where some sceenlock options are disabled
by admins but not showing up as grayed out.
Bug: 288081292
Flag: EXEMPT bug fix
Test: manually with `am start -a android.app.action.SET_NEW_PASSWORD
--ez isSetupFlow true --ei android.app.extra.PASSWORD_COMPLEXITY 327680`
Change-Id: I4aab61a052bc2c5146f44d0bfcd8153e3f2cee92
All activities that use biometric login through the CDCA class show a
Settings icon in the prompt. This cl adds a capability for the client of
the CDCA to set icon and icon description as extras to the unlock
intent.
Screenshot: http://shortn/_OpKTYFtddM
Bug: 333528540
Test: Manually verified on the device
Change-Id: Id7b5a3fe575069bef1810769e4f437e717d2d3c6
Fix face unlock confirmation button behavior to respect "always
require confirmation" setting. Adjust the description of the
confirmation toggle in private space face unlock settings to
reflect this change.
Screenshot: https://screenshot.googleplex.com/4uHfm9Z3ZE56ZaT.png
Bug: 342383195
Test: Tested manually by flashing local build
Change-Id: I0f742839a862fe66cacad9f5704dbe8b0df3a0c2
Test: Verified that the pattern option now appears disabled when
setting up COPE profile
Fixes 288081292
Change-Id: I43992dc4518a47a41e58e7b9cfd47fb22542e749
When turning off quiet mode for work profiles, ACTION_CONFIRM_DEVICE_CREDENTIAL_WITH_USER is fired
to confirm the device/profile PIN in order to decrypt the profile's storage. For work profiles with
unified challenge, we are expected to call LockPatternUtils.verifyTiedProfileChallenge() that
specifically decrypts the work profile's storage using the device PIN. This code flow is only reachable
when mForceVerifyPath is true in ConfirmDeviceCredentialActivity. In
I8b61e7d2df5792cbdb2e12b19e5a5582ea2290b7 a regression was introduced that caused the wong condition
to be used, and as a result work profile with unified challenge is no longer unlocked correctly in
this unlock flow. This bug is normally masked since we cache the unified work profile's password and
don't ask the user for device PINs most of the time. It's only reproducible when turning on work
profile from the keyguard, when we don't use the password cache. Fix this by using the right condition.
Bug: 328640625
Test: m RunSettingsRoboTests -j ROBOTEST_FILTER=com.android.settings.password
Change-Id: I5eb9379dc140c9803f033beee38fcd63aa9a85c0
The change adds private profile checks in addition to the exisiting
managed profile check to show customized message while choosing lock for
private profile in Pattern, PIN and Password screens.
Bug: 311343571
Test: Verify lock screen message for private space
Change-Id: Ic8173ff8c1af23fc593390acaff4c67390f99b9c
Merged-In: Ic8173ff8c1af23fc593390acaff4c67390f99b9c
The BiometricPrompt API setAllowBackgroundAuthentication is
now guarded by allowPrivateProfile flag. This change ensures the
references to this API are flagged by the same flag, and the uber
private space implementation flag - enablePrivateSpaceFeatures, as
well.
Bug: 312184187
Test: Tested by flashing changes on a test device
Flag: Flags.ALLOW_PRIVATE_PROFILE
Change-Id: Icfdc5a2c2f07177c25fa3d545837052209b76551
For private space lock setup as part of both PS setup and separate lock
form private space settings we need to show only traditional unlock
factors and Fingerprint but not show Face enrolment even on devices
where Face unlock is supported by hardware.
Once LSKF is enrolled it should be followed by Fingerprint enrollment
flow and after that Face enrollment should not be shown and exit lock
setup flow.
Currently for separate profile lock setup ACTION_SET_NEW_PASSWORD intent
is used in private space setup.
With this intent the options of LSKF+fingerprint+Face is shown in
devices supporting both fingerprint and face hardware. After the LSKF
ennrollment BiometricEnrollActivity is started which continues with
fingerprint and Face enrollment.
With this change we are passing an extra along with the intent to enroll
fingerprint only. Based on the intent extra value if set even if hardware
support exists the lock enrollment for the profile will support only
LSKF and fingerprint enrollment but not start Face enrollment.
User will still have the option to enroll Face from the dedicated settings
entrypoint in private space settings.
Recording link : b/323839067#comment4
Bug: 323839067
Test: Manual, verified option for face enrollment is shown or not shown
based on the intent extra. When extra is not passed the behaviour will be
default.
Change-Id: Idf92084052e02df9ca89f288c618796750e563e6
Update the strings for the warning shown to the user when they are about
to remove their screen lock and there are authentication-bound keys
that would be invalidated.
These strings are provided by Android UXW.
Additionally, apply the new string to all types of device lock screen:
Pattern, password and unknown.
Bug: 302109605
Test: Manual, flashed a device and added different types of screen lock.
Change-Id: Ida6f5f16c5aa1671f3f2c1358160b8173a1d1407
This a layer of flag guarding only for the implementation of Private Space features excluding the APIs. The MVP flag allow_private_profile still guards all the features including the APIs.
Bug: 326060689
Test: Manual - a few verifications that some feeatures are unavailable when this flag is disabled
Test: Run presubmits and verify that nothing breaks
Change-Id: I05f7e2f20c6132b33484bb133ce03a933ece485f
When the user goes through the flow of removing the device's lockscreen
knowledge factor (LSKF), warn them in case they have apps with
auth-bound keys on the device. Auth-bound keys that are bound to the
LSKF's secure user ID (that is, auth-bound keys that can be
authenticated by the user entering their LSKF) will be invalidated
when the LSKF is removed.
That means apps will not be able to decrypt the data encrypted with
these keys or use them to sign anything anymore (potentially effectively
losing the user's ability to prove their identity).
In this case, change the warning message that is shown to the user,
to make it clear wallet apps (that typically use such keys) will stop
working as well as other apps.
Bug: 302109605
Test: Manual, enrolled a PIN, face and fingerprint and tried removing PIN.
A CtsVerifier test will be added later.
Change-Id: I276b744f54763e291abe1f20824da4f8f156679d
During a new lock setup for profile whose credential is shareable with
its parent first the user is authenticated with device lock after which
an activity having options of Pin/Pattern/Password with fingerprint and
face combinations is shown.
On choosing any option which has combination to set LSFK and biometric
it is expected that after setting LSKF the Biometric enroll activity is
started but currently this does not work as expected as the
ChooseLockGeneric activity is finished after adding LSKF and it does not
start the biometric enrollment for the profile.
The issue also exists with non-profile users using this workflow through
SET_NEW_PASSWORD intent and if already have LSKF assigned.
This change adds a new boolean which takes care to not finish the
activity till the Biometric enrollment is started.
Below conditions are taken care with this change
- For new lock setup when device lock already exists then after
authentication of current device lock make sure the activity is not
finished untill the biometrics enrollment activity is started.
- On choosing continue without fingerprint or face option the biometrics
enrollment is not started
screen recordings uploaded to buganizer - b/316109077
Bug: 316109077
Test: Manual
Change-Id: Ifcbaa7d89195d87d432fc848092f2301752c3c22
This reverts commit 19d1d3d15d.
Reason for revert: revert it because this is not the root cause.
bug: 316867690
Change-Id: I0f168dbb64044aa720202af7b1040afd4f028c9c
isUserKeyUnlocked() is being renamed to isCeStorageUnlocked() to make it
clear what it does (considering that there are many types of user keys).
Temporarily, the method exists under both names. Change
ConfirmDeviceCredentialActivity to use the new name. No change in
behavior.
Bug: 306204742
Flag: exempt, mechanical refactoring
Test: presubmit
Change-Id: I9a3f686b57cfbf99b6c915565e5ecc38ddfe9b22
The change generalizes the workflow to disable strong auth requirements
for all profiles that require authentication to disable quiet mode,
once a successful unlock has happened through CDCA.
Currently, the call to disable the strong auth requirements is only
being done for work-profile.
Test: Tested locally on device with private space setup with a separate
challenge and tested the strong auth tracker values post this change.
Bug: 312184187
Change-Id: Ib41c51d1df78eea9415d72724b8cc693344e2c26
This reverts commit cf0501e4d7.
Reason for revert: b/317462033, it seems a flaky but revert it first.
Change-Id: Ie1d5e279cca6477fc17d8c27c1ecda8d7a6b2553
Repair mode requires the completion result after an user chooses
a new screen lock. This change defers finishing the activity until
the activity result is available.
Bug: 281641188
Test: atest SettingsRoboTests:com.android.settings.password
Change-Id: If635521ef7e1c509950d9683c15dffe45375cf4f
The change adds private profile checks in addition to the exisiting
managed profile check to show customized message while choosing lock for
private profile in Pattern, PIN and Password screens.
Bug: 311343571
Test: Verify lock screen message for private space
Change-Id: Ic8173ff8c1af23fc593390acaff4c67390f99b9c
Bug: 297959385
Test: 1. Enable talkback
2. Change or Set a password/pattern/pin
3. Check if there is a feedback after setting complete
Change-Id: I9a63bc99575e27b504dd3130e416f65dac068b4e
This change ensures the ConfirmCredentialActivity allows biometric
authentication to unlock (or disable quiet mode for) a profile if
the profile storage is unlocked when in quiet mode.
Test: atest SettingsRoboTest
Bug: 312184187
Change-Id: Iefcebf2f93403591a1a4c50ff5da8d6055a37b03
go/ss/3kmkEkasv6vmDDo.png
go/ss/7CzzSXZthbJVcEr.png
Bug: 308862923
Test: atest ChooseLockGenericTest and Verified manually customized
message is shown when passed with intent.
Change-Id: I784d42c4702801ec45bc8d4c5e911a404f549d46
This change adds a separate block to handle auth checks for all profiles
that have the property alwaysRequireAuthenticationToDisableQuietMode set
to true. The force verify path is to be invoked for all such profiles
that share credentials with parent.
Test: m -j RunSettingsRoboTests or atest SettingsRoboTest
Bug: 293571176
Change-Id: Iec133bd9dfb22299cbd56ab811f341fa3957ead3
Whenever launching
ChooseLockGeneric/ChooseLockPassword/ChooseLockPassword the activity
will finish itself when it goes into the background. This is to ensure
that a user only has an opporunity to complete this process once the
activity is shown. (It cannot be resumed after a power button press, or
sending the activity to the background)
Test: Verified in Settings that the ChooseLockGeneric,
ChooseLockPassword and the ChooseLockPattern activities now exit if they
are sent to the background.
Test: Same as above but in SUW
Test: m -j40 RunSettingsRoboTests ROBOTEST_FILTER=com.android.settings.password.ChooseLockPatternTest
Test: m -j40 RunSettingsRoboTests ROBOTEST_FILTER=com.android.settings.password.ChooseLockPasswordTest
Fixes: 287473148
Change-Id: Icc9142ff4672ab3669b2f425ff351b03ce7a223a
in initial setup and deferred setup
Bug: 301383804
Test: manually test with reproduciable steps in PO mode:
1. Set up offline and skip initial setup.
2. Navigate to home screen.
4. Connect to WiFi.
3. Sign in corp account during deferred setup.
5. Navigate to screen lock setup.
4. When landing on Choose screen lock, observe the behavior.
(cherry picked from https://googleplex-android-review.googlesource.com/q/commit:fdf80bd5c945f142e8529f104ca8b6d38d66d158)
Merged-In: I5d9d1d30d280311875d8bd8604aed0fd0c08ab2c
Change-Id: I5d9d1d30d280311875d8bd8604aed0fd0c08ab2c
