This is a first step to allow this flow to be reused for setting
a work profile-specific lock, to be used with the work challenge.
Change-Id: Iaa65fdab9021cda5f0a1d3bc526a6b54f8a7dd16
Make sure to finish ConfirmDeviceCredentialActivity directly, and use
Intent.FLAG_ACTIVITY_FORWARD_RESULT, so we can't even end up in a
state where we have the trampoline activity but not the real activity.
Bug: 23849216
Change-Id: I7a5be5af74ca85c11df1f61a69c3fd5cf558e1fb
Change the message for encryption interstitial when enrollin
fingerprint, to make it clear that fingerprint unlock is still used,
just that the backup unlock PIN / password / pattern will be needed
to start the device.
Bug: 22559146
Change-Id: Ia134e0d9b118151833a9118ff44667dcc9122185
ConfirmDeviceCredentialsActivity and ChooseLockGeneric now understand
CLSH.EXTRA_KEY_HAS_CHALLENGE and CLSH.EXTRA_KEY_CHALLENGE in their
launching intents. If present, they return a hw_auth_token_t verifying
the challenge passed in as a field in keyed by
CLSH.EXTRA_KEY_CHALLENGE_TOKEN in their result intents.
Change-Id: I0b4e02b6a798a9e57d02522880a180dffadfcde1
- 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
The correct method to call is isLockPatternEnabled, which
also checks whether we've actually selected a pattern.
Also removes the code for the obsolete pattern enabled setting.
Bug: 18931518
Change-Id: I6f369eb60f8f6bb1e33384cd06534c713ab52e79
When an accessibility service is enabled we are not using the user secure
lock when encrypting the data. If the latter is already used for encryption
we are decreasing the encryption level and therefore shall challenge the
user with their secure lock.
bug:17881324
Change-Id: If8905c05e20bc6bb6a6415e501871e5ad83f3d86
ConfirmLockPattern and ConfirmLockPassword return an intent that contains the
password, and as such are dangerous. Create internal versions that are locked
down, and don't put this info in the externally accessible versions.
Bug: 13741939
Change-Id: I0df4d1e720b3c33d2c9ca086636dc54f17b19bf0
This adds a feature to allow DevicePolicyAdmins to prevent using
simple PINs, which are defined as those containing more than 3
repeated values. Examples include '1234', '2468', '1111', '9876', etc.
Bug 12081139
Change-Id: I68d8fe2459837cb5e083724e1740e65f0519f7e1
As noted by the class javadoc, CredentialStorage has seen the number
of cases to cope with grow. This change tries to address those cases.
src/com/android/settings/CredentialStorage.java
Added ChooseLockSettingsHelper.EXTRA_KEY_PASSWORD to coordinate
additional producer and consumer.
constant declaration here, since its used by callers of
ChooseLockSettingsHelper.launchConfirmationActivity
src/com/android/settings/ChooseLockSettingsHelper.java
old producer
src/com/android/settings/ConfirmLockPassword.java
new producer (CredentialStorage wants passwords and patterns)
src/com/android/settings/ConfirmLockPattern.java
new consumer
src/com/android/settings/CredentialStorage.java
old consumer
src/com/android/settings/CryptKeeperSettings.java
Made class final and removed protected from method to make it clear
ChooseLockSettingsHelper is not to be used by subclassing.
src/com/android/settings/ChooseLockSettingsHelper.java
Change-Id: Ib2d65398fe44573168a6267a0376c3b0388b16c8
This fixes a bug where user was allowed to factory reset the device
without entering their PIN/Password.
It also fixes the same issue with MediaFormat (Settings->SD Card->Format).
Change-Id: I0677a50aa771ad8663513fd7ec398a70953dcde2
