In order to apply different styling to security methods,
we need getLayoutIdFor() to be protected instead of private.
Change-Id: Icc92240eec763c910ef334c22ff4b92fcdd83fe8
The menu key was not unlocking the keyguard properly
and didn't hide the notifications.
Bug: 26539875
Change-Id: I9dd89767f00d29c15d1d4e840a1ab22d59e58c8d
This change enables relaxing the constraint by which
strong authentication is needed after device reboot.
There are very limited use cases where this might be
safe, one of which is in a car. Cars head units usually
are protected physically by the car and have hardware
anti-theft mechanisms so we can potentially allow for
Android to allow users to use smart unlock to avoid the
lockscreen just after boot.
This change adds in a config flag that sets the default
trust flags, which can be set to allow smart unlock after
boot for car head units.
Bug: 26559008
Change-Id: Id6338a97b617ddaf3d2fae5d51235429a42b81cc
Tracks why trust agents are disabled and shows
a generic message on the keyguard. Dedicated strings
in follow-up.
Bug: 22704995
Change-Id: Ibb4fd9c9386c4dc12f0734004502b9a9cc6ded79
Do not dismiss keyguard if KeyguardUpdateMonitor.getCurrentUser() is
changed during the async credential check.
Bug:26415736
Change-Id: Id7e04c7100e0920fe86fe006840928a936f62dd8
Also takes into account the voltage
at which we charge to make speeds
at different voltages comparable.
Bug: 25229483
Change-Id: I62a192932a013036585cd9fc870808debceac0d3
Display the device owner information if it has been provisioned by
DPC via DevicePolicyManager, else fallback into displaying the
current user owner information (if set).
Change-Id: Ie915d6669ecac06bfa7b57079b9dcd0fac56df57
Stealth mode is not guaranteed to remain constant through keyguard pattern
view lifetime (it's user specific, and user context may be switched), so
update it when keyguard pattern is reset.
BUG=25017442
Change-Id: I798fe685cfaadd35462f54ab7e4fa9e6f6276436
When going over the handler, it could happen with a bad interleaving
we thought that Keyguard was not showing when getting the
onFinishedGoingToSleep message, so we stopped fingerprint
authentication. For some reason our state machine for canceling
/restarting authentication didn't work correctly so the fingerprint
listening state was not correct.
Bug: 24178814
Change-Id: I2a4731f195982395244c12e4d33b2b7d561c5671
We used to start fingerprint authentication in onFinishedGoingToSleep.
This was a UX issue because then users couldn't place the finger on
the sensor immediately after pressing the power button because
onFinishedGoingToSleep is significantly delayed (around 900ms after
pressing the power button).
Bug: 23570959
Change-Id: I0bf557ebd10e6a8b033ab98a78aa338bf6538dcc
To make unlocking work if keyguard is in occluded state and user
taps on a notification.
Bug: 22855718
Change-Id: Ide632f524a635e3e37741abaa77e258394c9a6e2
If you tap the enter key twice on the keyguard PIN entry
screen, the second tap can sometimes register because keyguard
hasn't been dismissed yet. The fix is to ignore a second attempt
after the PIN has already been verified.
Fixes bug 19216025
Change-Id: I73a004e91e43f3da65ec84f90de6943e717d737f
Split off from I0af11da1b7cd7c8d837bc5ba3a62ef2ffca74b1b.
The initial value did not matter previously because
a SystemUI crash triggered the boot logic and forced
a manual entry before fingerprint works.
Long term the timeout logic should be moved to StrongAuthTracker
so it can be shared with the trust agent implementation (currently
implemented by the trust agents themeselfes)
Bug: 22846469
Bug: 22115393
Change-Id: I0af11da1b7cd7c8d837bc5ba3a62ef2ffca74b1b
When calling cancel() on the cancellation signal, it doesn't happen
immediately. Now, because of a state messup during boot, we go
through the sequence
startListeningForFingerprint
stopListeningForFingerprint
startListeningForFingerprint
However, the cancellation callback from stopListeningForFingeprint
happened AFTER the second startListeningForFingerprint, so we assumed
that fingerprint detection was not running anymore but in reality it
was - leading to weird states and all kinds of small state messups.
Introduce a state machine to track when we we called cancel but
waiting for the confirmation of FingerprintService in order to track
this properly.
Bug: 23380500
Change-Id: I403479fb749cf7c22b73611b69698e8b771777d0
After gettin a callback onAuthenticationSucceded we set the
fingerprint listening state to false. However, when waking up, we
immediately started listening again because the state was false.
Protect against that by only calling authenticate only once, except
when the unlock doesn't go through because unlocking with fingerprint
is not allowed.
Also fixes some animation "jank" because of the state messup.
Bug: 23304421
Change-Id: Ic83ac0f1590dd4f8017bb55dca9e19a60cfdf99f
- Move all fingerprint related to logic in on central class in
SystemUI that knows all the state of the UI so there is exactly ONE
place in which we decide what to do when we acquire a fingerprint.
- When pulsing and we get a valid finger, we fade the contents of the
Keyguard out and fade the scrim out almost the same way as we would do
in a normal wake-and-unlock sequence.
- Hide shadows while dozing, so we don't see the artifacts when we fade
the dozed Keyguard out.
Bug: 23225107
Change-Id: I82f78e61f2530cf7d507ade80f6f0a340c082567
