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
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
This change keeps requestTraversalLocked from being called on virtually
every call to animate while rotating.
Change-Id: I6d2db37db3bb82f4f9ecc84b17dbf121819a6c1b
