History log of /frameworks/base/services/java/com/android/server/wm/WindowStateAnimator.java
Revision Date Author Comments (<<< Hide modified files) (Show modified files >>>)
81defc794b0079c7f557b5d7c3924039ac0e9156 29-Oct-2013 Craig Mautner <cmautner@google.com> Force relayout at completion of status bar animation

A final layout pass should be done whenever the status bar has
completed its incoming animation.

Fixes bug 10387660.

Change-Id: I48c19015c53116b58cf73e20be32d1f64dd682ca
/frameworks/base/services/java/com/android/server/wm/WindowStateAnimator.java
798adeffb0b9c22707b493895453e7dd2f608b75 22-Oct-2013 Craig Mautner <cmautner@google.com> Don't use transient states for wallpaper animation.

The WindowManagerService member mLowerWallpaperTarget is not stable
throughout an app transition. Relying on it to be stable causes the
intra-wallpaper animation to start out right but after the windows
have been relayed out there is no longer a lower wallpaper target.
This causes the wallpaper to start tracking the animation of the
current wallpaper target rather than remain stable.

Switching to a new variable that saves the state of wallpaper
animation at the start of the animation fixes bug 11240590.

Change-Id: I336a59c47665fcf61019f567b8663956ff0e4940
/frameworks/base/services/java/com/android/server/wm/WindowStateAnimator.java
4664623c304cf162b9a78f3aee3290a92e54b628 01-Oct-2013 John Spurlock <jspurlock@google.com> Store decor rects per window for transition cropping.

Instead of keeping a single global system decor rect around
in WindowManagerService, calculate and store policy-defined
system-decor frame for each window.

The per-window decor rect is useful for smooth transitions, since it
determines window cropping during transition animations.

Bug:10938001
Change-Id: Ice6652aa5946027c45c0b7ab4e46473a0f8e3f90
/frameworks/base/services/java/com/android/server/wm/WindowStateAnimator.java
5845812780a29f4594dbdac12e65c4e063ddb4b0 14-Sep-2013 Craig Mautner <cmautner@google.com> Add debug logging for b/10689184.

Focus is now on focus. Remove logging when fixed.

Change-Id: Ic0cd2d6bd4e65dac9dd40f4745dd12fb84f687ce
/frameworks/base/services/java/com/android/server/wm/WindowStateAnimator.java
a86ab640f7bb0bf3cb4eaed80473ca8c5d131903 30-Aug-2013 Igor Murashkin <iam@google.com> Surface: Change OutOfResourcesException to be a runtime exception

- Deprecates SurfaceTexture.OutOfResourcesException, it wasn't used
- Make all JNI code throw only Surface.OutOfResourcesException
- Get rid of redundant SurfaceControl.OutOfResourcesException

Bug: 10566539
Change-Id: I58126260771b9ccff6a69c672ce7719b9f98138d
/frameworks/base/services/java/com/android/server/wm/WindowStateAnimator.java
8efb0a4d811fc18ac8ef32f7d597aa6fafb3acec 08-Aug-2013 Craig Mautner <cmautner@google.com> Add extra layout pass after draw finished.

Once content has been drawn another pass through layout is required
to set mHasContent in the LogicalDisplay. Previously this pass was
occuring because of a delayed animation step. When timing of that
step changed that pass occurred before the draw completed. This is
why Presentations were immediately displayed in jb-mr1 and not
jb-mr2.

Fixes bug 10154780.

Change-Id: I0075c5a73d5cdf972e73fdd59c1fde46df64e245
/frameworks/base/services/java/com/android/server/wm/WindowStateAnimator.java
46ac6fa614131d567bed93d1d2067d765ecef85d 01-Aug-2013 Craig Mautner <cmautner@google.com> Add force default orientation.

Devices can be configured to remain in their default landscape or
portrait orientation by setting config_forceDefaultOrientation true
in overlay/.../values/config.xml.

Activities that desire to run in the non-default orientation are
supported by creating a logical display within the physical display.
Transitions to and from the activity perform a crossfade rather than
the normal rotation animation.

Also, improve SurfaceTrace debug output.

Fixes bug 9695710.

Change-Id: I053e136cd2b9ae200028595f245b6ada5927cfe9
/frameworks/base/services/java/com/android/server/wm/WindowStateAnimator.java
b3b36ba13895d779159799341d432f6380a0ba8a 20-May-2013 Craig Mautner <cmautner@google.com> Resize all changed windows and fix moveTaskToStack

- Add all changing windows to mResizingWindows when an ActivityStack
is resized.

- Stop calling TaskStack.setBounds if the bounds haven't changed.

- Make moving a task from one stack to another work properly.

- Eliminate unused methods and redundant variables in WindowState and
WindowStateAnimator.

Change-Id: I3a950c777bcc50cdeced150d44423d4d0b38af4a
/frameworks/base/services/java/com/android/server/wm/WindowStateAnimator.java
05d290365f0b9ed781ffcb30b38a0c7c6e450e9d 03-May-2013 Craig Mautner <cmautner@google.com> Fix layering and launching issues.

- Replace calls to ActivityStack.resumeTopActivity() with calls to
ActivityStackSupervisor.resumeTopActivities().

- Move dim layers from display scope to stack scope. This applies to
both the animation background dim layer and the FLAG_DIM_BEHIND dim
layer.

- Move windows on stacks that are not targeting wallpaper above the
wallpaper. Otherwise wallpaper placement hides the non-focused stacks.

Change-Id: Ic6b97ac6b094672bb1ddac17ce46ea58c738f073
/frameworks/base/services/java/com/android/server/wm/WindowStateAnimator.java
f76664673eed1c7b2fa141ce99e01028bc7a1be0 28-Apr-2013 Craig Mautner <cmautner@google.com> Clean up FocusedStackFrame layer setting.

- Putting the stack frame above the highest app window layer ends up
putting it over the IME when the caret popup is showing. This puts
the stack frame layer above the highest non-child window layer.

- Also change the timing so the layer isn't applied until all other
layers are also being applied.

Change-Id: Ic5f142998822ac1e3890a2943cda7fc86a7e7974
/frameworks/base/services/java/com/android/server/wm/WindowStateAnimator.java
cc979c9eae387d80e4c4129d18991d708dde44a6 11-Apr-2013 Craig Mautner <cmautner@google.com> Merge "Debug logging improvement." into jb-mr2-dev
66d7730903a0163711e3d037c2350d6a13368004 11-Apr-2013 Craig Mautner <cmautner@google.com> Debug logging improvement.

Previously a change to a surface would be logged with the old value
and you had to scroll through the logs to see what the new value
was. This change reflects the change to the surface immediately.

Change-Id: I2a6566466287922d08f4ce2329c61aa46d692ee1
/frameworks/base/services/java/com/android/server/wm/WindowStateAnimator.java
a57c695bf2c0f917517ecac8251043716b34f72d 29-Mar-2013 Dianne Hackborn <hackbod@google.com> Reduce duration of rotation xfade animation.

Also add code for tracking how long a rotation takes,
and who is causing it to take that time.

Change-Id: Ie3352ddfddd247f5a5c08f7da6bfe6b4da607ba2
/frameworks/base/services/java/com/android/server/wm/WindowStateAnimator.java
29479ebe1007361222bf6ab4d5e2a27927d4b8e8 14-Feb-2013 Mathias Agopian <mathias@google.com> clean-up following Surface split

Change-Id: I853a76d92d957ee38a36fcdd280d6407ec316987
/frameworks/base/services/java/com/android/server/wm/WindowStateAnimator.java
3866f0d581ceaa165710feeee9f37fe1b0d7067d 12-Feb-2013 Mathias Agopian <mathias@google.com> split Surface in two classes: SurfaceControl and Surface

SurfaceControl is the window manager side; it can
control the attributes of a surface but cannot push buffers
to it. Surface on the other hand is the application (producer)
side and is used to push buffers to the surface.

Change-Id: Ib6754c968924e87e8dd02a2073c7a447f729f4dd
/frameworks/base/services/java/com/android/server/wm/WindowStateAnimator.java
ef6550195f2f403e5ace27d49ae4f7f38d29cf4a 03-Jan-2013 Craig Mautner <cmautner@google.com> Release Session earlier, release Session later.

For finishDrawingWindow queue the performLayoutAndPlaceSurfaces call
and return immediately.

For setTransparentRegionHint call the WindowStateAnimator method
immediately, removing the previous queueing of it.

Fixes bug 7174665.

Change-Id: Ia52f9a6685842220e4ffca6e214ee366470ff666
/frameworks/base/services/java/com/android/server/wm/WindowStateAnimator.java
73164dc7bce52f6658eb2f786c45538e52404ab4 08-Jan-2013 Craig Mautner <cmautner@google.com> Merge "Combine DimAnimator and DimSurface into DimLayer"
1420b93fa5606979fd67eaf80f50294d4f8c191b 29-Dec-2012 Craig Mautner <cmautner@google.com> Combine DimAnimator and DimSurface into DimLayer

Replace two classes that did similar things in a complicated manner
with one class that does it more simply.

Bug 7064755 fixed.

Change-Id: I8c415671f60d1d2ece9da5916421f4d24aed2d65
/frameworks/base/services/java/com/android/server/wm/WindowStateAnimator.java
581068131c192a8c495fac00d3c61807580c7eca 28-Dec-2012 Craig Mautner <cmautner@google.com> Remove some TODOs.

Change-Id: I52f5a8a76593dde177c2e931f656b13134a3bd2b
/frameworks/base/services/java/com/android/server/wm/WindowStateAnimator.java
4b71aa1f8a1a3b7189fd29241ea7c594ce01623c 28-Dec-2012 Craig Mautner <cmautner@google.com> Move app transition constants

Move app transition constants from WindowManagerPolicy to
AppTransition.

Change-Id: I8ae6c4d0da1db826c44eb4ea0c6b85016b50b1a3
/frameworks/base/services/java/com/android/server/wm/WindowStateAnimator.java
72669d18016446d874e4fa1005464e36375124e4 19-Dec-2012 Craig Mautner <cmautner@google.com> Fixes to clean up icon launching during animations.

Several problems were causing animations to jump to the end when
launching an app while a previous app was animating away.

- Keep the two app token lists in tighter synch. These were separated
when we hoped to completely separate layout form animation. This is
not as critical a goal any more.

- Use new test criteria for starting and stopping animations.

Bug 7885350 fixed.

Change-Id: Ib679117f627d0957cda17cc6ffca2bc2cdd6ecdd
/frameworks/base/services/java/com/android/server/wm/WindowStateAnimator.java
545252f4fde6fbb70b07e97a120c7d1405758017 11-Dec-2012 Svetoslav Ganov <svetoslavganov@google.com> Refactoring of the screen magnification feature.

1. This patch takes care of the case where a magnified window is covering an unmagnigied
one. One example is a dialog that covers the IME window.

bug:7634430

2. Ensuring that the UI automator tool can connect and correctly dump the screen.

bug:7694696

3. Removed the partial implementation for multi display magnification. It adds
unnecessary complexity since it cannot be implemented without support for
input from multiple screens. We will revisit when necessary.

4. Moved the magnified border window as a surface in the window manager.

5. Moved the mediator APIs on the window manager and the policy methods on the
WindowManagerPolicy.

6. Implemented batch event processing for the accessibility input filter.

Change-Id: I4ebf68b94fb07201e124794f69611ece388ec116
/frameworks/base/services/java/com/android/server/wm/WindowStateAnimator.java
66f78d7a979775efb148873797bac4584ddb3b83 05-Dec-2012 Craig Mautner <cmautner@google.com> Share the pending layout changes

Do not pass the pending layout changes from animation to layout.
Simply assign them to the DisplayContent.

Change-Id: I72e48753db509023e5df70513a87e26998ec699f
/frameworks/base/services/java/com/android/server/wm/WindowStateAnimator.java
968683335e17c06504a11bc2e38a2580f613ea16 04-Dec-2012 Craig Mautner <cmautner@google.com> Recouple layout and animation a bit.

Share state between layout and animation and stop copying
redundant data between the two.

Change-Id: If07d3fc3ddfd33e3d46bf45d24d7aca58067ee66
/frameworks/base/services/java/com/android/server/wm/WindowStateAnimator.java
152e9bb81aa5b2ab4637f4b2dae04b3ce89fa891 13-Oct-2012 Svetoslav Ganov <svetoslavganov@google.com> Refactoring of the screen magnification feature.

1. The screen magnification feature was implemented entirely as a part of the accessibility
manager. To achieve that the window manager had to implement a bunch of hooks for an
external client to observe its internal state. This was problematic since it dilutes
the window manager interface and allows code that is deeply coupled with the window
manager to reside outside of it. Also the observer callbacks were IPCs which cannot
be called with the window manager's lock held. To avoid that the window manager had
to post messages requesting notification of interested parties which makes the code
consuming the callbacks to run asynchronously of the window manager. This causes timing
issues and adds unnecessary complexity.

Now the magnification logic is split in two halves. The first half that is responsible
to track the magnified portion of the screen and serve as a policy which windows can be
magnified and it is a part of the window manager. This part exposes higher level APIs
allowing interested parties with the right permissions to control the magnification
of a given display. The APIs also allow a client to be registered for callbacks on
interesting changes such as resize of the magnified region, etc. This part servers
as a mediator between magnification controllers and the window manager.

The second half is a controller that is responsible to drive the magnification
state based on touch interactions. It also presents a highlight when magnified to
suggest the magnified potion of the screen. The controller is responsible for auto
zooming out in case the user context changes - rotation, new actitivity. The controller
also auto pans if a dialog appears and it does not interesect the magnified frame.

bug:7410464

2. By design screen magnification and touch exploration work separately and together. If
magnification is enabled the user sees a larger version of the widgets and a sub section
of the screen content. Accessibility services use the introspection APIs to "see" what
is on the screen so they can speak it, navigate to the next item in response to a
gesture, etc. Hence, the information returned to accessibility services has to reflect
what a sighted user would see on the screen. Therefore, if the screen is magnified
we need to adjust the bounds and position of the infos describing views in a magnified
window such that the info bounds are equivalent to what the user sees.

To improve performance we keep accessibility node info caches in the client process.
However, when magnification state changes we have to clear these caches since the
bounds of the cached infos no longer reflect the screen content which just got smaller
or larger.

This patch propagates not only the window scale as before but also the X/Y pan and the
bounds of the magnified portion of the screen to the introspected app. This information
is used to adjust the bounds of the node infos coming from this window such that the
reported bounds are the same as the user sees not as the app thinks they are. Note that
if magnification is enabled we zoom the content and pan it along the X and Y axis. Also
recomputed is the isVisibleToUser property of the reported info since in a magnified
state the user sees a subset of the window content and the views not in the magnified
viewport should be reported as not visible to the user.

bug:7344059

Change-Id: I6f7832c7a6a65c5368b390eb1f1518d0c7afd7d2
/frameworks/base/services/java/com/android/server/wm/WindowStateAnimator.java
00d6a76c3d954db631b25f2bcde9287c276ed705 30-Nov-2012 Dianne Hackborn <hackbod@google.com> am a55097f8: am ed74c10f: am aae329ef: Merge "Don\'t apply transformation fudge when not rotating." into jb-mr1.1-dev

* commit 'a55097f8bb7871ef909c7005b6fa1b6b7cf06b16':
Don't apply transformation fudge when not rotating.
4b16969b006613bff4901a6e979f29a0f501430b 30-Nov-2012 Dianne Hackborn <hackbod@google.com> Don't apply transformation fudge when not rotating.

There is this stupid fudge factor applied to window transformations
when doing a screen rotation animation. We need this when rotating,
but when not rotating it causes very visible artifacts. Historically
the non-rotation case only happened due to configuration changes, so
wasn't that big a deal. Now however that we use this when switching
users, it is more annoying. So get rid of it for such cases.

Change-Id: I6b343866c1bad9b16984b4a629917c2f1bb37b9e
/frameworks/base/services/java/com/android/server/wm/WindowStateAnimator.java
8f0bdb5bb64044202c1090120f1193c4ff4a9fdf 29-Nov-2012 Craig Mautner <cmautner@google.com> Merge "Extract AppTransition from WindowManager"
8c6008e7e84877afbda14a3fc6fce1c0872ff8f7 28-Nov-2012 Craig Mautner <cmautner@google.com> am ae336a08: am 067a7ac4: am 9e98927e: Merge "Retain configuration change info and sync access." into jb-mr1.1-dev

* commit 'ae336a08ddc402372e3ba16dfaf50cfb837cf74d':
Retain configuration change info and sync access.
e8552142494bbb4438a8748707f74b1ce241ea48 07-Nov-2012 Craig Mautner <cmautner@google.com> Retain configuration change info and sync access.

- If a window was hidden while the configuration changed and then
changed back WindowManagerService would not know that the change
had ever happened and wouldn't notify the window of this. Most
windows wouldn't care but because Keyguard inflates layouts while
it is hidden...

Bug 7094175 fixed?
Bug 7501099 fixed!

Change-Id: If27f5f1d333602dac7719dd39dbdf3fe7954aa06
/frameworks/base/services/java/com/android/server/wm/WindowStateAnimator.java
164d4bb4c3eeba1488d9b4994980d24c1f6ec961 26-Nov-2012 Craig Mautner <cmautner@google.com> Extract AppTransition from WindowManager

Refactor of WindowManagerService to move app transitions out.

Change-Id: Id3e377526a69f95a3ee4c0d97ca6fd84005beb6a
/frameworks/base/services/java/com/android/server/wm/WindowStateAnimator.java
7636dfbc3331dec0cea374a9540a1f31fb7dbf77 17-Nov-2012 Craig Mautner <cmautner@google.com> Do not clear AppWindowToken.allDrawn while animating.

Creating new surfaces for applications clears the allDrawn flag in the
AppWindowToken. If the app windows were animating when this happened
the animation would complete immediately resulting in jank. This fix
defers clearing allDrawn until the animation completes.

Bug 7326635 fixed.

Change-Id: I5abe3b9ecfbefb476de6a6c8acc394373cc11751
/frameworks/base/services/java/com/android/server/wm/WindowStateAnimator.java
98129739afcb3786a6ec9f3efe774d8e01f6d632 02-Nov-2012 Dianne Hackborn <hackbod@google.com> Fix issue #7343200: Fails to show wallpaper in the background for...

...lockscreen sometimes and remains black / blank

The problem was that we were using the animation-side wallpaper state
in cases where it was not updated yet.

The mWallpaperTarget variable is propagated over to the animation
side when the main window manager state updates. On the animation
side, this is used by hideWallpapersLocked() to determine if the
current wallpaper should be hidden.

The problem is that various paths to hideWallpapersLocked() can
come from the layout side of the window manager instead of the
animation side. This causes the problem here because in this case
the wallpaper state may not have yet been propagated to the
animation side, so it could incorrectly decide to hide the wallpaper
because it thinks there is not a target when in fact a target is
set in the layout side. This won't get fixed until some time way
later that the layout side decides that a new window is being shown
that may need to have the wallpaper shown.

The fix here is pretty gross, but as safe as possible -- the
hideWallpapersLocked() function now uses either the animation or
layout wallpaper state depending on where the call to it is coming
from.

Change-Id: I9250bfeae6e11c1761760bcc696fdb33fb5c8a5f
/frameworks/base/services/java/com/android/server/wm/WindowStateAnimator.java
529e744d3131b9ebeb6b33c8030230c29a44ad12 01-Nov-2012 Dianne Hackborn <hackbod@google.com> More debugging for issue #7343200 Fails to show wallpaper in the...

...background for lockscreen sometimes and remains black / blank

There was a bunch of state not being put into the dumpsys output.
In particular, the current wallpaper target of the WindowAnimator
was not being included. I think the problem is that these targets
are not being updated from the main window manager state at some
point where they need to be.

Change-Id: Ic795047f6aea9b6f72d5550bccc9f8d76c6ecb67
/frameworks/base/services/java/com/android/server/wm/WindowStateAnimator.java
33877e15b8bfc50bd874027689a4794aa93b923d 07-Oct-2012 Craig Mautner <cmautner@google.com> Merge "Adds showWhenLocked attribute to Activities." into jb-mr1-dev
5962b12bedc4a1d0354816c1cd6b06ba04f6d807 05-Oct-2012 Craig Mautner <cmautner@google.com> Adds showWhenLocked attribute to Activities.

The new attribute allows an Activity such as the alarm to appear
on all users screens.

Bug: 7213805 fixed.
Change-Id: If7866b13d88c04af07debc69e0e875d0adc6050a
/frameworks/base/services/java/com/android/server/wm/WindowStateAnimator.java
4c1e3183baf39ab69c0289c1511877a8bb0b0f75 06-Oct-2012 Dianne Hackborn <hackbod@google.com> Fix issue #7296314, issue #7296314.

7296314 Crashing dreams are stuck
7296510 Transition from lock screen to dreaming is really bad

The window layer for dreams is now moved down below the keyguard,
so that some of the expected stuff like crash and ANR dialogs can
be seen on top of them. While doing this, I reorganized how we
define the layers so the constants are just in the switch statement,
so it is much less crazy-making trying to read how things go
together.

We now have some special cases for when a dream is being shown
to turn off its animation if the keyguard is currently shown.
Since we know it will be hiding the keyguard we need it to be
shown immediately so that you don't see whatever is behind it.

Cleaned up some handling of when the lock screen is displayed
while a FLAG_SHOW_WHEN_LOCKED window is displayed, so that the
lockscreen doesn't transiently get shown and mess up the fullscreen
or system UI state. This also fixes problems with any normal
activity that is doing this.

Hid the methods on DreamService for setting lights out mode. It
doesn't make sense to have such methods on DreamService, because
you can just as well do that on your own View that is showing the
dream content, and when you can do that you can fully participate
in the (required) interactions about it such as being told when
the mode goes away.

The DreamService method for going fullscreen now uses the window
flag for doing this, which is what you want, because you want this
state to persistent on that window and not get knocked out if
something above the window tickles the system UI state.

Also fixed the problem where dreams that hid the status bar would
have a jerky animation when going away, since they were causing the
activity behind them to be layed out without the lock screen. This
is a kind-of ugly special case in the window manager right now to
just not layout windows that are behind a dream. Good enough for MR1.

Change-Id: Ied2ab86ae068b1db0ff5973882f6d17b515edbcd
/frameworks/base/services/java/com/android/server/wm/WindowStateAnimator.java
88400d3a31139c40c4014faf86c243647087ef6c 30-Sep-2012 Craig Mautner <cmautner@google.com> Add flag for displaying non-user's Windows to user.

Created a new flag that indicates that a window should be shown
to all users. For the flag to be valid the owner of the window
must have system permissions.

Also separated system window types into those that show to all
users (e.g. StatusBar, Keyguard, ....) and those that appear only
to the owning users (e.g. Drag, ANR, TOAST, ...). Those that appear
only to their owner can override their default behavior using
the new flag (e.g. LowBattery).

Fixes bug 7211965.

Change-Id: I1fdca25d57b7b523f0c7f8bceb819af656c388d4
/frameworks/base/services/java/com/android/server/wm/WindowStateAnimator.java
28e0b09a3d22de80cca05499e98a23d5dd82fa15 25-Sep-2012 Jeff Brown <jeffbrown@google.com> Fix typo.

Bug: 7183618
Change-Id: I0c761fc7f55b3f182007cb4d50cbfdce309f844a
/frameworks/base/services/java/com/android/server/wm/WindowStateAnimator.java
3671410b9e09e1c5ec05dfc58651a8efaa7790dd 25-Sep-2012 Jeff Brown <jeffbrown@google.com> Fix dialogs on secondary displays.

Bug: 7183618
Change-Id: I65b650a0c423f3081c412a7341b7427b6ac85e24
/frameworks/base/services/java/com/android/server/wm/WindowStateAnimator.java
8863cca57d8c901a2da0edc422b653ae68849313 19-Sep-2012 Craig Mautner <cmautner@google.com> Fixes to Starting window and Wallpaper windows.

- Checking for found wallpaper to match either mWallpaperTarget
or mLowerWallpaperTarget keeps from swapping the layers while
transitioning between two wallpaper activities.

- Fade out RecentsActivity while bringing up selected activity. This
keeps the RecentsActivity from showing through a launching wallpaper
activity.

- When moving a starting window from one activity to another clear
the startingDisplayed flag in the old activity.

- When moving a starting window from one activity to another assign
the new activity's mAppAnimator to the starting window's mWinAnimator.

- Only treat a wallpaper transition as entering if the mWallpaperTarget
is visible and not being hidden. Keeps from assigning the wrong
animation when activities are launched back to back and the
mWallpaperTarget is still animating away.

Fixes bug 7148089.

Change-Id: Idd405b1ba113f3345ca2116d141b474abe5bd4c0
/frameworks/base/services/java/com/android/server/wm/WindowStateAnimator.java
a91f9e2959ee905f97977a88fe45bde6ffb874b0 15-Sep-2012 Craig Mautner <cmautner@google.com> Make more items per-Display.

Moving DimSurfaces, DimBackgrounds and Rotation surfaces into
per-display class.

Fixes bug 7167028.

Change-Id: I7408b3a27b5a7a8d0d59e9d6109c002fc627e536
/frameworks/base/services/java/com/android/server/wm/WindowStateAnimator.java
1cf70bbf96930662cab0e699d70b62865766ff52 06-Aug-2012 Svetoslav Ganov <svetoslavganov@google.com> Screen magnification - feature - framework.

This change is the initial check in of the screen magnification
feature. This feature enables magnification of the screen via
global gestures (assuming it has been enabled from settings)
to allow a low vision user to efficiently use an Android device.

Interaction model:

1. Triple tap toggles permanent screen magnification which is magnifying
the area around the location of the triple tap. One can think of the
location of the triple tap as the center of the magnified viewport.
For example, a triple tap when not magnified would magnify the screen
and leave it in a magnified state. A triple tapping when magnified would
clear magnification and leave the screen in a not magnified state.

2. Triple tap and hold would magnify the screen if not magnified and enable
viewport dragging mode until the finger goes up. One can think of this
mode as a way to move the magnified viewport since the area around the
moving finger will be magnified to fit the screen. For example, if the
screen was not magnified and the user triple taps and holds the screen
would magnify and the viewport will follow the user's finger. When the
finger goes up the screen will clear zoom out. If the same user interaction
is performed when the screen is magnified, the viewport movement will
be the same but when the finger goes up the screen will stay magnified.
In other words, the initial magnified state is sticky.

3. Pinching with any number of additional fingers when viewport dragging
is enabled, i.e. the user triple tapped and holds, would adjust the
magnification scale which will become the current default magnification
scale. The next time the user magnifies the same magnification scale
would be used.

4. When in a permanent magnified state the user can use two or more fingers
to pan the viewport. Note that in this mode the content is panned as
opposed to the viewport dragging mode in which the viewport is moved.

5. When in a permanent magnified state the user can use three or more
fingers to change the magnification scale which will become the current
default magnification scale. The next time the user magnifies the same
magnification scale would be used.

6. The magnification scale will be persisted in settings and in the cloud.

Note: Since two fingers are used to pan the content in a permanently magnified
state no other two finger gestures in touch exploration or applications
will work unless the uses zooms out to normal state where all gestures
works as expected. This is an intentional tradeoff to allow efficient
panning since in a permanently magnified state this would be the dominant
action to be performed.

Design:

1. The window manager exposes APIs for setting accessibility transformation
which is a scale and offsets for X and Y axis. The window manager queries
the window policy for which windows will not be magnified. For example,
the IME windows and the navigation bar are not magnified including windows
that are attached to them.

2. The accessibility features such a screen magnification and touch
exploration are now impemented as a sequence of transformations on the
event stream. The accessibility manager service may request each
of these features or both. The behavior of the features is not changed
based on the fact that another one is enabled.

3. The screen magnifier keeps a viewport of the content that is magnified
which is surrounded by a glow in a magnified state. Interactions outside
of the viewport are delegated directly to the application without
interpretation. For example, a triple tap on the letter 'a' of the IME
would type three letters instead of toggling magnified state. The viewport
is updated on screen rotation and on window transitions. For example,
when the IME pops up the viewport shrinks.

4. The glow around the viewport is implemented as a special type of window
that does not take input focus, cannot be touched, is laid out in the
screen coordiates with width and height matching these of the screen.
When the magnified region changes the root view of the window draws the
hightlight but the size of the window does not change - unless a rotation
happens. All changes in the viewport size or showing or hiding it are
animated.

5. The viewport is encapsulated in a class that knows how to show,
hide, and resize the viewport - potentially animating that.
This class uses the new animation framework for animations.

6. The magnification is handled by a magnification controller that
keeps track of the current trnasformation to be applied to the screen
content and the desired such. If these two are not the same it is
responsibility of the magnification controller to reconcile them by
potentially animating the transition from one to the other.

7. A dipslay content observer wathces for winodw transitions, screen
rotations, and when a rectange on the screen has been reqeusted. This
class is responsible for handling interesting state changes such
as changing the viewport bounds on IME pop up or screen rotation,
panning the content to make a requested rectangle visible on the
screen, etc.

8. To implement viewport updates the window manger was updated with APIs
to watch for window transitions and when a rectangle has been requested
on the screen. These APIs are protected by a signature level permission.
Also a parcelable and poolable window info class has been added with
APIs for getting the window info given the window token. This enables
getting some useful information about a window. There APIs are also
signature protected.

bug:6795382

Change-Id: Iec93da8bf6376beebbd4f5167ab7723dc7d9bd00
/frameworks/base/services/java/com/android/server/wm/WindowStateAnimator.java
69b0818179201fadc9d2a384d692d8ae4aecd85c 05-Sep-2012 Craig Mautner <cmautner@google.com> Limit certain actions to default Display.

Stop messing up PhoneWindowManager state when passing in windows
from non-default Display.

Change-Id: I472f7a13c5e2241fbf1f79ae1c8045fd92af016c
/frameworks/base/services/java/com/android/server/wm/WindowStateAnimator.java
19d59bc5ad877e9b1544ab13a08282b7b384fefb 04-Sep-2012 Craig Mautner <cmautner@google.com> Make mLayoutNeeded per-Display.

Switch from a global mLayoutNeeded to one for each Display so that
we don't run layout on Displays that haven't changed.

Change-Id: Ib65c5c667933cceacc46b94f4e6e6bd613d5cb35
/frameworks/base/services/java/com/android/server/wm/WindowStateAnimator.java
76a7165719dc3ccce902953f6244e2c2668aa753 04-Sep-2012 Craig Mautner <cmautner@google.com> Change layout inner loop order for multi display.

The inner loop that ran over each display had a few problems:
- The Surface transaction was starting and stopping between each
display.
- The layout change bits were being applied globally so all
displays were layed out when only individual displays needed to be.
- Wallpaper and input actions were being applied each time through
the display loop rather than once only for the default display.

Change-Id: I924252bab28c426222a4bb73693accc4b21cecbe
/frameworks/base/services/java/com/android/server/wm/WindowStateAnimator.java
64a55af0ac700baecb0877235eb42caac59a3560 26-Aug-2012 Jeff Brown <jeffbrown@google.com> Add plumbing for new surface flinger display API.

Cleaned up the implementation of Surface and SurfaceSession
to use more consistent naming and structure.

Added JNI for all of the new surface flinger display API calls.

Enforced the requirement that all Surfaces created by
the window manager be named.

Updated the display manager service to use the new methods.

Change-Id: I2a658f1bfd0437e1c6f9d22df8d4ffcce7284ca2
/frameworks/base/services/java/com/android/server/wm/WindowStateAnimator.java
b47bbc3d80badb94229bc4ce7a2d5006faa9ef15 23-Aug-2012 Craig Mautner <cmautner@google.com> Clean up displayId and layerStack usage.

Make better use of Display object by saving it in DisplayContent.
Only use layerStack when referring to Surfaces. Get displayId from
default Display or default DisplayContent. Remove warnings.

Fixes bug 7038151.

Change-Id: Ie493f0f5e755dc9b91ee969ff561c2a098283ead
/frameworks/base/services/java/com/android/server/wm/WindowStateAnimator.java
7e877fa00c6b093a0fe734e5d3bf23b5b2d6411e 22-Aug-2012 Craig Mautner <cmautner@google.com> Merge "Fix to allow SYSTEM_UID to display windows." into jb-mr1-dev
a2d7b1117abc23a3ff0ccda15a2f9138aaa7f4fc 22-Aug-2012 Craig Mautner <cmautner@google.com> Fix to allow SYSTEM_UID to display windows.

Was not previously checking to make sure that the appId was not
SYSTEM_UID (1000). This caused certain system windows to fail to
appear.

Change-Id: I939dc2f8a256acb84b7c413c7e00003a89aff6d4
/frameworks/base/services/java/com/android/server/wm/WindowStateAnimator.java
de1d96c736730c2a99a225311b9211a34042f9d4 21-Aug-2012 Craig Mautner <cmautner@google.com> Merge "Hide non user app windows from other users." into jb-mr1-dev
9dc52bc44c94854fcd3384a045b4b862e30e25de 06-Aug-2012 Craig Mautner <cmautner@google.com> Hide non user app windows from other users.

When transitioning between old user and new user application windows
from the old user may not be shown because only one user's windows
can be shown at a time.

Change-Id: I4e17b36c9100c9457cc6eb3cb3b77f3a94fa2b41
/frameworks/base/services/java/com/android/server/wm/WindowStateAnimator.java
98365d7663cbd82979a5700faf0050220b01084d 20-Aug-2012 Jeff Brown <jeffbrown@google.com> Refactor for multi-display support.

Split WindowManagerImpl into two parts, the WindowManager
interface implementation remains where it is but the global
communications with the window manager are now handled by
the WindowManagerGlobal class. This change greatly simplifies
the challenge of having separate WindowManager instances
for each Context.

Removed WindowManagerImpl.getDefault(). This represents the
bulk of this change. Most of the usages of this method were
either to perform global functions (now handled by WindowManagerGlobal)
or to obtain the default display (now handled by DisplayManager).

Explicitly associate each new window with a display and make
the Display object available to the View hierarchy.

Add stubs for some new display manager API features.

Start to split apart the concepts of display id and layer stack.
since they operate at different layers of abstraction.
While it's true that each logical display uniquely corresponds to a
surface flinger layer stack, it is not necessarily the case that
they must use the same ids. Added Display.getLayerStack()
and started using it in places where it was relatively easy to do.

Change-Id: I29ed909114dec86807c4d3a5059c3fa0358bea61
/frameworks/base/services/java/com/android/server/wm/WindowStateAnimator.java
9de4936c99b979f6010440b043edc6d6142d1980 02-Aug-2012 Craig Mautner <cmautner@google.com> Add features to DisplayManager.

Added Surface.setDisplayId().
Added callbacks to DisplayManagerService.

Change-Id: Idd3f85f8ca1f1208962f1196efd6a3ab51c8c259
/frameworks/base/services/java/com/android/server/wm/WindowStateAnimator.java
59c009776dae5ccbdfb93d7151ff2065ca049dc3 30-Jul-2012 Craig Mautner <cmautner@google.com> Introduce multiple displays with DisplayContent.

Fix a couple of bugs that turned up.
Remove touch/focus from display. Add iterators for access.
Respond to comments. Remove TODOs, and some deviceId parameters.

Change-Id: Idcdb4f1979aa7b14634d450fd0333d6eff26994d
/frameworks/base/services/java/com/android/server/wm/WindowStateAnimator.java
6881a10557acf3b0270de54799d6f19437acf584 27-Jul-2012 Craig Mautner <cmautner@google.com> Small step towards supporting multiple displays

Change-Id: I353449c2b464394988c7e0203656b5851a0c9127
/frameworks/base/services/java/com/android/server/wm/WindowStateAnimator.java
fa25bf5382467b1018bd9af7f1cb30a23d7d59f7 24-Jul-2012 Jeff Brown <jeffbrown@google.com> Add display manager skeleton.

The purpose of this change is to remove direct reliance on
SurfaceFlinger for describing the size and characteristics of
displays.

This patch also starts to make a distinction between logical displays
and physical display devices. Currently, the window manager owns
the concept of a logical display whereas the new display
manager owns the concept of a physical display device.

Change-Id: I7e0761f83f033be6c06fd1041280c21500bcabc0
/frameworks/base/services/java/com/android/server/wm/WindowStateAnimator.java
c69238ebc8d011ce225c9540bcf4e79bd3fa8eb0 17-Jul-2012 Jeff Brown <jeffbrown@google.com> Merge "Remove dithering support."
3cc321ecf505d87850740ad3c63849e6793a8ef6 17-Jul-2012 Jeff Brown <jeffbrown@google.com> Remove dithering support.

The dithering flag is no longer implemented in Surface Flinger
so this is all dead code.

Change-Id: I74c0e452923207e5b7cfe0eeca9457e5cb990947
/frameworks/base/services/java/com/android/server/wm/WindowStateAnimator.java
322e40315609acd5a608440bc469d873e09559ca 13-Jul-2012 Craig Mautner <cmautner@google.com> Further isolate layout side from animation side.

- Use local AppWindowAnimators in WindowAnimator rather than
using shared WindowManagerService objects.
- Use local WindowStateAnimators in AppWindowAnimator rather
than use AppToken's WindowState objects.
- Remove redundant WindowManagerService parameter passed to
AppWindowAnimator ctor.
- Keep from copying parameters from performLayout if the
parameters haven't changed since the last copy.
- Link WindowStateAnimator to AppWindowAnimator to keep
from going through WindowStateAnimator.mWin,
WindowState.mAppToken and AppWindowToken.mAppAnimator.
- Converted attached WindowState in WindowStateAnimator to
WindowStateAnimator to eliminate multiple conversions.

Change-Id: I5e35af88d8fdc1a7454984eaea91a1bc4f926978
/frameworks/base/services/java/com/android/server/wm/WindowStateAnimator.java
918b53bc531f5bd1ea102e8b827d693bd4d0555b 09-Jul-2012 Craig Mautner <cmautner@google.com> Isolate layout and animation wallpaper objects.

Provide separate copies of mWallpaperTarget, mWallpaperTokens, and
mLower/UpperWallpaperTarget in the layout and animation sides of
Window Manager.

Simplify constructors of WindowAnimator and WindowStateAnimator.

Change-Id: I7e35794a432c25c4194c046e9e27150d1c905403
/frameworks/base/services/java/com/android/server/wm/WindowStateAnimator.java
2639da500e3d53ea3a17d888b1c0001d043c6b98 09-Jul-2012 Craig Mautner <cmautner@google.com> Fix hang on rotation.

A recent optimization to only send updates to WindowManagerService
when there is something to report backfired. One bit indicating
change had negative polarity so the update should also have been
sent when this bit was cleared. This change alters the bit to
positive polarity.

Fixes bug 6780496.

Change-Id: I3336812a60534ebffc9e94b2fb1d0df4d6969bca
/frameworks/base/services/java/com/android/server/wm/WindowStateAnimator.java
a76fdb7713d900763cff090557a10d3942b9b3ca 04-Jul-2012 Craig Mautner <cmautner@google.com> Use new object to sync DimAnimator.

The controls for the DimAnimator were going through the H Handler
to sync with the Animator. We are switching to using the
LayoutToAnimator object for passing data from layout to animator.

Change-Id: Ib6d0afabba781c88bcc1c525e3ae424cf19ac1ad
/frameworks/base/services/java/com/android/server/wm/WindowStateAnimator.java
711f90a7c1e99a435fa8f5335f13772f0b41270b 04-Jul-2012 Craig Mautner <cmautner@google.com> Swap source and destination transfer objects.

It will be better to have the object that moves layout parameters to
animation on the layout side, and the object that moves animation
parameters back to layout on the animation side. That way we can
do partial filling of these objects without calling across. We
may never do partial draining of these objects.

Change-Id: I88826fa97350f96e309beef386885f55a9a73305
/frameworks/base/services/java/com/android/server/wm/WindowStateAnimator.java
6fbda63e68513ece4409dac845588711ab25c39d 03-Jul-2012 Craig Mautner <cmautner@google.com> Merge CL 202423/3 App launching has random pauses.

Change-Id: Iba5616182c02e51f4d9063d0a01b30b9f558549a
/frameworks/base/services/java/com/android/server/wm/WindowStateAnimator.java
a4b7f2f75e7803193429ec1179fb5e2eb1c6fbda 21-May-2012 Dianne Hackborn <hackbod@google.com> Use two fingers to work some magic...

Change-Id: Ibcb3dbd3d158c22da8277e544d81fb47eadccd49
/frameworks/base/services/java/com/android/server/wm/WindowStateAnimator.java
9e809448761878b72b47c0a0e703de95a3cf9815 23-Jun-2012 Craig Mautner <cmautner@google.com> Step 1 in consolidating wallpaper animation.

- Merge testWallpaperAndBackgroundLocked into
updateWindowsAndWallpaperLocked. Eliminates mDetachedWallpaper,
mWindowAnimationBackground, and mWindowAnimationBackgroundColor.

- Merge multiple calls to perform layout into one.

- Cleaned up debug output.

Change-Id: I5dc2d8330dc092ee2b165867cddb7d16b431fa0b
/frameworks/base/services/java/com/android/server/wm/WindowStateAnimator.java
f41209568617f4acfaf6dea8f8b2cbe9c2994a3e 22-Jun-2012 Craig Mautner <cmautner@google.com> Fix starting window problems.

Three problems fixed:
1. When one Activity took over for another Activity not all of the
starting window state was being copied over. Now copying over more
parameters.

2. When the visibility of an Activity was being changed the dummy
animation was overwriting the existing animation. If that animation
was the starting window animating then it started over when the
dummy animation was assigned. Now the dummy animation no longer
replaces an existing starting window animation.

3. The test for whether to animate away the starting window only
looked to see if the Activity had already drawn a window but did
not include the starting window. This caused the starting window
to immediately be hidden when the Activity was removed if no
windows were drawn, thereby exposing the fading window behind.
Now the starting window is included in the hasAppShownWindows test
and is animated away if it is exposed.

Fixes bug 6691421.

Change-Id: I4d32a1546c201652574a44d9e7f2752f1f1eb5a6
/frameworks/base/services/java/com/android/server/wm/WindowStateAnimator.java
6e2281d44c9b71a03a50ed24d654927111cd2b72 20-Jun-2012 Dianne Hackborn <hackbod@google.com> Fix issue #6686339: 2 taps required to launch notification...

...or settings from lock screen

When a window is drawn, the code to determine whether it should now
be shown was calling WindowState.isReadyForDisplay(). Part of the
condition of this function is that it is not ready if a policy is
forcing the window to be hidden -- which is the case when the lock
screen is shown. As a result, we wouldn't show the window at that
point, so wouldn't tell the activity manager that the token's windows
are visibible, and wouldn't tell the lock screen to go away.

This adds a new variation WindowState.isReadyForDisplayIgnoringKeyguard(),
which is the same as the original method but ignores the policy visibility
for app windows. This allows windows to be go through the complete
path of handling when the window is finally drawn and telling the
activity manager about it, even if behind the lock screen. By making it
a separate function, we don't impact any other code that is calling the
old function and may be relying on its behavior.

Also cleaned up a little of the dumpsys output. Most important, the
new ANR section is now moved to the top, since we want
"adb shell dumpsys window" to still give a nice summary of what we
normally care about -- the window stack and important global state.

Change-Id: Ica3ea85ce46f3f5f5cd2cc30fbd9de13d3885a57
/frameworks/base/services/java/com/android/server/wm/WindowStateAnimator.java
507a2ee12b6d1d683e4a5806804c472b3fe32e61 13-Jun-2012 Craig Mautner <cmautner@google.com> Update wallpaper visibility at time of hide/show.

Call the Window client method dispatchAppVisibility when hiding or
showing wallpaper rather than wait until the next call to
performLayoutAndPlaceSurfaces.

Fixes bug 6645473.

Change-Id: I363f69f8db0affff92308e11ce52546401959d8f
/frameworks/base/services/java/com/android/server/wm/WindowStateAnimator.java
0fa77c1e0fc218040efc570936e988dbeece399c 12-Jun-2012 Craig Mautner <cmautner@google.com> Remove over aggressive optimization.

It turns out that sometimes the wallpaper target is migrated to the
bottom of the window stack and then mWallpaperTarget is set to null.
In particular this happens when the launcher all-apps screen is
brought up. When this happens the layer of the wallpaper is
correctly set below the previous wallpaper target.

An optimization in WindowAnimator was keeping the layer update from
propagating to the Surface object. This fix removes that optimization.

Fixes bug 6631717.

Change-Id: I800dd043ce8df83b4e5edbf710503135396bc01e
/frameworks/base/services/java/com/android/server/wm/WindowStateAnimator.java
c38869abe5d89b7f9e66f23599889e17b93b5eec 12-Jun-2012 Craig Mautner <cmautner@google.com> Revert "Merge errors."

This reverts commit b0419a52008e57475ee254def1da20451da22d4c.
/frameworks/base/services/java/com/android/server/wm/WindowStateAnimator.java
a5bbb8987b98fdbef45549103f70979f4e1e9e4d 12-Jun-2012 Craig Mautner <cmautner@google.com> Merge errors.

Change-Id: I33d0b1aa5dc5018cc879d2e9878e4825adaa4074
/frameworks/base/services/java/com/android/server/wm/WindowStateAnimator.java
b9836b9185132974f6cfa9296bb3c28d1c9b668a 11-Jun-2012 Craig Mautner <cmautner@google.com> Fix exposing wallpaper on rotations and other.

1. Rotations do not go through standard closing of animations so the
wallpaper was not being hidden when the wallpaper target surface was
destroyed. This fix adds hiding the wallpaper when the wallpaper
target is destroyed.

2. The wallpaper target is nulled when switching from launcher home
screen to launcher all apps. In this case the wallpaper remains
visible but below visible layers. It should be hidden so that when
those layers adjust it is not exposed. (Separate fix for adjusting
wallpaper in this case will come).

Fixes bug 6629464.

Change-Id: I522f97dafc0cdcc0f933a825ec9a29d8f63590b5
/frameworks/base/services/java/com/android/server/wm/WindowStateAnimator.java
ff92f04e76cb141caba6bf767618b1c5153242c1 08-Jun-2012 Craig Mautner <cmautner@google.com> Hide wallpaper when wallpaper target gets hidden.

Another location that potentially hides the wallpaper target while
leaving the wallpaper itself still visible. Causes the wallpaper to
show up when upper surfaces are transparent all the way down.

Fixes bug b6621986.

Change-Id: If75053160f041eb78868eda36b7820fb2110d069
/frameworks/base/services/java/com/android/server/wm/WindowStateAnimator.java
ad5725d7985a784056b02b97ab76357a667a6ad4 05-Jun-2012 Craig Mautner <cmautner@google.com> Eliminate wallpaper exposure during transition.

Make sure that the wallpaper target exists and is visible before
exposing the wallpaper.

Fixes bug 6570335.

Change-Id: I1dddfe26683e84fd813e7bee884ba2bd4bb85272
/frameworks/base/services/java/com/android/server/wm/WindowStateAnimator.java
67e6070fa10bbd313c8ebe0de4e0440b688c569e 24-May-2012 Craig Mautner <cmautner@google.com> Merge "Change method of tracking moving AppWindowTokens." into jb-dev
ef25d7a01910d5547b60c9cc52d4fa4a9e40b6fa 16-May-2012 Craig Mautner <cmautner@google.com> Change method of tracking moving AppWindowTokens.

Stop trying to keep track of the AppTokens that have been moved
to the top and bottom and then try and match the WindowStates when
transitions are goodToGo. Instead rebuild the WindowState order based
on the AppToken order when we are goodToGo.

When moving AppWindowTokens lower in mAppTokens create a new ArrayList
of AppWindowTokens to keep track of the apps in Z order while
animating.

Fixes bug 6481078.

Change-Id: I29b33a507b45752f15feb10a9f4b47a3f5eb9f0e
/frameworks/base/services/java/com/android/server/wm/WindowStateAnimator.java
bf08af3323117e15a65b74e66b7499d31537f9e1 17-May-2012 Craig Mautner <cmautner@google.com> Eliminate deferred surface destruction.

Removing the code that delays a surface destruction when
WindowManager.FLAG_KEEP_SURFACE_WHILE_ANIMATING is set. The lock
screen that continued to animate after destroySurfaceLocked is no
longer used and this code was causing problems.

Also mDrawState was being set to NO_SURFACE in destroySurfaceLocked
even if the surface ended up not being destroyed. Later when it was
reused the false value of mDrawState was messing things up.

The screen lock bug referenced below no longer levaes the user stuck
with a black lockscreen. However it occasionally powers back up in the
launcher screen rather than the lock screen.

Fixes bug 6485955.

Change-Id: I684104c7e7c39c161a5118aa890889fbae92e635
/frameworks/base/services/java/com/android/server/wm/WindowStateAnimator.java
3e52fc25154540faf3c0cb927ff45532cdebdddf 16-May-2012 Dianne Hackborn <hackbod@google.com> Fix some issues with updating the offsets of a window.

- 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
/frameworks/base/services/java/com/android/server/wm/WindowStateAnimator.java
521e0d794d298201716d30c66164f0c60d6a74c0 14-May-2012 Jamie Gennis <jgennis@google.com> WindowManager: unset the wallpaper window crop

This change removes the window crop of the wallpaper when setting its position.

Change-Id: I0f4dc10ea9a724b210f75286580ef391145286df
/frameworks/base/services/java/com/android/server/wm/WindowStateAnimator.java
85afd1b6f871d471fdff1980134676a5f1690525 13-May-2012 Dianne Hackborn <hackbod@google.com> Implement new window cropping.

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
/frameworks/base/services/java/com/android/server/wm/WindowStateAnimator.java
9aa695871c9d5a0a4784dd60f77a44922cfd2498 10-May-2012 Craig Mautner <cmautner@google.com> Fix wallpaper glitch and moving window animation.

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
/frameworks/base/services/java/com/android/server/wm/WindowStateAnimator.java
79b7742cf17c79c529bbcbd1acc2d871a90e8fbc 09-May-2012 Craig Mautner <cmautner@google.com> Merge "Fix wallpaper exposure bugs." into jb-dev
0afddcb7f11ddfcaa5d1f5a5db75fce1b5d40253 09-May-2012 Craig Mautner <cmautner@google.com> Fix wallpaper exposure bugs.

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
/frameworks/base/services/java/com/android/server/wm/WindowStateAnimator.java
3a67f35f5e912b9c1ec44adbdc5531427318b12d 07-May-2012 Craig Mautner <cmautner@google.com> Change DimAnimator to reflect rotations.

Enlarge DimAnimator to cover corners when frozen surface rotates.
Update DimAnimator size following rotation to reflect new dimensions.

Fixes bug 6449788.
Fixes bug 6449035.

Change-Id: I217d7c96af940e6affc395b79dc665d00318b18c
/frameworks/base/services/java/com/android/server/wm/WindowStateAnimator.java
83339b465c3299abc47ced7dffdf470c5b0c0750 02-May-2012 Craig Mautner <cmautner@google.com> Fix Home key causes wrong animation

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
/frameworks/base/services/java/com/android/server/wm/WindowStateAnimator.java
fbf378c736a973b8edaf1fc4c187d11dc0f5e291 24-Apr-2012 Craig Mautner <cmautner@google.com> Various debugging enhancements.

Also moved DummyAnimation into AppWindowAnimator where it belongs.

Change-Id: I7da254a8b99030b898e2ff8d983500d7ce0b2b65
/frameworks/base/services/java/com/android/server/wm/WindowStateAnimator.java
4d7349bb6df5a01ba451aa1abd4c9f6349a57016 20-Apr-2012 Craig Mautner <cmautner@google.com> Remove flicker from transitions.

Change state progressions to handle animation/layout separation.
Also added debug as needed.

Fixes bug 6360835.
Fixes bug 6206366.
Fixes bug 6286371.
Fixes bug 6240494.

Change-Id: I1079756a7e3e35ebb9f711f02d005bde9bf65ef0
/frameworks/base/services/java/com/android/server/wm/WindowStateAnimator.java
de6198ebd7f9ea5b7940d38bf5839dfbc6a192c4 19-Apr-2012 Craig Mautner <cmautner@google.com> Defer the Surface.show until animation phase.

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
/frameworks/base/services/java/com/android/server/wm/WindowStateAnimator.java
9546e457fcfed1da9448d72758642793d9e271bb 18-Apr-2012 Craig Mautner <cmautner@google.com> Delay rendering into Surface until draw completed.

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
/frameworks/base/services/java/com/android/server/wm/WindowStateAnimator.java
a51a9564fd53b661446cd63eea23208656acc678 18-Apr-2012 Craig Mautner <cmautner@google.com> Add call-stack reporting methods into Debug

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
/frameworks/base/services/java/com/android/server/wm/WindowStateAnimator.java
acaf9cca865902e6f1823e771f4234bfda53cfd1 17-Apr-2012 Craig Mautner <cmautner@google.com> Move Surface operations into existing transaction.

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
/frameworks/base/services/java/com/android/server/wm/WindowStateAnimator.java
7d8df3905d294127cc58100912a57c816bfb2502 07-Apr-2012 Craig Mautner <cmautner@google.com> Animate from Choreographer only.

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
/frameworks/base/services/java/com/android/server/wm/WindowStateAnimator.java
7358fbfeb2febb60085067fcacc192f429b06545 13-Apr-2012 Craig Mautner <cmautner@google.com> Minor cleanups.

- 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
/frameworks/base/services/java/com/android/server/wm/WindowStateAnimator.java
1f4e0ccba08e4abb55a38a8b5936dbb244475fb9 10-Apr-2012 Craig Mautner <cmautner@google.com> Fix NPE in setTransparentRegion.

Check for null Surface before using it.

Fixes bug 6312835.

Change-Id: Iaaac2a5d88e81b88e369815e09818c268085e4b7
/frameworks/base/services/java/com/android/server/wm/WindowStateAnimator.java
bec53f7066852c1c5877c51fcd8c55840891d866 05-Apr-2012 Craig Mautner <cmautner@google.com> Animate from local list of WindowStateAnimators.

Stop animate() from using the mWindows maintained by
WindowManagerService. Animating WindowStateAnimators are now drawn from
a HashSet maintained by WindowAnimator and containing just those
WindowStateAnimators that have Surfaces.

When starting a move animation do not place parameters directly into
the WindowStateAnimator, instead pass them through the Handler.

Also removed synchronization points from mWindows/mAppTokens
add/remove.
/frameworks/base/services/java/com/android/server/wm/WindowStateAnimator.java
594316361d38d88b53c85bd5c8d58a92345e8187 04-Apr-2012 Craig Mautner <cmautner@google.com> First separation of animation from AppWindowToken.

New class AppWindowAnimator pulls animation out of AppWindowToken.

Change-Id: Ic1ccb6ec2bf091f1f901fe3c20cbeb242376ae6b
/frameworks/base/services/java/com/android/server/wm/WindowStateAnimator.java
d09cc4ba247e896cc95a57ed7a3247b55b1b68fc 04-Apr-2012 Craig Mautner <cmautner@google.com> Move more items between layout and animate sides.

- Isolate DimAnimator animation from the layout side.
- Isolate mWallpaperForceHidingChanged and mOrientationChangeComplete
from the animation side.
- Eliminate a redundant setting of mOrientationChangeComplete to true.
It was already true at that point.
- Synchronize changes to mWindows and mAppTokens on mAnimator. This is
a nop until we go to multiple threads.
- Synchronize AppWindowToken.freezingScreen on mAnimator.
- Modification to repeat layout debugging including temporary enabling
of spew on layout repeats.

Change-Id: Ic8d82b1c197144aaf6957caa5f71e175288220f2
/frameworks/base/services/java/com/android/server/wm/WindowStateAnimator.java
749a7bb28b2aff7a77a8c7dce01e086c2bd82c6b 02-Apr-2012 Craig Mautner <cmautner@google.com> Refactor to convert four state booleans to int.

Replace four booleans (mDrawPending, mCommitDrawPending, mReadyToShow
and mHasDrawn) with a single int that can take on the four states.

Move mLastHidden from WindowState to WindowStateAnimator.

Change-Id: Ieff319dfa19123bf5a6cdc98e9ab28fd432b8153
/frameworks/base/services/java/com/android/server/wm/WindowStateAnimator.java
48ba1e7f530dab01bd2e733b6466246380720a92 02-Apr-2012 Craig Mautner <cmautner@google.com> Defer a couple of Surface actions for WSAnimator.

Perform the set-transparent-region-hint operation outside of the
WindowManagerService loop. This is to isolate the Surface operation
from the WindowManagerService inner loop.

Similarly, defer the setWallpaperOffset call so it's animation is not
coupled to the WindowManagerService inner loop.

Note that both operations are still being done on the
WindowManagerService thread.

Change-Id: I97f030b2a9b7cffe91c77342a299bfac6e59e9f8
/frameworks/base/services/java/com/android/server/wm/WindowStateAnimator.java
c8bc97e53044cd62c0e023fdc441fd13127d0283 02-Apr-2012 Craig Mautner <cmautner@google.com> Further isolate the Surface from WindowState.

Replace references to mWinAnimator.mSurface with new member
mHasSurface.

Clean up odd looping structures.

Simplify logging.

Change-Id: I9cc52a657044220d7b92528928b11bb18a724aef
/frameworks/base/services/java/com/android/server/wm/WindowStateAnimator.java
a608b882327fbb393bde3854953cd322a6fea675 30-Mar-2012 Craig Mautner <cmautner@google.com> Move variables into animation class.

Moved drawPending and commitDrawPending and associated methods from
WindowState to WindowStateAnimator.

Created mechanism for passing results from WindowAnimator to
WindowManagerService. Initial results passed are mUpdateRotation and
mWallpaperMayChange.

Change-Id: Ib03d28f921580ac9426ea9233bea6eafc9ea964c
/frameworks/base/services/java/com/android/server/wm/WindowStateAnimator.java
d87946ba48b62a6a83fd971ef7c4c419407db836 30-Mar-2012 Craig Mautner <cmautner@google.com> Remove obsolete variable masking valid one.

The mUpdateRotation variable was still in the WindowManagerService
mInnerFields object. This was masking the true mUpdateRotation found in
WindowAnimator.

Fixes Bug 6240025.

Change-Id: I6531002f870f30d22e19ba9af5cac86e1c7b9bcb
/frameworks/base/services/java/com/android/server/wm/WindowStateAnimator.java
c2f9be0b7fe14258e01d73f6bc43dd94c3e711d4 28-Mar-2012 Craig Mautner <cmautner@google.com> Move Surface operations out of WindowState.

Migrated the bulk of Surface operations from WindowState to
WindowStateAnimator. There remain a multitude of cross-referencing
between the two classes and most of the other classes in the wm
package.

Change-Id: I4bfdfb84be31341371f3ef311aca8fc6a4966692
/frameworks/base/services/java/com/android/server/wm/WindowStateAnimator.java
e7ae2505405cf30d9d3140278d5b9a2604d866df 27-Mar-2012 Craig Mautner <cmautner@google.com> Move wallpaper animations int WindowAnimator.

More refactoring. This time wallpaper animations were broken up from
WindowManagerService and the layout piece kept there while the
animation piece was moved into WindwoAnimator.

Also, applyAnimationLocked and applyEnterAnimationLocked were moved
from WindowManagerService to WindowState.

Change-Id: I05935023702ce05fdfdc804342ec14f719cdfea4
/frameworks/base/services/java/com/android/server/wm/WindowStateAnimator.java
a2c77053b8dfa5f06bdd927bdbab4df2d00bb4e2 26-Mar-2012 Craig Mautner <cmautner@google.com> Refactor animation out of WindowState.

Remove the animation stepping from WindowState and move it into a new
class, WindowStateAnimator. Update all references to moved variables
in related files.

Change-Id: I7540d8f897b370c73975f3ffe450140861cb0cd1
/frameworks/base/services/java/com/android/server/wm/WindowStateAnimator.java