Use fingerprint icon when lock screens are loaded on
fingerprint setup's behalf.
bug: 63809908
Test: Manually tested and verified. Also added robolectric tests
Change-Id: I773a1eec2466e7ab626cc3330f5ce987a21b048f
Currently The activity not requesting showSoftInput() and hence keypad
doesn't show up.
Activity.onResume(), we should call ImeAwareEditText.scheduleSoftInput()
to request schedule ShowSoftInput() when EditText gains focus.
Fixes: 63582564
Test: Manually launch com.google.android.setupwizard/.SetupWizardTestActivity
Change-Id: Ib75ba0f361b8b46c3b717cc1ffb864726958ed82
The ConfirmLockPassword screen (responsible for both PIN and password
locks) should not accept any input during the lock-out period after
consecutive incorrect unlock attempts. However, this is broken if the
activity is resumed from a paused state (e.g. from Recents).
In this CL, we clean up the logic around updating the UI controls, which
fixes the issue above and also hopefully simplifies potential future
work.
Bug: 63277910
Test: make RunSettingsRoboTests
Test: manual, both unified and separate work challenge
Change-Id: I752a5911d4445bf0caeea299ca3eb182e1defc62
Due to incorrect strings, we temporarily disabled the prompt strings for
strong auth and instead used the generic ones as a short-term fix. In
this CL, we correct the strong auth prompt strings and add them back to
the lock screen UI. The new strings are in line with those in keyguard.
Bug: 36511626
Test: manual
Test: make RunSettingsRoboTests
Change-Id: Ifba689db37cc7d331eb1a774814f6b6235977ff9
Hide the screen lock options button in the confirmation stage of
SetupChooseLockPassword, so the user cannot skip out of that screen
while the screen lock is being saved.
Test: Manual
Bug: 63526104
Change-Id: I8ee8938f3ddcd9f0ff3b1812fcae667eddaf09ab
These screens are used whenever setting or confirming the
lockscreen PIN or password. Set them to a consistent textSize (24sp)
and a consistent fontFamily.
Would have set the fontFamily in the style, but unfortunately
setInputType is called on the TextViews after inflation which blows
away the fontFamily. Instead, we set it in code right after that
call.
Change-Id: I77c3f94e2b1ce6d1f19697394c5caa09aac423b0
Fixes: 62873478
Test: manual
The prompt strings on the confirm credentials screen (pin, password,
pattern) are incorrect. They currently say strong auth is "required
after device restarts". But instead they should be "required for
additional security" because strong auth can be enforced not only after
device or profile restarts, but also after profile key eviction, for
example.
Unfortunately, we've already missed the window for string changes.
Therefore, as an alternative, we use generic prompt strings in this CL,
to avoid conveying the incorrect (and misleading) information. We'll
follow up with another CL in master with a proper string change to fix
the issue.
Bug: 36511626
Test: manual
Test: make SettingsRoboTests
Change-Id: I44f84420b88bb4933ad0afa6e8032af465de0cd3
Move the applyThemeResource calls up from the setup wizard specific
subclasses up to the settings classes so that it will get GLIF v2
theme on devices that request it.
Test: Manual
Bug: 62906814
Change-Id: I6ff4ff8d9ed3e6090b35b4ae7197e5d01f5a61f8
- "Continue" in choose lock flows are renamed to "Next"
- "Done" in fingerprint enroll finish screen is renamed to "Next"
during setup flow.
Test: Manual
Bug: 62839648
Change-Id: I3ea77b759b654d7c1da1f7b545781c9dfd74caa3
So that setup wizard can show PIN option by default.
Test: Added Robolectric and instrumentation tests
Bug: 38509560
Change-Id: Id72744dd444b9b026ca5f28f230bae3bec254b2f
(cherry picked from commit 0f897d79f6)
Both View focus (which is triggered by View.requestFocus()) and IME focus
(which is internally handled inside InputMethodManager), are implemented
as delayed tasks on the UI thread. The goal here is to make sure that
InputMethodManager.showSoftInput() always gets called only after the target
EditText gained IME focus.
This requires some tricks, but is basically a solved problem with
ImeAwareEditText introduced by
I182b05d3ff59fb3b4732d60d0d5a464f0e0e0235. Here we can just reuse it.
Note that ConfirmLockPassword & ChooseLockPassword are the only ones
using ScrollToParentEditText. Latter doesn't call IMM.showSoftInput().
Fixes: 62542157
Test: Verified keyboard still shows-up on the ConfirmLock screen.
Change-Id: I892d639f3cc5d43db553b682d5278b8ce2fe72da
When setting up fingerprint's backup screen lock, show a different
header text that says
"To use fingerprint, set {PIN/pattern/password}" instead of
"Choose your {PIN/pattern/password}".
Test: Manual. Existing tests pass
Bug: 62187833
Change-Id: If1084e64b99291a0eda63c174793b5a091ab4bae
Bug: 36814845
Test: adb shell settings put global device_provisioned 0 && adb shell am start -a android.app.action.CONFIRM_FRP_CREDENTIAL
Change-Id: Id6ce6bc5ebd9c9e2a88790cc800678aff50e580f
Instead of a separate headerText view, change the header in the
GlifLayout directly.
Test: Manual. Existing tests pass
Bug: 38180862
Change-Id: I02d692870f5e2230ccae87a5ac2aee4def8f61af
- Add icons to items in choose lock dialog
- Add title to the dialog
- Update the font size and color to match specs
Test: Manual. Existing tests pass
Bug: 38394440
Change-Id: Ie7ed9944b71fa5ca408ec6898f49cbd36865a1dd
Previously, failed ConfirmDeviceCredential attempts only counted towards the
wipe limit if it is used as a separate work challenge.
In this CL, we additionally make these failed attempts count towards the total
failures in the following scenarios:
1) when unified work challenge is enabled
2) for the primary user (e.g. when a wipe limit is set by a DO)
3) for secondary users
Bug: 27238008
Test: manual, by entering wrong credentials multiple times
Test: make SettingsRoboTests
Change-Id: Ie5a099bb3fd46245c13ccf4c8f91c4d935412a4e
- Added "Screen lock options" button in PIN screen, controlled by
extra EXTRA_SHOW_OPTIONS_BUTTON, which will create a dialog to ask
the user to choose another screen lock type.
- Extracted ScreenLockType enum and ChooseLockGenericController that
can be shared by ChooseLockGeneric and the dialog
ChooseLockTypeDialogFragment.
- The intent extra EXTRA_SHOW_OPTIONS_BUTTON will be set if
ChooseLockGeneric screen starts ChooseLockPassword /
ChooseLockPattern without asking the user. (Although the extra is
ignored by ChooseLockPattern currently)
- Fix layout alignment for the password entry field to remove the
extra 4dp padding on the sides.
Test: cd tests/robotests && mma
Bug: 35442933
Bug: 38002299
Change-Id: I877fbe08a0c05bb97175e1cbf0260ea6dbda22e2
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
1. Aggregate policies and generate the requirements
2. When user modifies the password, check is each requirement fulfilled
Update the view accordingly.
Change-Id: I962ed3b81ce844006be1024a493e94ce52a3fdec
Fix: 24900754
