This may fix the issue, but we have no repro steps so no way to
make sure.
What appeared to be going on was that the emergency dialer was
created, but still had the starting preview window above it. We
were stuck in this state because the preview window didn't have
the "hide lock screen" flag set, so the lock screen would never
be removed, and thus we would never take care of finishing the
show of the emergency dialer (because it was not visible) and
thus not remove the starting window.
The solution here is to simply propagate the lock flags up to the
starting window.
Change-Id: I6da9f6494537f0661d9d230664ebf745c293ea7d
There were a few places in the window manager where we wouldn't cause
a layout after making a window visible. This would leave it using
whatever size and position it last have since we don't layout windows
when they are not visible.
Also includes a little part I missed in the security issue that
allowed wallpapers to see input on the lock screen.
Change-Id: Icd7e037ad9a67ac936bc7039d87ed68f49502d73
The system_server process is deadlocking between event dispatch and window
manager code. This change fixes the lock scoping to eliminate the deadlock.
Change-Id: I00f029e4d51d7432119ad3aeec260df215b52546
...in setup wizard ->Wifi setup screen.
We were stopped waiting for the wallpaper to draw, which it would never do
because it had been obscured and thus hidden.
Change-Id: Ia48b3f2a46ca970f143cbaee99f5f2a054378986
This is a quick and dirty hack to not deliver touch events to the wallpaper when
they are being sent to the keyguard. Perhaps we should have a separate window
flag for this, but... bleah. Maybe later. Or maybe I'll use that secure flag.
Or something.
Change-Id: Ifd95b9f5b10db24a0854a93b925a833b24331b4c
This fixes another case where the screen would turn on when the keyguard is open but hidden by another activity.
Change-Id: I2b7c8a329036401709e96ded4f4c138041192a71
Signed-off-by: Mike Lockwood <lockwood@android.com>
...Binary XML file line #37: Error inflating class <unknown> after adding a secondary account
The problem was that we weren't dealing well with the situation where we start a transition
from activity A to B, then transition back to A before B is shown (it finishes before being
shown), then transition from A to C. At this point we had some state showing that we
were in the process of showing A from it being hidden (due to the middle transition from
B to A), which would cause the layout pass to ensure its window is hidden before the
transition starts.
The solution is to detect the case where we are showing a token and it is already actually
shown, and in this case not do all of the token setup for it to wait for its windows to
be displayed before it is shown. This isn't needed, the windows are already displayed
or the token is already set up to wait for them to be displayed.
Change-Id: I16925b91e1e2449dd65ade162a5758173c6e2695
If reenableKeyguard() is called before the previous disableKeyguard() call is processed,
then TokenWatcher.sendNotificationLocked() will cancel the request, resulting in neither
the TokenWatcher acquired() or released() methods being called.
In that case, reenableKeyguard() will hang waiting for released() to set
mWaitingUntilKeyguardReenabled to false. Now we only wait in reenableKeyguard()
if the TokenWatcher acquired() method is called and the keyguard has actually been disabled.
This should fix bug b/2270192
Change-Id: Id886fb28df607dbb4543124f2db6997121d6a682
Signed-off-by: Mike Lockwood <lockwood@android.com>
Make sure to deliver events to the wallpaper until the final up.
Also fix behavior in the case where a window goes away while the pointer is still
down in it, which is a fairly novel situation introduced by the new lock screen.
Also add infrastructure for delivering motion events during preview.
Change-Id: I0de7979be27e00caf0b1eff794ea899a815142f6
The window token rearrangement is defered if an animation is
underway. Force a focus recomputation when the window tokens are finally
rearranged so that we have a valid focused window.
again this flag gets set no matter what since the keyguard window is always present in the list of tokens and this hides the window which would
have become visible since the keyguard just got dismissed.
This causes unnecessary focus changes due to changes in visibility of current window.
This will resolve issues related to current focus and time outs when dispatching key events.
Because of the asynchronous behavior of keyguard, and incall explicitly
disabling keyguard, sometimes the window manager would wind up in a state in
which the "correct" app and activity window were shown, but focus was
recalculated "too soon," at a time when keyguard was just about gone but not
quite, and incall was not yet fully shown. In this case there was no currently
valid event target, but the final show of the incall window would not prompt a
focus recalculation, so that "no current focus" state would incorrectly persist,
resulting in spurious ANRs until some other phone activity forced a focus
update.
We now detect the problematic case when windows are shown, and make sure to
recalculate focus explicitly thereafter. This change does *not* fix the
underlying race conditions that have been resulting in mismatched state within
the window manager, but it does force a validation pass that puts things in
order so that normal operation can continue.
Change-Id: I8e7f5f0795f0042a0da074aeed385e3fbc210360
Fiddle around with the offsets of wallpapers to have better defaults, and
update the offset when the currently wallpaper target is not setting an
offset itself.
Change-Id: I1864d098fb4813fb0c67857af8ebf398b35e6876
TokenWatcher.acquire() synchronizes on mTokens, not this,
so we need to synchronize on mKeyguardDisabled in disableKeyguard()
to synchronize properly with reenableKeyguard().
This should fix b/2180142 (Stuck in enable keyguard when receiving phone call)
Change-Id: Iad66a2748c7fbf2c516fdb8a00988696719ea80c
Signed-off-by: Mike Lockwood <lockwood@android.com>
There was another way we could ignore the application windows flags
while the lock screen was displayed. This is the infrastructure to
deal with that.
Change-Id: Id8c9cb2f7081df6757ccb797a7cde618e82f7b38
There was a bug with the starting window where it could be added to
the app window list twice, so the buddy list would end up with one
left over after all was done. This would result in visibility
changes not being delivered to it correctly, delaying the dispatch
of onStop.
Change-Id: If1993eaf9cfbba1f523ce5aaa478be0239d0c7db
Windows with a negative Y position can end up in createSurfaceLocked()
with mFrame containing a negative height, causing SurfaceFlinger to go
crazy when asked to create the surface. This change simply guards
against such a situation by instead asking for a 1x1 surface and relying
or later layout operations to resize the window to the appropriate size.
Change-Id: I66f2058f4cd1cf069b12d3d23e6fd340dc76b74e
I think when we were scanning the updated app in the system image,
from an older version on the data partition, we were not setting
the existing package to have the system flag, so not auto-granting
any new permissions.
This also includes some other cleanup in the package manager to
remove old files in various places, and tighten up logging.
Also similar logging cleanup elsewhere.
Change-Id: I6d113c7cf7e736ab9be512d6d7c94c806a24199a
Now that we can have a non-app-window cross-wallpaper animation,
we need to make sure to not access a null app token.
Change-Id: Ia00debd4b2b431d15bd074927a9035e1bc0a6445
The APIs for checking whether keys are held down now also look
at virtual keys.
However it turns out there is less than a second between the time we
start the input thread and check for safe mode, so there is not enough
time to actually open all of the devices and get the data from them
about the finger being down to determine if a virtual key is down.
So now you can also hold DPAD center, trackball center, or s to
enter safe mode. Also give some vibrator feedback.
Change-Id: I55edce63bc0c375813bd3751766b8070beeb0153
This was introduced when I did the fading of the lock screen,
which relies on setting the policy visibility of the windows behind
it to be hidden. As a result, when the orientation changed or
the activity was restarted, they wouldn't be resized or reported
as drawn, and the activity manager would wait until its timeout
before unfreezing the screen.
We now have a new method on WindowState to find out if a window
has drawn itself, which is used in the appropriate places.
Change-Id: If05f8b1947d3029917f62ad0f89b43544bd0a4dc
- The lock screen now fades in and out.
- Fixed a bug where we would accidentally freeze the screen when switching
to an activity with a different orientation than the current (but
the screen itself is in the current orientation). This would mess up
the animations on the car dock.
- New API to force a particular animation for an activity transition
(untested).
- New wallpaper animations.
- Resources now uses the next API version when in a development build,
to help applications being developed against such builds.
Change-Id: I2d9998f8400967ff09a04d693dc4ce55f0dbef5b
Lot of infrastructure for more things to go away when "clear system dialogs"
happens, and now do this when we turn on the lock screen.
Change-Id: I567130296fe47ce82df065ed58ef21b37416ceaf
- New meta-data you can add to a dock activity to have it launched by the
home key when the device is in that dock.
- Fix a deadlock involving ActivityThread's internal content provider lock.
- New window flag to have a non-secure keyguard entirely dismissed when a
window is displayed.
- New WindowManagerPolicy APIs to allow the policy to tell the system when
a change it makes during layout may cause the wall paper or
overall configuration to change.
- Fix a bug where an application token removed while one of its windows is
animating could cause the animating window to get stuck on screen.
Change-Id: I6d33fd39edd796bb9bdfd9dd7e077b84ca62ea08
Add API to skip the animation for a particular start activity, so that
a latter better one can be used.
Fix Theme.NoDisplay to actually work.
Fiddle with various animations: don't do a different animation for task
switching, try a scale animation for switching in/out of the wallpaper.
Adjust the animation duration so that at normal speed we have something
more like the slower animation option (so slow is now the default).
Change-Id: Ieba9f3db0bd9a762a19b327a3ecccbc7b547893d
This also takes care of the problem of system dialogs like the
crash dialog causing the status bar to dim behind the lock screen.
On the down side, the fade transition from the lock screen is
now gone, and I'm not sure how likely it is for it to return.
Change-Id: I7f9e6d0f3510a1fdbbe6ad252d986bd85a16475d
This was a problem with not hiding the starting window when it got
transfered to an activity whose window (instead of token) animates
when displayed.
Change-Id: I9eb58faa6e27d53144687952a715fc083a5c5842
This implements support for devices whose hardware can hide
their navigation keys. It works much like the existing keyboardHidden
configuration, and for compatibility uses the same configuration
change bit.
Also add FLAG_TURN_ON_SCREEN for windows, which has the system
cause the screen to be turned on when the window is displayed.
Great fun when used with FLAG_SHOW_WHEN_LOCKED!
Change-Id: I0b867f19af85cfd8786a14cea194b34f7bdd9b7a
This introduces a new activity that you can derive from to implement
a wall paper configuration activity. This is supposed to select
a theme based on whether it is being run to configure a real wallpaper
or a preview, but this is going to be more difficult to do than I
thought. :(
Also fix a problem in the white theme where the list view's background
was being set to white, so it wouldn't work on a transparent bg.
Change-Id: I26d5a8695a3c878a1664eb09900eded57eaff990
This takes care of allowing us to cancel the back button. The
back button is a bear because it is strewn all over the place --
everywhere you can close something, there is some code looking
for the back button that now needs to deal with being canceled.
The main things changed are activity (of course), dialog,
input method, search dialog. There are some other misc places
in the framework (and some I missed here that I will get in a
second pass).
To facility all of this, the key dispatching APIs now provide
a lot more support for dealing with looking for cancelled keys,
and incidentally also provide an actual API for catching long
key presses. This also helped clean up the code in PhoneWindow
where it deals with all of the combinations of key pressed and
releases. (And also allows people to override
Activity.onKeyLongPress() to provide a different long press
action for a standard key like search.)
And while I was doing this, I reworked how we detect long
presses by having this be part of the key event delivered by
the window manager. This should greatly reduce (hopefully
outright eliminate) the problems with long presses being
mis-detected when an application is being slow.
Change-Id: Ia19066b8d588d573df3eee6d96e1c90fdc19f57d
First, fix some issues with the final wallpaper bitmap
we use: ensure it is always 16bpp, and make sure dithering
of its bitmap is turned off. We take of dithering
when loading, to make sure we don't use it when drawing.
Also add new APIs to return the wallpaper with the equivalent
of Launcher's old FastBitmapDrawable. As doing this, also load
the default wallpaper the same way as custom ones, taking care to
resize it as needed at load time.
Finally implement a mechanism for the window manager to wait
for the wallpaper to redraw at its new position before returning
from the application's call to change the offset. This ensures
that the wallpaper better tracks the application. Note that there
is a timeout in this wait that is relatively short, and if it
expires we will run for a while without waiting.
Change-Id: Ife449437746da85958bd447e0a6cf3d2223b398c
Some more tweaks and fixes to wallpapers. Make sure wallpapers are
told they are not visible when the screen is off. Add some new animations
for transitions across tasks, and fiddle with many of the existing
animations. Clean up the relationship between translucent activities
and animations. Add new API to start a PendingIntent from an
activity.
Change-Id: Ie0bf45fe44081bb6982c75361257a55d9cd9d863
ViewRoot was using Surface.clear(), which has different behavior
in different processes -- in the system process it would kill the
surface, causing all windows in that process to immediately disappear
instead of animating away.
This change makes Surface.release() public and uses that instead. It
also renames Surface.clear() to Surface.destroy().
Also fixed some issues in the window manager that were causing the
wallpaper to not get immediately resized when the orientation changes
and its target window is removed and re-added.
Change-Id: I2a992e365cf5747511f0bf1193db32dc2525b218
This is work on the transitions with wallpapers. There are now new
animations specifically for leaving the wallpaper and returning to
it, which allow us to have a consistent animation when entering home
and returning to it. I also renamed the existing animations across
wallpapers, and cleaned up some junk in the various interpolators.
This also now hides the wallpaper surface when it is not visible,
to get rid of the wallpaper flickers people complained about albeit
in a somewhat brutal way. :) (Though really returning us to the
previous behavior with the same previous bugs and name back to them
not being very visible, yay!) There is are also some bug fixes
here and there about managing the wallpaper visibility that this
change revealed.
Change-Id: I913990a9a81651728122ed2e1101b75ed2c36fcb
The new code to rebuild the window list was missing some app tokens.
Also there were a few other smaller bugs floating around.
Change-Id: I7734917af0b76ee4aa304e6a5321401d87640f89
This addresses a few parts of the bug:
- There was a small issue in the window manager where we could show a window
too early before the transition animation starts, which was introduced
by the recent wallpaper work. This was the cause of the flicker when
starting the dialer for the first time.
- There was a much larger problem that has existing forever where moving
an application token to the front or back was not synchronized with the
application animation transaction. This was the cause of the flicker
when hanging up (now that the in-call screen moves to the back instead
of closing and we always have a wallpaper visible). The approach to
solving this is to have the window manager go ahead and move the app
tokens (it must in order to keep in sync with the activity manager), but
to delay the actual window movement: perform the movement to front when
the animation starts, and to back when it ends. Actually, when the
animation ends, we just go and completely rebuild the window list to
ensure it is correct, because there can be ways people can add windows
while in this intermediate state where they could end up at the wrong
place once we do the delayed movement to the front or back. And it is
simply reasuring to know that every time we finish a full app transition,
we re-evaluate the world and put everything in its proper place.
Also included in this change are a few little tweaks to the input system,
to perform better logging, and completely ignore input devices that do not
have any of our input classes. There is also a little cleanup of evaluating
configuration changes to not do more work than needed when an input
devices appears or disappears, and to only log a config change message when
the config is truly changing.
Change-Id: Ifb2db77f8867435121722a6abeb946ec7c3ea9d3
Yet more work on improving the behavior of wallpapers. This fixes a few
problems in their lifecycle (corresponding change in the picker also
required for this), makes their animations better for hardware that supports
alpha fades, adds animations for the wallpapers themselves, eliminates
fixed size wallpapers, and adjusts the API for retrieving a wallpaper
bitmap to take care of scaling the raw wallpaper image to match the current
desired width and height.
Change-Id: If1c0aaceba4ea4e175dcb7a8416ca7ddbb9bfa6f
The problem was instigated by another fix I made to keep
windows around while their tokens are animating or preparing to
animate. This then hit an issue where if the window's process
died while its token was getting ready to animate, we would
immediately hide the token, and when we then went to start
the token animation we wouldn't do anything, leaving the old
dummy animation in place and not allowing it to run.
Now we clear the animation before hiding the token, to ensure
the dummy animation is gone at this point.
Change-Id: If83fadcce6815bc545c80fbdb82fe6972bbdf5ef
