- Apply the correct crop rect at this point.
- Apply the correct position by taking into account the frame left/top.
- Don't directly apply the new values if the window is currently
animating, since we need to go through the whole animation step
to determine what the correct position is (taking into account
any transformations).
Change-Id: I15d79354d9779867c49c7c0880faccdead7b021d
The window manager now performs the crop internally, evaluating
it every animation from, to be able to update it along with
the surface position.
Change-Id: I960a2161b9defb6fba4840fa35aee4e411c39b32
- During the transition, fade the bg to black
- Exiting activity fades to black
- Recents background no longer fades away, because
then it would fight against the fade to black
happening behind it
This refactoring sets the stage for a follow-on change that
will make use additional functions of the power HAL.
Moved functionality from android.os.Power into PowerManagerService.
None of these functions make sense being called outside of the
system server. Moving them to the PowerManagerService makes it
easier to ensure that the power HAL is initialized exactly once.
Similarly, moved ShutdownThread out of the policy package and into
the services package where it can tie into the PowerManagerService
as needed.
Bug: 6435382
Change-Id: I958241bb124fb4410d96f5d5eb00ed68d60b29e5
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
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
- Fading out recents first, then scaling up app
thumbnail
- Fade Recents out over 130ms
- Delay the window animation for 200ms first,
then animate for 200ms (previously we didn't delay
and then animated for 300ms)
Bug: 6390075
Change-Id: Ia8c753bf7ee03d2acef6eb2772b28d88fe10a682
1. Previous fix to hide wallpaper at the same time the wallpaper target
was hidden was too aggressive. In the case where one wallpaper target
was replacing another we would lose the wallpaper for an instant.
2. Previous fix to keep from overwriting the moving window boundaries
was incomplete. The default values for the parent window were 0,0
which caused the lock window animation to translate down and to the
right. Defaulting the parent window boundaries to the full screen
and restoring it to the full screen after each animation fixes this.
Fixes bug 6472070.
Change-Id: I0b13c642c1aaab666cdd0f4a1e7fb4b716e6b17f
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
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
