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
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
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
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
Always throwing RemoteServiceException would make it impossible to
tell the cause of a crash without the string message.
Let's use a different exception type so developers can cluster crashes
without the exception message.
Bug: 124137635
Test: Treehugger
Change-Id: Ibae57bdb1b8965241c41249a89c728d224e4e995
The choose screen lock page didn't apply the right theme during the
enterprise flow. That is because an intent extra of setup wizard wasn't
properly passed to the next page. In this change we made sure the intent
extra is able to properly pass to the next page.
We also removed the wrong theme for setup choose a screen lock page
since the wrong theme made this page broken. The setup choose a screen
lock is a sub setting page that wasn't implemented by using SUW library,
so it should not use GlifLayout theme. With this update, the choose a
screen lock page still keeps the background color of Settings, that is
different from the one of setup flow.
Bug: 190499041
Test: manual test
Change-Id: I9dceee6a398c7e7b487dd8e4046f71f76cc50e36
When set, only enforce password requirement explicitly set device-wide.
As part of the change, restructure the code such that ChooseLockGeneric
becomes the central place for aggregating password requirements from
different parties, while ChooseLockPassword only enforces whatever
password reuirement it is told (by ChooseLockGeneric via intent extras)
Bug: 169832516
Test: m RunSettingsRoboTests ROBOTEST_FILTER=com.android.settings.password
Change-Id: I0acbea4819c13d4a8444c7b06928baccead18837
The device management app may run before the end of device provisioning,
and it may start SetNewPasswordActivity. If this happens, use
ChooseLockGeneric instead of SetupChooseLockGeneric. Only use
SetupChoseLockGeneric if SetNewPasswordActivity was started by Setup
Wizard itself.
Fixes: 151552453
Test: atest com.android.settings.password.SetNewPasswordActivityTest
Test: atest com.android.settings.password.ChooseLockGenericTest
Test: Manually run consumer and enterprise device setup
Change-Id: I3b479ed18211d6625654f266fe692f07d0047e4f
- Search box is hidden if user set intent extra isSetupFlow true
Fixes: 135717823
Test: search box is hidden in the following command
adb shell am start -a android.settings.SETTINGS --ez isSetupFlow true
Change-Id: Ia3d955c9390d6b0eef9391b9b35b6a483eb63d26
If the calling app has admin rights (DA/DO/PO), don't display footer
text that the calling app is 'recommending' that a password is set.
Fixes: 131888973
Test: atest com.android.settings.password.SetNewPasswordActivityTest --verbose
Test: atest com.android.settings.password.ChooseLockGenericTest --verbose
Test: manual
Change-Id: I32785d33e6425416fc1dbba24540ece8917b58f3
This is to match the method name "getPasswordComplexity" as requested by API review feedback
Bug: 128030136
Test: N/A
Change-Id: Ia4ce1b0ceb581608615364b41a05ca71142ef2b7
Every launch of the activity with either ACTION_SET_NEW_PASSWORD
or ACTION_SET_NEW_PARENT_PROFILE_PASSWORD is logged, regardless
of whether extra EXTRA_PASSWORD_COMPLEXITY is used or whether
the caller has the required permisssion or not
- action: ACTION_SET_NEW_PASSWORD or
ACTION_SET_NEW_PARENT_PROFILE_PASSWORD
- pageId: SET_NEW_PASSWORD_ACTIVITY
- key: calling app package name
- value: raw value of intent extra EXTRA_PASSWORD_COMPLEXITY, or
Integer.MIN_VALUE if it does not exist
Bug: 120840632
Test: atest packages/apps/Settings/tests/robotests/src/com/android/settings/password/PasswordUtilsTest.java
atest packages/apps/Settings/tests/robotests/src/com/android/settings/password/SetNewPasswordActivityTest.java
Change-Id: I57dc55110f7f284ddad7d3fc971d1f2298b46cbd
When an app that has the permission GET_AND_REQUEST_PASSWORD_COMPLEXITY
launches ACTION_SET_NEW_PASSWORD, it can use the DPM PASSWORD_COMPLEXITY_*
constants to specify the complexity it wants in a new extra
EXTRA_PASSWORD_COMPLEXITY.
The screen lock type picker would then filter out the options which
cannot fulfil the min complexity (and DPM restrictions) and will show a
footer with a brief description of the calling app and the requested type.
The same password requirements UI is used in ChooseLockPassword screen
to display the minimum requirements that can fulfil both DPM
restrictions and the min complexity.
The app must have permission GET_AND_REQUEST_PASSWORD_COMPLEXITY
otherwise the extra would be ignored.
ACTION_SET_NEW_PASSWORD is also updated to always display the calling app
name in the screen lock type picker if it is not launched by Settings,
with or without the new extra.
Bug: 111173457
Test: atest packages/apps/Settings/tests/robotests/src/com/android/settings/password/ChooseLockGenericControllerTest.java
atest packages/apps/Settings/tests/robotests/src/com/android/settings/password/ChooseLockGenericTest.java
atest packages/apps/Settings/tests/robotests/src/com/android/settings/password/ChooseLockPasswordTest.java
atest packages/apps/Settings/tests/robotests/src/com/android/settings/password/PasswordUtilsTest.java
atest packages/apps/Settings/tests/robotests/src/com/android/settings/password/SetNewPasswordActivityTest.java
atest packages/apps/Settings/tests/robotests/src/com/android/settings/password/SetupChooseLockGenericTest.java
manual test with TestDpc (ag/5901733)
Change-Id: I21a25d28669bf1223c3b02ba85c0755e59feee2e
Consolidated the many variants of ChooseLock*.createIntent, so that
it will take the same set of arguments.
Also modified SetupChooseLock*.createIntent to modifyIntentForSetup,
which will take the intent created by ChooseLock* and modify it for
use with setup.
Test: cd tests/robotests && mma
Change-Id: I5ff033f459c33ec9980872a536b3996d89f2bbbb
Context.getActivityToken is introduced since O.
To align with MR2 and avoid unnecessary merge conflict,
pass the activity token from activity to controller.
Test: 1. make RunSettingsRoboTests
2. Manual Test
a. Start SET_NEW_PASSWORD intent in user 0, set password.
User 0 password is set.
b. Start SET_NEW_PASSWORD intent in work profile, set password.
work profile password is set.
Bug: 32959373
Change-Id: I8577752d446a7c395ad30417f8c0c832f951d7b3
Problem:
SetNewPasswordActivity is the new entrance for
ACTION_SET_NEW_PASSWORD. And it starts ChooseLockGeneric with the
fingerprint extras. ChooseLockGeneric infers which user is starting it
and determine which user is setting password. However, it now always
think that it is current user as it is always SetNewPasswordActivity
in current user starting it.
Solution: Resolve the user id in SetNewPasswordActivity and forward it
to ChooseLockGeneric. SetNewPasswordActivity needs to know the user id
anyway in order to have the fingerprint checking in the correct user id.
Test: 1. make RunSettingsRoboTests
2. Manual Test
a. Start SET_NEW_PASSWORD intent in user 0, set password.
User 0 password is set.
b. Start SET_NEW_PASSWORD intent in work profile, set password.
work profile password is set.
c. SET_PROFILE_PARENT_NEW_PASSWORD is always setting parent
password.
d. If fingerprint is disabled, both intent should not show
fingerprint option
e. DO sync auth flow with google.com account, fingerprint option
is shown.
Change-Id: I2f73d01ab11e91b337beb90c05bbcb857dfd40dc
Fix: 32959373
The trampoline currently always uses the settings style for set action
new password. When called during setup wizard, it should launch the
setup wizard style.
Test: Added robotests for launching activity and copying setup wizard
extras. Also manually tested with an application when device is
provisioned and not provisioned.
bug:32575389
Change-Id: I5763eb87b63a46b05cd200bb73b15bdc24c8bd3b
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
