After too many incorrect attempts at entering the user credential (PIN,
password, or pattern) for the work profile, a timeout will be triggered
to limit the rate of retries. At the same time, fingerprint should no
longer be allowed to unlock the work profile, until the user unlocks it
with the correct user credential.
Previously, fingerprint was not banned from unlocking the work profile
during and after the said timeout. (Pattern lock screen only had a
partial fix which removed the fingerprint UI, but still allowed
fingerprint to unlock.)
This CL fixes the issue. It also replaces the following fields with
equivalent getter methods:
- mIsStrongAuthRequired,
- mAllowFpAuthentication.
Otherwise, we would have to rely on these internal states being always
up-to-date, which is less maintainable.
Test: make SettingsGoogle and manually enter incorrect PINs/patterns
Bug: 36912481
Change-Id: Id6ac6b5c78bdc19078ce8dd7acb4ec41329e57c3
Previously, the KeyStore lock state was used but this doesn't hold any
real value and may be removed in future. The user unlock state is the
source of truth we are looking for.
Test: Enroll finger, turn off work, lock and unlock device, turn on
work, asked for pin but can no longer user fingerprint.
Fixes: 34858001
Change-Id: I228952f4f7fd24916d294b5b523c6d3609520506
Now it is necessary to actually press the exact "OK" or Back button to
get the dialog to dismiss. This makes pocket wiping that little bit less
likely.
Bug: 32934848
Test: manual, enter the password too many times. The dialog should appear. Attempt to dismiss it by tapping outside the dialog. This should not happen.
Test: correctness of .setCanceledOnTouchOutside is outside scope.
Change-Id: Icff8bd9068f636c0a75decb787b8a5c9161a8cbd
Stacking them on top of each other like that does not count as defence
in depth and we should not do it.
Bug: 32934848
Test: make RunSettingsRoboTests # added one specifically for this
Change-Id: I9490652c05a630e7c3f9164a9144fadfc0f41ea1
When setting the accessibility title in confirm credential fragment, it
simply does nothing if the title is null. But for most of the confirm
fragment only have header and details, not the title. In that case,
nothing will be set. Changing it to use the supplemental text directly
if the title is null.
Change-Id: Id9fdebf04535ccc8f38a933758a7948ee2966fb4
Fixes: 30221638
Cause: with unified screenlock, ConfirmDeviceCredentialActivity didn't
forward result with FLAG_ACTIVITY_FORWARD_RESULT
Also, fixed that ConfirmDeviceCredentialActivity didn't allow fingerprint
authenication in unified screenlock after keystore unlocked.
In ChooseLockSettingsHelper, add one new util function to allow
extra option to set returnCredentials to false while external to true.
Set StrongAuth to "not required" when it has been successfully unlocked.
Test:
1. PO Unified Screenlock/Work Challenge x fingerprint -> ok to trust cert
(Also, no credential is returned in intent)
2. WorkMode off -> Reboot -> turn on Work mode
-> no fingerprint option, PIN unlock successful to turn work mode on
Bug: 28752364
Change-Id: I6dc8865e8f005545f8577d7731afb4495647062b
Instead of having a separate textview, we now reuse the detail textview
to show the hint.
Fix: 28204828
Change-Id: I3eff3240bf7ecb1495fbf11a073a273a0de603ae
Show a hint text to user noting that pattern/PIN/password is
required when decrypting the credential based storage when file
based encryption is turned on.
The hint text is the same as that of the device unlock screen after
device reboot.
Bug: 27964055
Change-Id: I0d5a493bab69eae5ce4742bd07d4851387863cac
SettingsPreferenceFragment has this already set so that the drawer
layout will work when the menu doesn't exist. However, some fragments
are not preference fragments, and we need to set setHasOptionsMenu
manually.
bug:27879503
Change-Id: I6faadeb56dab00af611ac413109800822038c66d
Entering the wrong credential in ConfirmDeviceCredentials should
also count as failed attempts for the password, after which the
DPC have set a restriction to wipe the work profile.
Fixed related issues, such as the CredentialChecker re-sending
the result after onResume causing additional attempts to be counted.
The new error message String is also displayed initially when there
are pending attempts to inform the user that they are not starting
from fresh.
Bug: 26677759
Change-Id: I70cfae4c05e705ad7fe93bc071426459b79e7d0c
Call into DevicePolicyManager to retrieve the background color that
should be used for the work challenge on the user whose credential
screen we're about to show.
Change-Id: I612dd96020ce8932b49b21e6ff6faaddd39f957d
If the challenge shown is for a work profile, add the default image and
color to the background of the fragment.
Change-Id: I148c6cd3a835a84c7bac78b020839dfdae4a6c36
When using ConfirmDeviceCredential as the Work Challenge, we sometimes
have intercepted a task launching from recents. In this case, read the
taskId given as an extra and request that task to be started from
recents instead of launching a new intent.
Change-Id: Icca92f246e8f025b64de1f138493fc4069f98829
Add support in the Confirm Credentials flow to read an Intent extra
and fire it when authentication succeeds.
This is part of the Separate Work Challenge feature.
Change-Id: I52c203735fa9b53fd2f7df971824747eeb930f36
- New strings in the screen.
- New layout/style.
- Clean up internal API's around it.
- Add fingerprint support if launched from externally
- Separate theme if launched from externally
- If launched from above Keyguard, use SHOW_WHEN_LOCKED flag
Change-Id: Icdf9bf9e0506841f24e8aab5f0f1d1f4b688951f
