The messages in ConfirmDeviceCredentials have been updated to
inform the user that the pattern/pin/password to be entered is
the profile one.
The strings in the confirmation dialog when the user removes
the lock have also been updated.
Ideally we would have a parametrized approach to strings here,
but capitalization makes it a hard problem.
Bug: 26706338, 26709116
Change-Id: I9f5508d6f449f9e572d65e5b2dcb15cca23832b3
If the challenge shown is for a work profile, add the default image and
color to the background of the fragment.
Change-Id: I148c6cd3a835a84c7bac78b020839dfdae4a6c36
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
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
- Add a CheckLockResultTracker to track result of async lock check so that
it can finish on configuration change;
- Let the pending lock check finish and ignore subsequent check requests;
- Add a mDisappearing flag to prevent running disappear animation
multiple times;
- Check whether activity is still active after disappear animation
before setting result and finishing it;
- Remove no longer used mNumWrongConfirmAttempts;
Bug:23190499
Change-Id: If1784d3d1fcc152ac06137b12748b9def5726692
This makes Talkback in ConfirmLockPattern works similarly as
in ConfirmLockPassword to read out error messages.
Bug:20282779
Change-Id: Ied05c284e959539cfbff965f33edd51c3bdfc9f9
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
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
- the EXTRA_NO_HEADERS flag as no more meaning as we are showing
the Tiles (previously named "Headers") only in the Dashboard
(which is the main Settings screen)
Change-Id: I55656de0d28ca9c84adbe6647d870838b4ac230b
- get rid of PreferenceActivity as much as we can and use fragments instead
- add Drawer widget
- add Dashboard high level entry into the Drawer (but this is work in progress and would be done in another CL)
- add bypass of fragment's Header validation when launched from the Drawer but *force* validation if external
call thru an Intent
Be aware that WifiPickerActivity should remain for now a PreferenceActivity. It is used by SetupWizard and should
not trigger running the SettingsActivity's header building code. SetupWizard is a Home during the provisionnig process
and then deactivate itself as a Home but would make the Home header to appear in the Drawer (because momentarily we
would have two Home).
Also, verified that:
- the WiFi settings still work when called from SetupWizard
- when you have multiple Launchers, the Home header will appear in the list of Headers in the Drawer
Change-Id: I407a5e0fdd843ad7615d3d511c416a44e3d97c90
Also re-orders updateStage() and setText/Selection calls so that text
events don't flush announcements. This does not change functionality.
Bug: 7256500
Change-Id: I8b10d66e9f73c7a630a8c3c5128372e18f26234c
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 converts most of the existing activities to fragments and wraps
them in PreferenceActivities so they can be launched as before
(e.g. by a DevicePolicyManager)
Upload after sync/rebase.
Change-Id: I4f351b75d9fca0498bcb04b4e11ff3b70765a4ba
