Check the status of Settings.Secure.USER_SETUP_COMPLETE for the current
user when showing the keyguard, disabling the Camera + Search touchpoints
entirely until the user makes it through the setup wizard.
Bug:7308791
Change-Id: Ic8e3596582c2aefc7fe15af1824ed6bfd541dffa
If the user was in the middle of a phone call and went to the lock screen
it would show a black box with an X, but Face Unlock wouldn't pop up and
the X was unresponsive.
There were a few issues causing this. The X on the default view wasn't a
button, so it has been changed to a button which will go to the backup
lock. The concept of show() and hide() in FaceUnlock.java are obsolete
because Face Unlock is no longer being overlayed on top of the backup so
there's isn't a black box to show or hide. In addition, since it's not being
overlayed, Face Unlock doesn't cover the backup lock so fading to the backup
looks janky. The flip animation is more appropriate.
Change-Id: I730aa4bbce42b4656ee1bce61352b8aefbd6892d
When switching users, Face Unlock starts in onResume(). However,
there is no signal to indicate when the user actually sees their
unlock screen. This means Face Unlock could be running unseen, timing
out soon after it becomes visible, or letting the user in before they
see the preview.
This fix simply suppresses Face Unlock immediately after switching
users. This is not the ideal behavior, but there is no easy way to
make Face Unlock start only after the unlock screen becomes visible.
When the user changes screens it becomes unsuppressed, so if they go
back to the multi-select widget screen or login, Face Unlock works as
expected and is only suppressed again when the user is switched.
Change-Id: I80a302b0aefc1dee3c2dc77557978cbe062de435
This fixes an issue where the music transport hangs around indefinitely.
It used to get dismissed when music stopped playing and a notification came in.
This was due to a bug in JB.
Now that the bug is fixed, the music control hangs around indefinitely until
the application actually releases it.
Since we have widget support, we can now leave the transport control in place
for as long as it's possible to resume music (state = playing | paused).
If music is playing, we start with the trasport showing
If not, and multi-user is enabled for more than one user, we show the user switcher.
Otherwise, we show the clock.
Bug 7290707
Change-Id: I6f0553a64b7b66bac7b35eca6d8a8793c15b918c
When Face Unlock failed the maximum number of times (3), it was asking
for account login when it should have been asking for the backup lock
that the user chose when setting up Face Unlock.
This change splits the isBiometricUnlockEnabled() function into two.
One of them strictly checks whether it exists and is selected. The
other one checks whether too many attempts have occurred. When
deciding which backup to choose, the decision is now based only on
whether Face Unlock is enabled. Checking whether too many attempts
had occurred caused the bug because the check indicated it had already
'fallen back' to pattern, and the backup for pattern was being
selected instead of the backup for biometric unlock.
Change-Id: I6b9cf2c5155e8c14933cbfc8f5d58ebc007e53cb
The final iteration of that change was a little too aggresive in
deciding when it turns off the dream's enter animation, so it was
doing this always instead of just when it needed to (when it is
being displayed to hide the lock screen).
This change fixes a dumb typo that was causing the dream to always
turn off its own animation (duh!) and tweaks the logic for deciding
when the dream should be able to cause the lock screen to hide to
better ensure that it is shown before the lock screen gets hidden.
Change-Id: Ie73a5be9ee597713644fb2a0202f36c32b4f1fca
7296314 Crashing dreams are stuck
7296510 Transition from lock screen to dreaming is really bad
The window layer for dreams is now moved down below the keyguard,
so that some of the expected stuff like crash and ANR dialogs can
be seen on top of them. While doing this, I reorganized how we
define the layers so the constants are just in the switch statement,
so it is much less crazy-making trying to read how things go
together.
We now have some special cases for when a dream is being shown
to turn off its animation if the keyguard is currently shown.
Since we know it will be hiding the keyguard we need it to be
shown immediately so that you don't see whatever is behind it.
Cleaned up some handling of when the lock screen is displayed
while a FLAG_SHOW_WHEN_LOCKED window is displayed, so that the
lockscreen doesn't transiently get shown and mess up the fullscreen
or system UI state. This also fixes problems with any normal
activity that is doing this.
Hid the methods on DreamService for setting lights out mode. It
doesn't make sense to have such methods on DreamService, because
you can just as well do that on your own View that is showing the
dream content, and when you can do that you can fully participate
in the (required) interactions about it such as being told when
the mode goes away.
The DreamService method for going fullscreen now uses the window
flag for doing this, which is what you want, because you want this
state to persistent on that window and not get knocked out if
something above the window tickles the system UI state.
Also fixed the problem where dreams that hid the status bar would
have a jerky animation when going away, since they were causing the
activity behind them to be layed out without the lock screen. This
is a kind-of ugly special case in the window manager right now to
just not layout windows that are behind a dream. Good enough for MR1.
Change-Id: Ied2ab86ae068b1db0ff5973882f6d17b515edbcd
When keyguard doesn't have focus, events weren't being propagated to
keyguard properly. The fix is to grab the back-button event from the
top-level view and handle it there.
Change-Id: Ied9761919cff30173f43f03e4c2a1732387e618e
Created a new flag that indicates that a window should be shown
to all users. For the flag to be valid the owner of the window
must have system permissions.
Also separated system window types into those that show to all
users (e.g. StatusBar, Keyguard, ....) and those that appear only
to the owning users (e.g. Drag, ANR, TOAST, ...). Those that appear
only to their owner can override their default behavior using
the new flag (e.g. LowBattery).
Fixes bug 7211965.
Change-Id: I1fdca25d57b7b523f0c7f8bceb819af656c388d4
While fixing this bug, I fixed a few other issues:
- Always call showAppropriateWidgetPage(), even when DPM enabled
- Always disable status view interaction, even when DPM enabled
Fixes bug 7294880
Change-Id: Ia8495555c1940f2b38f42389558f46fde6aab775
Some security screens aren't currently calling userActivity(). As such,
they allow keyguard to timeout before the user has a chance to enter
the required information.
The fix uses a TextWatcher to look for changes in the input text
and call userActivity() appropriately.
bug 7291431
Change-Id: I6d7889cc01a4d6bdbefefc5af478e812c35b1a49
Add a new call to the activity manager for the input dispatcher
to report about any pid having an ANR. This has a new feature
where it can also tell the activity manager that it is above the
system alert layer, so the activity manager can pop its ANR dialog
on top of everything if it needs to. (Normally we don't want
these dialogs appearing on top of the lock screen.)
Also fixed some debugging stuff here and there that was useful
as I was working on this -- windows now very clearly include
their uid, various system dialogs now have titles so you know
what they are in the window manager, etc.
Change-Id: Ib8f5d29a5572542cc506e6d338599ab64088ce4e
Two things going on here, status bar disabled flags need to be reset
on user switch. Also make status bar's internal disable-record lookup
multi-user aware.
Bug:7278793
Change-Id: I1d7088d956a065330736da4c09cc1874c528c133
1. If there is a non-speaking accessibility service installed and the
global gesture is performed an exception is thrown since an attempt
is made to modify the list with services returned by the accessibility
manager (to remove the non-speaking ones) but this list is immutable.
Now the returned services are put into a mutable list before removing
the non-speaking ones.
bug:7280996
Change-Id: I2852a3e169c1d34d942b50fb439e0961394c92bc
Otherwise global actions appear underneath interactive dreams,
like all system dialogs.
Bug:7257688
Change-Id: Idb7ae8079fa0fc335c598c72f36bdad69248b1b1
-> When user is switched, we immediately show their security, if present
-> If a user taps on the active user, it shows the glow pad unlock hint
Change-Id: I074ed63123a6bc6a38051cb77b5d86bd3f0e93ea
This fixes a performance issue on the 7" tablet where disabling hardware
layers in landscape mode resulted in extremely bad drawing performance.
The code now enables hardware layers for all the widgets while the user
is dragging.
Fixes bug 7274971
Change-Id: Iafd18fb317fcd3caad45791fe5a0f111d40a1ed4
Since the new PowerManager changes are in, keyguard needs to handle
keeping the screen awake. This change does this in a few places in
addition to the existing security screens:
- when the widget page changes
- when the user interacts with any widget other than the status widget
- when the user taps on the target in the selector screen
Fixes bug 7273646
Change-Id: If4c76a38e9b886dd359ba96cd2aae03652007b66
-> Updated user switcher to be closer to spec (issue 7047393)
-> Drawing keyguard overscroll gradient manually in KeyguardWidgetFrame
(eliminates need for assets, eliminates banding)
-> Fixed clipping of overscroll on sw600dp using negative margin
Change-Id: I90ec7f820ca7dccebf7e05628a3185e95d41af08
