Prior to this fix once dimming had been turned on it stayed at the
same layer and associated with the same window until it was turned
off. Now the DimAnimator layer is updated if either the window layer
changes or the dimming window changes.
Fixes bug 6467865.
Change-Id: I3e1765b92b51be26e3718c8a87e2583041a36af9
If the layout goes through more than one pass after detecting a window
movement but before animation begins then the later pass overwrites
the animation offsets. The incorrect values are large leading to an
animation starting location in the bottom right corner.
Fixes bug 6450310.
Change-Id: I0f74e67b3e9a15a9246151abf6d47384509340e9
Qualify the test for wallpaper animation to exclude the dummy
animation. This keeps us from treating a dummy-animating wallpaper
as an exiting wallpaper and providing the wrong animation.
Hide wallpapers when the wallpaper target window is hidden. This
fixes a timing issue where the wallpaper was exposed for one pass
through performLayout after the launcher was hidden.
Fixes bug 6454992.
Change-Id: Ib4f9205c01a37e6f48f1f93ddcf2476e40ff942f
When attached to an HDMI touch screen, the input system needs
to know the size and rotation of the external display independent
of the internal display. The size was already being reported
separately but not the rotation. The inconsistency can cause problems
if the internal display's natural rotation is portrait but
the external display's natural rotation is landscape.
Change-Id: Id344f04c1ba032625f6265766be66f9ddaa2cc0b
Wallpaper logic assumed that if mWallpaperTarget was non-null then
any wallpaper animation should be exiting. However, if the existing
wallpaper target was already animating away then mWallpaperTarget
remains non-null until it is completely gone. Pressing Home during
this time was causing the next animation to exit rather than reverse
and enter.
This fix looks to see if the wallpaper target is animating and if it
is to treat it as null for the purpose of determining which direction
the animation should go.
Fixes bug 6407941.
Change-Id: I731267328db0f9972a5aed6f214962f96737dd07
The window manager policy made some incorrect assumptions about the
meaning of the Configuration.keyboard field. We need to be more
careful about distinguishing between built-in and external keyboards.
Most of this change is to move the determination of the parts of
the Configuration related to input devices into the WindowManagerService
leveraging new features of the InputManagerService to good effect.
Then we plumb through the flag that indicates whether a device
is internal or external so that we can be more particular about
how the lid switch effects changes to the Configuration.
Bug: 6424373
Change-Id: I36a1c22ade35e578955465a25940a33f227b9763
Added a config option to allow the lid switch to turn off the
screen. This is a closer match to what a lid switch should be
doing.
Removed an old feature to bypass keyguard when keyboard is visible
because the way it was plumbed in made bad assumptions about
the meaning of the lid switch. Also, the last product we shipped
that had a physical keyboard turned this config option off.
So away it goes. We can bring it back someday if we really want it.
It's questionable how useful the feature is anyhow, since it only
works when the keyguard is unsecure and when the lid switch is
unlikely to be jostled in the user's pocket.
Fixed a bug where we would tell the power manager that the keyboard
was visible even if the lid switch did not control the keyboard.
This used to cause the power manager to try to set the keyboard
brightness, which doesn't work.
Bug: 6377115
Bug: 6406726
Change-Id: Ic84b71d09563d51c92cd1cf132fa8bdee6509103
This will be used to determine which parts of a window a completely
hidden by system UI elements (status bar, nav bar, system bar) so
that they can be clipped out from rendering.
Change-Id: I2c6c6ac67dbdfeed82d2c089ef806fb483165bd9
On some hardware allocating a new graphics buffer is quite
expensive, which blocks updates to the UI. This can cause
glitches when performing window animations.
To reduce these glitches, the view hierarchy will now only
allow itself to be drawn once if its window is being shown
while the window manager is animating, not resuming draws
until it is told that the animation is done.
Change-Id: Ie15192f6fddbd0931b022a72c76ddd55ca266d84
Move the test for deferred window change notification after the drawing
update. Previously there was never a second check after the drawing
completed so we never sent the notification to the departing window.
Fixes bug 6335849.
Change-Id: I8a7eafdb184567a47ae04f1e597bae4cccf6cf62
Check to make sure that a WindowState has a Surface before adding it to
mResizingWindows.
Fixes bug 6300793.
Change-Id: Ieb39422523360dcdd5f5bf8109f061ae1ced62b2
Check to see if app token is hiding before going ahead with turning on
dimming. Before this fix went in we were turning dimming back on right
after turning it off. Then we didn't turn it off again until all
animations had completed leading to a delayed dim-off experience.
Fixes bug 6378033.
Change-Id: Ic819a0093ba95f62df369266c07525835703c5fa
* commit '7eda9de1a638e4ed1ce5dc65fecd673400b9f3c0':
Transparent activity orientation problem when previous landsacpe fullscreen activity not yet destroyed.
These now do something reasonable when performing transitions
across two activities that are both on top of the wallpaper.
Fixed computation of the pivot point of the animations.
Fixed issue where the recents panel was considered a status
bar element for purposes of deciding if the animating elements
are obscured by the status bar, which would result in us not
running the animation correctly.
Change-Id: I4b9b588b80243463e6f087a9703ee886ee281630
After terminating landsacpe fullscreen activity,
when user launch transparent activity via portrait home app, transparent activity is shown as landscape mode.
At this time AppWindowToken of previous acitivity has not been deleted, because Activity.onDestory() has not been returned yet.
In this case, getOrientationFromAppTokensLocked() returned ActivityInfo.SCREEN_ORIENTATION_LANDSCAPE.
Ignore hidden application is terminated on the top.
See also http://code.google.com/p/android/issues/detail?id=28927
Change-Id: I51239431120ec6ba8f8ff76871efb2347b9810ca
Added two public methods to Debug. These methods return a String
indicating the caller (getCaller()) or callers (getCallers(int depth))
of the calling method. The String indicates the class, method and line
number of the caller(s). Similar to using Throwable.fillInStackTrace()
but much more concise.
Change-Id: I53d0085aa50e4501d28e8eb3ad5b91ef700ac218
Several Surface operations - notably setPosition, setSize, and show -
had been moved outside of a Surface.openTransaction/closeTransaction
window. This corrects that problem.
In addition, before animations were separated from layout the Surface
frame was computed prior to returning from relayoutWindow(). After
separation the frame was being computed during animation. This checkin
restores the frame calculation in layout.
Fixes bug 6343291.
Change-Id: I4752bdf1fed0f2b46c5eb9508825c9b1b0fd702f
In the old code orientationChangeComplete was set to true on each pass
through perfomLayout. If any window was rotating the variable was set
to false on the way through the performLayout. Since we can now make
passes through performLayout before any animation step occurs we were
seeing mOrientationChangeComplete true prior to rotation completing.
This change sets mOrientationChangeComplete false at the start of a
rotation and sets it to true if we ever get through an animation step
without encountering any rotating windows.
Change-Id: I37690cf20868dfbaac94a81640bc4d9cb9fb8f00
Animation steps are now executed on a Thread launched from the
Choreographer rather than being called at the end of the WindowManager
layout process. Animations and layout are still tightly coupled in
that they share considerable state information and neither can be
executed without holding a lock on WindowServiceManager.mWindowMap.
Change-Id: Ie17d693706971507b50aa473da1b7258e9e67764
- Replace HashSet with ArrayList.
- Check for Watermark and SurfaceSession initialization once, not every
time through layout.
- Move watermark rendering into animation.
- Add surface operation debugging.
Change-Id: I4b7e7c0b8d89d43c67a42753832f90b8632d4f5d
We now have an animation to apply to the thing behind the lock
screen animation when it isn't on the wallpaper, which looks
similar to the animation we use when both are on the wallpaper.
In implementing this, cleaned up the code to figure out up-front
which animation to run, getting rid of that kludgy thing that
cleared the window animation if the wallpaper was not being used
for the lower windows.
Change-Id: Ifc4c8a8894ad384124dcf4bbdaab134f1157b0f3
The method setTokenVisibilityLocked returns true when animations are
delaying the exit of an app. Previously this only checked AppToken
animations but that caused exiting WindowState animations to be
ignored.
In particular if an application both hid an AppToken and then
dismissed the AppToken, the AppToken was being removed from
mClosingTokens before the animation finished. This caused
rebuildAppWindowListLocked to lose a WindowState. Furthermore
Surfaces were not being removed when a WindowState was lost and
we were leaking Surfaces.
Fixes bug 6297563.
Change-Id: Ie75c71064518199237ec4a17d3f65e2a2dd29674
Add a test to make sure that we are dimming before we send the message
to stop it. This prevents a CPU consuming loop when dimming is already on.
Fixes bug 6320003.
Change-Id: If26dc5b0800300d8e38c166824651223eded4cfa
