At one point we added a timeout to the black box that covers the
underlying backup unlock method so if Face Unlock doesn't start or
crashes, the user will see the backup method rather than being stuck
looking at a black box. However, when powering the phone on and off
quickly, the message to time out the black box could be received at
the wrong time, causing it to expose the underlying backup method
when it shouldn't.
This solution clears the existing SHOW/HIDE messages from the
handler's message queue before sending a new SHOW/HIDE message. In
particular, it clears out a delayed HIDE message when a SHOW is sent
so the SHOW can't be undone by a pending delayed HIDE message.
Also, logging errors for a couple of exceptions instead of rethrowing
so we can gracefully go to the backup in these cases.
Patch set 2 fixes problem where rare exceptions could prevent ever
binding to the service again because mBoundToFaceLockService was still
true.
Change-Id: Ieb7b6723161070f509277f67dc9ef100cf7c1aa6
This fixes a regression caused by a resource change to the vibrate
pattern. It used to contain an array of delays and values. Now it has
another mode with just one value with an associated change to the vibrate
API.
Instead of using a custom vibration pattern, it now just follows the system
vibrate pattern for HapticFeedbackConstants.VIRTUAL_KEY, which is shared by the
home key, among other things.
Change-Id: Ib58493a96a42383955ae59f8ac3865bb46a86a31
If the user is making an emergency call, don't bring up Facelock
Has the side effect of not bringing up Facelock if they cancel dialing
Change-Id: I5d23e89b7f687f260670d41f1cc55ebf2a135181
Bug: 5011907
Introduce a 150ms delay in handling volume down keys
while waiting to see if a power key will follow.
Don't trigger the screenshot chord if both volume up and
volume down are pressed together.
Don't trigger the long-press power menu if volume keys are
also pressed.
Require the user to press both keys in the chord within
the debounce time and continue long-pressing them in order
to trigger the screenshot action.
Change-Id: I248968d37b73c09d6d08e7f62667c443eba32da0
Bug: 5011907
Introduce a 150ms delay in handling volume down keys
while waiting to see if a power key will follow.
Don't trigger the screenshot chord if both volume up and
volume down are pressed together.
Don't trigger the long-press power menu if volume keys are
also pressed.
Require the user to press both keys in the chord within
the debounce time and continue long-pressing them in order
to trigger the screenshot action.
Change-Id: I248968d37b73c09d6d08e7f62667c443eba32da0
Leaky singleton bug! GlobalActions, recents, and the
keyguard are all in the same process and therefore receive
the same StatusBarManager instance. Therefore, their calls
to enable() and disable() clobber one another.
Bug: 5423182
Change-Id: Ie535d88f5a5bb940dabee5f1ac176027e1793c5c
This is needed for application to know when the keyguard becomes
unlocked, because isKeyguardLocked() is typically true while
provisioning (setup wizard), but ACTION_USER_PRSENT was
not sent when it transitions to false after provisioning.
Bug: 5436867
Bug: 5430833
Change-Id: Icae13ff9cab84774a002a426eb9cb353fa1dc530
Fix a bug where action bar menus were using the wrong context to
inflate stock views. This was causing them to use the action bar's
themed widget context instead of the current theme's specific action
bar items.
Note that action views in the menu will still be inflated using the
themed widget context. This can produce some weird side effects if
the action views use theme attributes relating to these action bar
item attributes.
Change-Id: Ied3614d1fedb10a0f5366bbe7b90cd5f2f1ff969
This fixes a bug where Lock Screen would sometimes inappropriately show
"charged" if it took a while for Lock Screen to get an update on the
battery state. It now starts with the state set to BATTERY_STATUS_UNKNOWN
so we properly update listeners when we finally get battery information
in handleBatteryUpdate().
Change-Id: I71018a233f38b2f897ff2e6592d7e310550fa016
Leaky singleton bug! GlobalActions, recents, and the
keyguard are all in the same process and therefore receive
the same StatusBarManager instance. Therefore, their calls
to enable() and disable() clobber one another.
Bug: 5423182
Change-Id: I724d17dfc5289141690560cc8ff83cc8543b25b1
The PhoneWindowManager is now responsible for hiding and showing
the nav bar.
For hiding, it just moves it off the screen (easy way to get a
nice slide animation on and off). At the same time, we use a
new WM facility to put up a fake input window to capture all
touch events.
When a touch event is received, we force the system UI to clear
the navigation hiding bit so it will be shown again.
This removes a bunch of code from the system UI for hiding and
showing the nav bar. Also removes the code calling from userActivity()
to the system UI, which was bad. (Also no longer using userActivity()
fixes bugs around re-showing the nav bar due to key presses and
other wrong things.)
Change-Id: I8c3174873b5bcaa36a92322a51e8f7993e88e551
This fixes a bug where the state wasn't being updated because it wasn't
registered for KeyguardUpdateMonitor state changes when the view first created, like on first boot.
Change-Id: Ic6838afffd0de51decdc43a8e8a796696aed49df
The alarm clock doesn't actually hide the view until AFTER Facelock starts
hence the need to kill Facelock after it has started when the even is caught
Also fixing phone black box background in case the user cancels the call quickly
Also eliminating blackscreen after 4s for multiple reasons
so people can login if lockscreen locks up
also so cancel fade is to the backup lock
Change-Id: I8162ff67453038559f289408f4f0d452d4f79ab3
This cleans up how ui flags are managed between the client and window manager.
It still reports the global UI mode state to the callback, but we now only clear
certain flags when the system goes out of a state (currently this just means the
hide nav bar mode), and don't corrupt other flags in the application when the
global state changes.
Also introduces a sequence number between the app and window manager, to avoid
using bad old data coming from the app during these transitions.
Change-Id: I40bbd12d9b7b69fc0ff1c7dc0cb58a933d4dfb23
This needs to actively listen for phonecall callbacks,
or calls that come in while Facelock is active will drop.
Change-Id: I818433e5de9085f0357f61d6a04b395e58871396
