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.
Change-Id: I5d9d1d30d280311875d8bd8604aed0fd0c08ab2c
Test: Manually verified that the patterns text does not get
set to the empty string.
Fixes: 301214189
Change-Id: I768c9693b6be28a4cabaadc404465a172e2e5564
Fix the check for invalid characters in new passwords by switching from
PasswordMetrics#validatePassword() to
PasswordMetrics#validateCredential(). For more information, see
frameworks/base change I5c3c55367c3a294578cd0f97ac0e315a11ed517e.
Bug: 219511761
Bug: 232900169
Bug: 243881358
Test: Verified no regressions in 'atest ChooseLockPasswordTest'. Note,
this test is currently @Ignored and has 2 failures. I didn't
attempt to address that.
Test: Set a password containing non-ASCII characters on a device running
an older build. Upgraded and verified unlocking still works.
Tested that setting a new non-ASCII password is not allowed.
Change-Id: I5f1822a34688473cb103eb64dca56e4c19d4dd08
Merged-In: I5f1822a34688473cb103eb64dca56e4c19d4dd08
(cherry picked from commit b547094366)
This CL removes explicitly setting the disabled state of the confirm
button while reconfirming the PIN in the setting of PIN flow. We do this
since otherwise a11y services announces the state of the button which is
confusing for users.
Bug: b/281953347
Test: Tested by building and installing Settings APK on local device,
and checking a11y announcement. Also setup a PIN to see if the setup
flow is working properly.
Change-Id: I91b592310e240c3994049330c8a881740a3a0d59
setup and deferred setup
Make the style the same as DO mode SUW's Choose screen lock.
Bug: 237347124
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.
Change-Id: I03c7ba5e129fab121b4144fef0aa9a32dd95bcb5
When LockPatternUtils#setLockCredential() fails, it can either return
false or throw an exception. Catch the exception and treat it the same
way as a false return value, to prevent crashing com.android.settings.
Bug: 253043065
Test: Tried setting lockscreen credential while in secure FRP mode using
smartlock setup activity launched by intent via adb. Verified
that com.android.settings no longer crashes due to the exception
from LockPatternUtils#setLockCredential().
(cherry picked from commit 05f1eff1c9)
(moved change into ChooseLockPassword.java and ChooseLockPattern.java,
which are merged into SaveAndFinishWorker.java on udc-qpr-dev and main)
(cherry picked from https://googleplex-android-review.googlesource.com/q/commit:8f3ca8daeb583b8d46ad0d1045c2b953b83f5903)
Merged-In: I48b9119c19fb6378b1f88d36433ee4f4c8501d76
Change-Id: I48b9119c19fb6378b1f88d36433ee4f4c8501d76
