Cherry-pick of 436256c36d
Test: 1) make and run SettingsTests. It passes.
2) Manual test 1
a) On a device supports fingerprint, set a password but not fingerprint.
b) adb shell am start -a android.app.action.SET_NEW_PARENT_PROFILE_PASSWORD
c) Confirm Lock password screen is shown
d) Select "Skip fingerprint". There isn't a second lock password confirmation screen.
e) A new password can be set successfully.
3) Manual test 2
a) Repeat step 2)a) - 2)c)
b) Select "Fingerprint + PIN". There isn't a second lock password confirmation screen.
c) A new password and fingerprint can be enrolled successfully.
Bug: 33059280
Change-Id: I1078c6e303fc41aeeb370e5d6518d1f16b5837f1
Merged-In: I1078c6e303fc41aeeb370e5d6518d1f16b5837f1
+ This is caused by the encryption interstitial result code not handled
in ChooseLockGeneric. Change the request code of launching encryption
interstitial screen to CHOOSE_LOCK_BEFORE_FINGERPRINT_REQUEST if it
is set new password flow.
Testing
Test: See below
1) Auto
make RunSettingsRoboTests
2) Manual
On a device (Nexus 5x) that shows encryption interstital screen and
supports fingerprint.
1) Nexus imprint flow (regression test)
Fingerprint can be enrolled with the following flow.
Settings > Security > Nexus Imprint > FingerprintEnrollIntroduction
> ChooseLockGeneric (Unlock selection) > Encryption Interstitial
> Password setup > Notification Interstitial
> Find sensor and fingerprint enrollment
2) Set new password test
i) $ adb shell am start -a android.app.action.SET_NEW_PASSWORD
ii) Click Nexus Imprint + Pattern.
iii) Choose "Require pattern to start device"
iv) Set a pattern lock.
v) Choose any of the notification behavior.
vi) Can enroll a fingerprint.
Bug: 32382952
Change-Id: Ie66ffca2e8c3cc46b5e8b619bd35986e4f41d5ab
When the Direct Boot tests go to remove the PIN set in previous
tests, it needs to find the option that will remove the PIN. Recent
changes for fingerprint caused this "none" option to be hidden, so
assign the "none" ID to the "skip" option.
Test: cts-tradefed run cts-dev --module CtsAppSecurityHostTestCases --test android.appsecurity.cts.DirectBootHostTest
Bug: 31160946
Change-Id: I0b34cbfae45d1db8ee58a5ef66738414f5e2fc27
Cherry-pick from ag/1444396
1) Added a trampoline activity to display SET_NEW_PASSWORD intent.
2) On devices that have fingerprint sensor and have no enrolled fingerprint,
ChooseLockGeneric handles the SET_NEW_PASSWORD intent by providing
fingerprint + {PIN/PATTERN/PASSWORD} and skip fingerprint options.
Test: See below
1) Auto
make RunSettingsRoboTests
2) Manual
a) Fingerprint + pattern
i) $ adb shell am start -a android.app.action.SET_NEW_PASSWORD
ii) Click Pixel Imprint + Pattern.
iii) Set a pattern lock.
iv) Can enroll a fingerprint.
b) Pattern
i) $ adb shell am start -a android.app.action.SET_NEW_PASSWORD
ii) Click Continue without Pixel Imprint
iii) A list of unlock options, without fingerprint option, is shown.
vi) Select and enroll a pattern lock
c) Has an existing password
i) $ adb shell am start -a android.app.action.SET_NEW_PASSWORD
ii) Setting app asks for password input.
iii) Enter password and click "Continue without Pixel imprint".
vi) No password is asked. A list of unlock options, without fingerprint option, is shown.
v) Select and enroll a pattern lock
d) Work profile
i) Create a work profile
ii) adb shell am start --user x -a android.app.action.SET_NEW_PASSWORD. X is the work profile user id.
iii) Click Pixel Imprint + Pattern.
iv) Set a pattern lock.
v) Can enroll a fingerprint.
Bug: 23017051
Change-Id: I6384bbffb72a5d3a83972da7474532746e4d06b9
Some preferences aren't available due to DPM, so check for null
before setting the title.
Fixes bug 31184335
Change-Id: I69f97274eef87755269fd8f7897edcc36087f8b2
When Intent ACTION_SET_NEW_PASSWORD is called from a managed profile,
ChooseLockGeneric fragment shows title "Unlock Selection", update that to
"Choose work lock".
Bug: 28451356
Change-Id: I9bcf4698557fa453337aa666f10f94f15e7624fa
- cleaned up private API to ensure userId is distinct from groupId.
- fixed bug where we were sending the wrong userId when attempting to
- fix warning about wrong fingerId when receiving final id of 0.
Fixes bug 28268635
Change-Id: Ic8abfbf6fbf173db2d57a76ac2e38b2a71ffd19e
Add hooks for adding an option for selecting a managed password as
lock credential. By default this option will not be visible.
BUG=27923581
Change-Id: Id17bd8074bf23cbcffb96d8576cc760df6f2298a
Changes:
(1) When unified work challenge is enabled and screen lock is secure
- Store work profile secure key in primary profile
- When primary user keystore unlocked, unlock work profile keystore
- When primary user change lock to none, remove work secure key
(2) When unified work challenge is enabled but screen lock is not secure
- When screen lock changes to secure, store work secure key in primary
(3) When user changes work challenge from unified to separated
- Remove work secure key in primary
(4) When user changes work challenge from separate to unified
- Do (1) and (2)
Bug: 27460698
Change-Id: Id7464c178e6ea7b561643477e7cd84f963048c87
This is a partial fix for b/27903189.
When we remove the lock screen and remove all fingerprints, wait for
them to all be removed before finishing the activity. This will let
the security screen accurately show how many fingerprints are available.
bug:27903189
Change-Id: I30908dbefb7a858f6d99e532841ed4ff894bfe62
When ChooseLockScreenGeneric is started via the set password
intents, it should not allow the drawer menu to show.
bug:26288300
Change-Id: I10d512e20fedab2be8c725c7d524db0c55666590
When enrolling fingerprints on both personal and work and then setting
the lock to none or swipe, the fingerprints for that user were not being
correctly removed due to wrong userIds being passed in.
Also fix the wipe dialog message as it was always querying whether the
main user has fingerprints instead of the user the dialog applies to.
Bug: 27263452, 27199237
Change-Id: I8d170e36f31b5595bc0bb41168a87db9f57eda2f
This also adds frp warning dialogs in case the user skips lock
screen setup initially.
bug:26880444
Change-Id: I732b6a806e139fb6c1c1b334b8d1608c229f217c
This will make sure the headers are set before the underlying
RecyclerView has made its first layout, and prevents an animation
from playing when rotating to landscape.
bug:26990364
Change-Id: I2838a07a145b4d6136e88125ab955006d84d135c
Some invocations of ChooseLockGeneric are done with arguments, but
when invoking it from FingerprintEnrollIntroduction we add the extra
to the activity intent so we need to support both.
Bug: 26901625
Change-Id: Iaabad18bf17160578f6b6d807dc6acfead1ba419
And when adding accounts if only one account type is possible and
it is disabled by admin, show the admin support dialog.
Bug: 26897250
Bug: 26767564
Change-Id: I5cca64491a100efc34307c45aa35c14412f043cd
Fixes a bug where if you upgrade a device with screen lock,
screen lock suggestion would show (upgrade such as N->N developer
builds) or from a user test case like M->N
bug:26844580
Change-Id: Ic779ff28f5895e407c2c96771dbbc622e6026a7f
Also, fixes a bug where the suggested activity stayed on screen
after the component was disabled causing a crash.
bug:25246207
bug:26770556
Change-Id: I28d784cdc57e464e49887483690ab514ca3bc46a
This reduces the # of screens, and makes the backup lock choice
for fingerprint more obvious that it is a backup.
bug:26377096
Change-Id: I4e75e1f3302c286587de106bcdf43537bda03390
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
- When in a unified state, selecting the work lock to be "none" caused
a security exception
- When the work lock was set to "none", unifying didn't work
- When in a unified state, the work lock type selection screen showed
"none" as the current type instead of the device lock type
Bug: 26577247
Change-Id: I853d77186e23b6a458eaa6c1047942a7eefddc9c
If the challenge shown is for a work profile, add the default image and
color to the background of the fragment.
Change-Id: I148c6cd3a835a84c7bac78b020839dfdae4a6c36
Have ChooseLockGeneric resolve the new intent that allows setting the
parent challenge. If the new intent is received or seperate work
challenge is not supported, default to setting the challenge of the
parent user, otherwise use the calling user.
Change-Id: Ibd0ce8ce81b1d5c9073d4eb0096fdc74de12ee95
Create a new section in Security Settings which includes all
settings for the Work Challenge.
Only some settings apply to the Work Challenge, so we reuse
the security settings layouts for items and compare them against
a whitelist to remove unwanted items.
Additionally, remove all usages of ChooseLockGeneric.KEY_USER_ID
in favor of Intent.EXTRA_USER_ID.
Change-Id: I3d1ba953a2056f7c61a7b3feeb8b49f1a352dff6
Modify the back stack and result code propagation in the screen lock
scenarios.
- EncryptionInterstitial now propagates the result of ChooseLock*
request instead of always returning RESULT_OK.
- ChooseLockGeneric now treats CHOOSE_LOCK_REQUEST and
ENABLE_ENCRYPTION_REQUEST the same (since encryption can be a proxy
for ChooseLock*). This means ChooseLockGeneric will now stay on
back stack when going back from ChooseLock*, just like the case
(indirectly) through EncryptionInterstitial.
Bug: 26177240
Change-Id: Id7f1256dcbff00d552a3e7db60c285f53f1e63e6
When the user changing passphrase is not the process' user, disable
the "Ask for password on device startup" screen, as it makes no sense.
Change-Id: I521b5ec8702f7a39b94012a606794e04135e4c75
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
