Drawing in windows is suppressed during window animations, to make window
animations smoother. This means that drawing activities that the activity
requested are dropped on the floor. There is no call at the end of window
animations to tell the windows that they may now draw, which leaves the windows
and activities in an uncertain state, especially with respect to some of the
dirty flags that we use internally to know when we have requested (and satisfied)
invalidations on views.
The fix is to notice, on the WindowManager side, when we've finished window
animations and to schedule a traversal on the WindowManager, which will then send
out appropriate messages to the affected windows.
Issue #6461113 EventInfo is stuck in day view
Change-Id: I364c9c472531c467d44801698cfb453970173bb3
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
BlackSurface transparency was tracking animation transparency causing
background images to peek around the corners.
Fixes bug 4998851.
Change-Id: I48ac7bf5d0cc560b655c9f12faccda411985cbad
Calls to relayout were forcing outgoing app reported visibility to
false. Because there was a DummyAnimation in the outgoing app the
stepAnimation was forcing the app Transformation alpha value to 0
based on the most recent reportedVisibile value. This was causing the
outgoing app to disappear for an instant. Moving the visibility test
to the time at which the DummyAnimation is set fixes this problem.
Fixes bug 5908102.
Change-Id: Ib574728a007a0af759990816db42e23ba315b468
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
The DimSurface layer was momentarily being placed above the entering
app animtion. This lets the layering be set after the animations have
been evaluated.
Plus debug enhancements.
Change-Id: Icc034bc5264ae9bc6c57c593534683b56588b59a
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
When dummy animation is being used, set the alpha to 0 or 1 depending
on whether the app was previously hidden or visible.
Change-Id: I1a4e3cdb4b9ca4a6aef58e47bf26e5adbef66a7f
Force a pass through layout with mOrientationChangeComplete set
following all windows drawn when the application is freezing the
screen.
This fixes bug 6359311.
Change-Id: I318864fb687cf85a0c9ac4478e4f29dc20f43d9c
This fixes a rotation bug introduced by delaying rendering animation
into the Surface. Now instead of delaying the rendering we delay the
show by eliminating a point where we were showing the Surface too soon.
Change-Id: I63ad3b494963111ffc96569093c8d43517c5408b
* 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
Hold off on updating surface with animation until the Surface draw has
completed. Previously we were calling Surface.setAlpha/setLayer/
setMatrix prior to the app drawing into the surface. This fixes a bug
that caused a flash of the target animation image before the animation
had begun.
Change-Id: Id9142e09b0b22d631dc002eba4dc787455dea03a
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
