Use GLIF theme as the default for confirm lock screen, even for
"external" launches of the screen. Renamed the theme from "internal"
to "normal" to reflect this change.
Dark theme code will be cleaned up later.
Test: Existing tests pass
Bug: 62573742
Change-Id: I86958eb3a440d7274807f1cf453c3e53c16c23e7
- for fragments that do not implement the preference screen, change them
to inherit from InstrumentedFragment instead.
Change-Id: I791c2634024bd2c248efea955be5c680180d735c
Fixes: 68277111
Test: make RunSettingsRoboTests
When the user enters a wrong pattern/pin/password, a "Wrong
pattern/pin/password" text shows up on ConfirmLockPattern or
ConfirmLockPassword screen. In ConfirmLockPassword, it disappears
automatically after 3 seconds, whereas it doesn't in ConfirmLockPattern.
In this change, we make the prompt in ConfirmLockPattern disappear
automatically as well.
Bug: 64781905
Test: manual
Test: make RunSettingsRoboTests
Change-Id: I53a25576413671ced4197064d51fbcc397733265
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
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
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
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
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
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
