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
This attempts to fix a bug where the transport control would sometimes be
inoperative. The problem is that we had two transport control layouts
on some devices because they were being declared in the layout file.
The fix is to only inflate the layout once when KeyguardHostView
is created.
Also removes redundant KeyguardStatusView.
Fixes bug 7254833
Change-Id: Iab84e8326ff745ee57be5177ab2561114c8dc6f0
Includes telephony, WindowManager, PackageManager, and debugging
settings. Update API to point towards moved values.
Bug: 7231764, 7231252, 7231156
Change-Id: I5828747205708872f19f83a5bc821ed0a801cb79
Sending the unmasked soft input mode int setAttachedWindowFrames
included the SOFT_INPUT_STATE bits and guaranteed that the adjust
test would always pass.
Bug 7256294
Change-Id: Iaf5368432c7b350fe70687d08c0a08e814b35e94
-> Showing correct page, as per discussions (issue 7205431)
-> Hide the time when the system status widget is showsing (issue 7216577)
Change-Id: I5b79d72e8fd8226952f6a8ea99b776feb4ddde1f
When there are multiple activities that respond to MediaStore.INTENT_ACTION_STILL_IMAGE_CAMERA_SECURE
we need to show the disambiguation dialog to the user. However the disambiguation "dialog"
is actully an activity themed as a dialog. Hence, we can't show it in the secure keyguard.
This works around the issue by prompting the user for their credentials directly when the
intent needs disambiguation. This will take them out of keyguard and prompt them for
which activity they want to use.
We'll provide a more robust solution in a future release.
Fixes bug 7109816
Change-Id: I94e643d3cb503e1ce6de24c82400b4d5fcbb9d95
