Bug 7453429
Change the detection of sliding the security view to require crossing
the border between sections in the correct direction. This also
improves the feel of re-opening the slider.
Change-Id: I57797f926e017ea2cf41f7c48e0fe77ac0f78460
FUL is suppressed when first booted and unsuppressed when the user
leaves keyguard (by logging in or turning the screen off). However,
if the user managed to enter the phone without going through
keyguard (security set to none, or initial device setup), FUL was
not being unsuppressed and it would not show up the first time the
user tried to use it.
This fix only suppresses FUL on first boot if it is the selected
security method. Therefore, it is not suppressed the first time it
is used after setting it up.
Change-Id: I766bbce31ce3939de97661623fe3b8d3fa29c20d
Added a check in pattern and PIN to showed the face unlock max attempts
failure message if that had been reached. The max attempts can only
be true if face unlock is enabled so it doesn't need to also check if it's
enabled.
Change-Id: If8a26498961d79fa6a647abc923c72f0af407e61
Since the callback is unregistered in onPause(), KeyguardFaceUnlock
doesn't get onKeyguardVisibilityChanged() when it's paused. This means
that if the state changes while it's paused, then mIsShowing is incorrect
when it resumes. This is fixed by keeping track of the state in
KeyguardUpdateMonitor and checking it when onResume() is called.
Change-Id: I67aa1e091161a965e4347dc8c2ec5e7a1dd9d92e
Face Unlock would reappear when rotating a tablet after it had already
fallen back to the backup unlock method. This change suppresses Face
Unlock after going to the backup so it isn't seen again until the user
leaves and revisits keyguard.
This change also removes the exposeFallback() callback from Face
Unlock. It has been unnecessary for a long tiem since Face Unlock no
longer covers the backup. The Face Unlock service was therefore
making unnecesaary calls via the AIDL interface.
Note that the AIDL interface change broke obsolete keyguard stuff.
That is being deleted soon anyway, so code has just been commented out
of the obsolete files to make it compile.
Change-Id: Ia5c451cce1703b3bc03e27a35c6b38373e944d1b
We suppress FUL when the device first boots because with all of the
things happening at boot, we don't want to interact with the camera.
We also suppress it immediately after a user switch for the same
reasons. However, once the user turns the screen off, we want to
show FUL when they turn it back on. Prior to this fix it was only
being unsuppressed on login.
Note that this CL also removes the isFirstBoot flag. It was only
being set/checked when the suppress flag was set/checked, so it was
redundant.
This also addresses bug b/7450665, which is regarding the
user-switch case.
Change-Id: I2b39e85e21c08ef7629398521ab1159f5a6c7547
Integrate from proto app
Make sure you can drag back up immediately without the delay of extra
offset on the challenge view.
There are still a few further tweaks to make here that will be
dependent on another upcoming patch.
Change-Id: I6af599e43d6be6da7b431dca5b87e39c157a54df
Also, remove ability to filter widgets by feature
in appwidget picker in anticipation of api change
Change-Id: I325de0b98f03d3a250758d504229ea27794b5330
Integrate from proto app
Get some layout/alignment right between security views, bouncer,
etc. Expand the space available for the more cramped security views
when not in the bouncer.
Fix bug 7434391 - don't allow widget swiping in bouncer mode. Fix a
few other bouncer-related state tracking problems as well.
Use layers when moving the security view around.
Change-Id: Ied14bab8bb5c3d997c734a3ae657b766c427253f
The code was adding default widgets before setting mViewStateManager, which means the
callback from the transport control might access mViewStateManager before it's set.
Change-Id: I985a3c8062d0660519cb4a4c8c1b42c7c90f4ac7
