| 9214704eac0af4b0d138a195bcea6fecef523ea5 |
|
09-May-2016 |
Chong Zhang <chz@google.com> |
Fixes for restoring more than one child surfaces
App may have more than one windows and subwindows. Remember which ones
are visible at the last setAppVisibility time, and restore only those
that was visible then. If the app itself requested to hide a window
before that, we don't want to use the window for early animation.
Also move mAnimatingWithSavedSurface into WindowState as it needs to
be tracked per window.
bug: 27455025
bug: 28296945
Change-Id: I3ed1879634fa7709de699d4518d8fcfc91a85554
/frameworks/base/services/core/java/com/android/server/wm/AppWindowAnimator.java
|
| 8e0626572d44413e77ab73bd859b9d76c16c0d6b |
|
30-Apr-2016 |
Chong Zhang <chz@google.com> |
Fix a transparent flicker due to wrong crop
When transfering an animation, copy over app animator transformation
in addition to the animation object itself.
bug: 28399102
Change-Id: I8694a76993476b19ec61d74680d6fc51326a18bf
/frameworks/base/services/core/java/com/android/server/wm/AppWindowAnimator.java
|
| 5c80c41ee0ef808e7c8234087c5538531a16f5bb |
|
20-Apr-2016 |
Jorim Jaggi <jjaggi@google.com> |
Final fixes for growing recents transition
- Make sure to reposition windows during animations to avoid that
they lag one frame behind.
- Don't put windows that are gone for layout into resizing mode.
- Don't layout windows that are gone for layout, to avoid resizing
the surface but the client won't draw anymore.
Change-Id: I809feffef00f9a086b44504126e03f509eb7f190
Fixes: 27855229
/frameworks/base/services/core/java/com/android/server/wm/AppWindowAnimator.java
|
| 8448f339f9207aa1e554b1a1e537ce269462807a |
|
14-Mar-2016 |
Jorim Jaggi <jjaggi@google.com> |
Implement transition for docking task in recents #4
Convert aspect scaled animations from using scaling to achieve
the translation to use translation animations directly. We set
the pivot point to the middle of the thumbnail and then manually
translate the surface.
This will allow us to use curved motion in transition when docking
a task from recents.
Bug: 27607141
Change-Id: I5ef3bf2352baace2a3829097d2d7da8f04857ec6
/frameworks/base/services/core/java/com/android/server/wm/AppWindowAnimator.java
|
| de63d441d7daf0503bcc6d5fd3f4f7efe06e23d3 |
|
14-Mar-2016 |
Jorim Jaggi <jjaggi@google.com> |
Implement transition for docking task in recents #3
- Implement clipping for thumbnail.
Bug: 27607141
Change-Id: Ic3ba0acf685341ad715fae1601fad5eba1a93e44
/frameworks/base/services/core/java/com/android/server/wm/AppWindowAnimator.java
|
| 6a7c90a12b5e5250e0350d35ca6547b26630653f |
|
11-Mar-2016 |
Jorim Jaggi <jjaggi@google.com> |
Implement clip modes during animation
Introduce modes how surfaces are clipped to the stack bounds
during transitions.
Use setFinalCrop to implement STACK_CLIP_AFTER_ANIM.
Add logic to determine which stack clip mode to use.
Bug: 26559810
Change-Id: I8edc47de3aaf1ef12055cefd8ceb8df536c5109a
/frameworks/base/services/core/java/com/android/server/wm/AppWindowAnimator.java
|
| 65d15d03326456457039dde69ae37e9ae1db6d6e |
|
14-Mar-2016 |
Chong Zhang <chz@google.com> |
Fixing misc issues that leads to black screen when pressing Home
- Make sure to clear usingTransferredAnimation flag together when
setting app animator's animation to null. Not clearing it will cause
setAppVisibility to not apply dummy animation (placeholder)
to a closing app token while it should, and the closing app token will
then exit early before the opening app is ready, since it doesn't have
any animation set. This causes a brief blank period.
- When app relayout to invisible, make sure to mark mWinAnimator's
mAnimating to true if we decided exit animation is running. Note that
even if we didn't actually apply the animation (which could happen if
the window is no longer visible by policy), if the app token itself is
under any animation, we need to mark mAnimating otherwise the clean up
code in FinishExit will not run, and the window will be stuck in
Exiting state.
- We no longer change mAnimatingExit flag in setAppVisibility(), but
wait for app's relayoutWindow calls to change it if applicable.
setAppVisibilty doesn't apply the animation until transition is good
to go. Setting the flag without the animation applied will disable
setTokenVisibilityLocked and relayoutWindow to actually apply the
animation, because they may think the window is no longer visible.
bug: 27391256
Change-Id: I292305847d742cdbb5ebe6aa8daa5d83bf65483b
/frameworks/base/services/core/java/com/android/server/wm/AppWindowAnimator.java
|
| 3dac63a18d9115405404561d327010604420b07b |
|
01-Mar-2016 |
Jorim Jaggi <jjaggi@google.com> |
Don't destroy thumbnails immediately
The hiding of the thumbnails needs to be synchronized with the hiding
of the app window. Because destroying them immediately destroys them
without being part of the transaction, that can happen earlier than
hiding the surface.
Instead, hide the thumbnail in the transaction first and then put it
into a list to be cleared after the transaction is closed.
Bug: 27275815
Change-Id: I1530262c26c0751e53d218b686c46129f7c7df1d
/frameworks/base/services/core/java/com/android/server/wm/AppWindowAnimator.java
|
| 5e6968db630d26872306c4b23aa2c600d83ed454 |
|
20-Feb-2016 |
Jorim Jaggi <jjaggi@google.com> |
Fix disappearing windows after moving divider to side
Because we only hide the surface when the clip rect got empty
but never showed it again if it got non-empty, app windows
disappeared after moving the docked stack divider to the
edge of the screen. Now we reshow the surfaces if the clip-rect
gets non-empty.
However, this introduces another bug while dismissing the docked
stack: Because we move all windows to the fullscreen stack, we resize
them but until the app transition starts, it can take a while and
during this time the app surface would be visible with the wrong
bounds. To fix this, we notify the windows that we are repositioning
ourselves in our stack. When applying the clip-rect, we detect that
situation and then we set the clip rect to empty if it was just empty
before and we just moved in the stack, to fix this very specific
issue.
I'm really not proud of this solution but at this point we can't
revisit how app transitions are executed in terms of timing and
ordering, so I thought this little hack is the best solution at
this point.
Bug: 26588506
Change-Id: I78305f7f7ef6c3da3c126a58d751117fcee23ca9
/frameworks/base/services/core/java/com/android/server/wm/AppWindowAnimator.java
|
| bfc2f8f6c8ac4156e76a50c88a9ac36d864cee36 |
|
30-Jan-2016 |
Chong Zhang <chz@google.com> |
Some fixes for saved surfaces
- If we have a saved surface, and app relayouts to visible before we
started entry animation, we need to restore the saved surfaces.
Otherwise the surface might get stuck in the saved state, because
we may not get to run any animation after this relayout.
- Keep track of the allDrawn while we're using the saved surfaces,
so that we can rely on allDrawn itself, instead of whether we're
using saved surfaces.
- If the app is set to visible when it's exiting, clear the exiting
flags. Also, save the surface if we cancel an exiting animation.
- More debug logging.
bug: 26819496
Change-Id: Ie42c6eea7879632d82f24ed09c3b6e737dd6d8a4
/frameworks/base/services/core/java/com/android/server/wm/AppWindowAnimator.java
|
| 198dcbf5231761b7b644d9d7fbceb23e1f0f9aec |
|
18-Jan-2016 |
Filip Gruszczynski <gruszczy@google.com> |
Fix several small logging issues.
This includes:
1) invert HIDE_STACK_CRAWLS to SHOW_STACK_CRAWLS so it's immediately
clear from the config file that something is enabled (if anything is
true).
2) Merge stack collection code into a method, so we can remove the
repeated code.
3) Remove copying of some constants in AppTransition and just import
them directly.
Change-Id: I3190ee0a5963720ac6285b4f48b2705e84f04ab5
/frameworks/base/services/core/java/com/android/server/wm/AppWindowAnimator.java
|
| 92e432c30e2304272c2f5b1b33366f32c3d763cf |
|
16-Dec-2015 |
Filip Gruszczynski <gruszczy@google.com> |
Refactor and improve window layering.
This CL moves layer calculation into a separate class, so the whole
logic can be encapsulated. It also extracts special cases from the
general loop and instead applies them at the end. This simplifies the
logic in the main algorithm and makes it clearer what needs to happen
for special cases.
Bug: 26144888
Change-Id: I87347bf0198bd0d3cd09e4231b4652ab979f2456
/frameworks/base/services/core/java/com/android/server/wm/AppWindowAnimator.java
|
| 0bd180d8880b3d1b9677f154c034a2af840b4796 |
|
08-Dec-2015 |
Filip Gruszczynski <gruszczy@google.com> |
Improve debugging setup for window manager package.
This moves debug flags to a dedicated class and also provides a
mechanism to either have fine grained tags or one common tag for easier
grepping the logcat. This mimicks the approach in activity manager
package.
Change-Id: Ie8c08b9a3d8b182335ee5547ee05d21b5933db6b
/frameworks/base/services/core/java/com/android/server/wm/AppWindowAnimator.java
|
| a590c99256b197d52a0869d89f8def34796a985d |
|
26-Nov-2015 |
Filip Gruszczynski <gruszczy@google.com> |
Remove unnecessary field from AppWindowToken.
Change-Id: I0bc488dc67d5128a1f47f58f62038d178d8ef0cd
/frameworks/base/services/core/java/com/android/server/wm/AppWindowAnimator.java
|
| 564a8f697b3f3a287d9a4cce14ac0fe1a046709e |
|
20-Nov-2015 |
Filip Gruszczynski <gruszczy@google.com> |
Synchronize thumbnail header in recents to freeform animation.
Bug: 24913782
Change-Id: I46792ea3135794e514894783e1ee5fa696576f7f
/frameworks/base/services/core/java/com/android/server/wm/AppWindowAnimator.java
|
| 1a4dfe593aafda057ac9cb3086b84588d88cd09f |
|
15-Nov-2015 |
Filip Gruszczynski <gruszczy@google.com> |
Synchronize recents to freeform transition.
Recents to freeform animation must hang on the first frame and inform
Recents to hide its views. This mirrors the transition from freeform
to Recents, where the animation needs to hang on the last frame.
We need a special window flag for recents to force a redraw after the
animation launches. At this point Recents will become not visible
from the perspective of the activity manager, which would prevent
further drawing. We make recents ignore that and instead depend on
window visibility which will change after recents exit animation
finishes.
Bug: 24913782
Change-Id: Ief743b7e6fcebb3d8789d4745fb122ac607c1cf0
/frameworks/base/services/core/java/com/android/server/wm/AppWindowAnimator.java
|
| 14b4e57c1ba427f07186dbff8491242162028c71 |
|
04-Nov-2015 |
Filip Gruszczynski <gruszczy@google.com> |
Remove blink during the freeform -> recents transition.
We achieve the desired result by prolonging the last frame of the
animation until recents tells that it drew its content. The CL also
includes cleanup that moves code that depends heavily on WindowState
fields into that class.
Bug: 24913782
Change-Id: I5ee5b18504dd4a86c24033d17eca21cd31936bca
/frameworks/base/services/core/java/com/android/server/wm/AppWindowAnimator.java
|
| db20b5f7a1fdb847f2266df0fbae6046dc95c757 |
|
23-Oct-2015 |
Chong Zhang <chz@google.com> |
Use saved window surface to start entering animation
When app is paused, keep the window surface around. Use it to start
enter animation if size remains unchanged on next launch.
bug: 19940527
Change-Id: Icf88d81f08b59e8bd946e410611f5098b253eb10
/frameworks/base/services/core/java/com/android/server/wm/AppWindowAnimator.java
|
| 974eb3dd60cc5c5a79a400782dee86c94dd87ee9 |
|
24-Oct-2015 |
Filip Gruszczynski <gruszczy@google.com> |
Run AppWindowAnimator.showAllWindowsLocked in a transaction.
Change-Id: I39dcecc79b272672ae5287e3c3c408fdfed6f616
/frameworks/base/services/core/java/com/android/server/wm/AppWindowAnimator.java
|
| e8069dcfcff15e060fc397b9ed5ea8b915b1cfa7 |
|
18-Aug-2015 |
Wale Ogunwale <ogunwale@google.com> |
Moved window manager wallpaper control into separate class
Change-Id: Ia3c12065678992614667dc210d4611a1250ca22b
/frameworks/base/services/core/java/com/android/server/wm/AppWindowAnimator.java
|
| c554b77b7392b97e0f455d8276b739e16147d6df |
|
05-Jun-2015 |
Jorim Jaggi <jjaggi@google.com> |
Skip first frame for app transitions when possible
In most of our standard app transitions, the first frame of a
transition results in the same contents on the screen. This is
inefficient, as we can directly skip to the second frame of the
transition, introduce no jank, but execute the transition 16ms
faster.
Change-Id: If58337eae5558eae3acced691ae01c769f0ec2b9
/frameworks/base/services/core/java/com/android/server/wm/AppWindowAnimator.java
|
| a48eadbeb6fa34f27d6db7de51d3c01972ea2ebf |
|
15-May-2015 |
Wale Ogunwale <ogunwale@google.com> |
Send AppTransitionFinish notification when there was no animation
Activity#onEnterAnimationComplete() is the hook that we advise app
developers to use to know when they are allowed to start drawing
(so they don't collide with the window transition animation).
However, it's not invoked if the window transition has no animation
(e.g. by calling Activity#overridePendingTransition(0,0).
Bug: 20823935
Change-Id: I5b286968b0cd3351e9a9224294d0a1e7faf8c654
/frameworks/base/services/core/java/com/android/server/wm/AppWindowAnimator.java
|
| 8a2978c9ab5edd97e1de97fdc2ac6c6e2f7bb02b |
|
14-May-2015 |
Wale Ogunwale <ogunwale@google.com> |
Merge "Don't stop animation when starting windows app token changes" into mnc-dev
|
| 8ebc82a63f7e4818bb615cf980b961757c8d6587 |
|
14-May-2015 |
Wale Ogunwale <ogunwale@google.com> |
Don't stop animation when starting windows app token changes
If another activity is starting while we are still animating
the starting window of the previous activity to start, we
transfer the starting window of the old activity to the one that
is currently starting so we don't have to create another starting
window and also to reduce jank from the starting window animation
appearing to restart.
However, there were several conditions that led to the starting
window animation stopping when the transfers app tokens
1. Starting window animator not been removed from the previous
app token animator causing it to finish/remove the starting window
prematurily.
2. Starting window animator not been properly added to the new
app token animator causing the animation not be be picked up.
3. WMS.mSkipAppTransitionAnimation been set to false regardless of if
an app transition was actually prepared in WMS.prepareAppTransition()
4. WMS.mSkipAppTransitionAnimation not been set to true in all cases
where the starting window transfers tokens even though we don't want the
new app to do any transition animation is the starting window is
animating.
5. New app not setting its animation to dummy animation when the next
transition should be skipped due to starting window still animating.
6. Starting window animation been cleared for the new app in
WMS.handleAppTransitionReadyLocked() even for cases where we transferred
the animation from the previous app.
Also, cleaned up some code.
Bug: 20953232
Change-Id: I714d6bdfcdaeeaac29f9d464bab9f3e9c192e937
/frameworks/base/services/core/java/com/android/server/wm/AppWindowAnimator.java
|
| 827e0facfefd0c0033dcfb1747b4fa6f80f9e0e2 |
|
07-May-2015 |
Jorim Jaggi <jjaggi@google.com> |
Make sure the app can draw a frame before unlocking
- The mechanism to stop windows drawing while window animator was
animating was somehow flaky. It relied on the fact that the client
would call relayout() whenever the animating state changed. This is
mostly the case, but not for lockscreen animations. Instead, we now
use a push model, where window manager tells the app that the state
has changed.
- In addition, it only stopped drawing if that window was animating,
but then only resumed drawing after all windows have finished
animating. Now, we do this per window, so we only stop drawing for
windows that are currently animating.
- We resume the top activity now at the very beginning of the
unlocking sequence. This gives the app a chance to draw a frame
before the user sees anything. If it's to slow, then we just use the
outdated framebuffer.
Bug: 19964562
Change-Id: Ifef8abd189a3146d854b81b9b948861e4d38c155
/frameworks/base/services/core/java/com/android/server/wm/AppWindowAnimator.java
|
| f16a281066ed7b524676698f95642c0a550b0b62 |
|
01-Apr-2015 |
Wale Ogunwale <ogunwale@google.com> |
Fixed NPE when trying to animate a windows whose display is gone.
In some cases it is possible for the AppToken.allAppWindows list to
get out of sync with the list of windows known to WMS if the client
doesn't call Session.remove(Window). This can lead to an NPE when
the animation threads runs and the display for the window has been
removed.
Also corrected some method names/scopes I ran across while debugging.
Bug: 19972099
Change-Id: Ib0ae7ede6c506f833bbdd66723b88e7504a61907
/frameworks/base/services/core/java/com/android/server/wm/AppWindowAnimator.java
|
| 378756154fce86b53e91746583bfe15996ef680b |
|
19-Feb-2015 |
Jorim Jaggi <jjaggi@google.com> |
Stop app transition based on mAppWindowAnimating field
Bug: 19440051
Change-Id: Ic385eab15cca8c5b814dc9cdbfd2d2f79fd84b02
/frameworks/base/services/core/java/com/android/server/wm/AppWindowAnimator.java
|
| 77ba4803a510717032181e7cf0beca9d07f09733 |
|
18-Feb-2015 |
Jorim Jaggi <jjaggi@google.com> |
Add AppTransitionListener
Introduces the concept of a listener to be notified about app
transition events. The only client at the moment is window manager
which notifies activity manager about completed transitions, but this
can be used for various clients, including the status bar.
Bug: 19233606
Change-Id: Ia6fec5837b6eb4db90f3cb1c999d3f157ba6dd4a
/frameworks/base/services/core/java/com/android/server/wm/AppWindowAnimator.java
|
| ec533f6a55cfe3b3fdc43f2cdd2305d952a2437b |
|
05-Dec-2014 |
Wale Ogunwale <ogunwale@google.com> |
Don't destroy surfaces of activities launched behind early.
When the launch activity behind feature was introduced in
http://ag/502868, we destroy the surfaces of windows associated with
the activity early in the last app window animation step. The causes
issues with activities that might be using the surface and not
prepared to have the surface destroyed from underneath them. We now
let the surface destruction get handled like any other window so all
the components/processes interested in the surface can be in the
right state when the surface is destroyed.
Bug: 18325222
Change-Id: I45e834a07a199b8a9e364f7392db99c871a43280
/frameworks/base/services/core/java/com/android/server/wm/AppWindowAnimator.java
|
| ab79fce2e71b6816b2b88b826ca723b3591f1e26 |
|
05-Nov-2014 |
Winson Chung <winsonc@google.com> |
Fixing crash in recents window transition. (Bug 18246975, 18159006)
The recents transition requires synchronizing the thumbnail header (the bar
that animates on top of the window that is being scaled/cropped) and the
application window. This change simplifies the code and removes the notion
of having another animator manage the same surface, and instead ensures that
the thumbnail animation has the same duration and that the thumbnail animation
is deferred and cleaned up one frame after the app transition is complete.
Change-Id: If8f348afccf59327187e8498eb451ba066600a41
/frameworks/base/services/core/java/com/android/server/wm/AppWindowAnimator.java
|
| 1ad99155b37c0cb0b7d95f084a2bff0cbfc8e12d |
|
29-Aug-2014 |
Craig Mautner <cmautner@google.com> |
Don't use anim background for translucent windows
When a translucent window transitions in or out the activity behind
it does not animate. In such cases if a background color is specified
for the translucent window animation then the background will obscure
the static window behind the animating window for the duration of the
animation. This change eliminates the background color for
translucent windows.
Fixes bug 16219830.
Change-Id: I5834595afa5beae95ac2fcf8f2bad1a59271e08a
/frameworks/base/services/core/java/com/android/server/wm/AppWindowAnimator.java
|
| a4ccb86ddc8f9f486aee25fb836f4aff97bf7679 |
|
23-Aug-2014 |
Winson Chung <winsonc@google.com> |
Multiple performance changes to speed recents invocation/app launching time. (Bug 16987565)
- Reverting changes to the existing thumbnail transition to prevent breaking applications
that currently depend on that transition. As a result, we need to create a new, hidden,
aspect-scaled thumbnail transition, and instead use that thumbnail to animate the
recents header so that we don't have to wait to do that inside the Recents activity.
In order for this to work, we also have to ensure that the thumbnail surface destruction
is synchronized with the application that is currently closing (when going down to
recents) or opening (when coming back up). The current thumbnail is destroyed when the
animation ends, but that can be at least 1 frame before the surface for the animating
window is destroyed. We change this by deferring destruction of this thumbnail window
to the animation that is being closed.
Especially on the way up, not having to wait for us to hide the header before doing the
transition up can save us the duration of that first animation (> 100ms).
- Other optimizations:
* No longer creating a new stack view on each transition to calculate the target rect
* Removing unnecessary call to get the thumbnail when transitioning up/down (the actual
window does its own animation.
* We reduced numerous system calls per task by adding a flag to ignore home-stack tasks
and caching the activity label and icon (and task description icon). These caches
follow the same eviction schemes as the thumbnail and icon cache.
- Also tweaked the touch slop for the nav bar swiping gesture to prevent conflicting with
tapping on home (Bug 17109581)
Change-Id: Ica697aad788051a9203edd9351c583e1cb038a71
/frameworks/base/services/core/java/com/android/server/wm/AppWindowAnimator.java
|
| 76a1623afc170a13923b68f3256057d8adeb7937 |
|
08-Aug-2014 |
Jorim Jaggi <jjaggi@google.com> |
Preparations for lockscreen launch animations
- Update unlock animations to new spec to make the consistent with
lockscreen launch animations.
- Introduce disappearing motion for security views which runs before
we actually dismiss Keyguard.
- If a window is running the un-force-hide animation, treat as it
would have the wallpaper flag set so the wallpaper stays until
the animation is completely done.
- Run an animation on the wallpaper if the wallpaper is going away.
Bug: 15991916
Bug: 16234603
Bug: 15326120
Change-Id: I063aa4f269ddcf75b9a705e90f0c3056b541b642
/frameworks/base/services/core/java/com/android/server/wm/AppWindowAnimator.java
|
| 8746a478abcfb3b0d73b156232051af1e8d21ce2 |
|
25-Jul-2014 |
Craig Mautner <cmautner@google.com> |
Create end of animation callback for Activity
Activities cannot draw while their entering animations are active.
This change introduces a callback, onEnterAnimationComplete() so
that activities can know when their draws will be effective.
Fixes bug 13658460.
Change-Id: Ic48540cd4c7e37538f10cb2dc0852aa3f55d11e1
/frameworks/base/services/core/java/com/android/server/wm/AppWindowAnimator.java
|
| bb742462781a73bb25516067c8fe6311c1c8a93e |
|
08-Jul-2014 |
Craig Mautner <cmautner@google.com> |
Launch activity behind launching task.
Use ActivityOptions.makeLaunchTaskBehindAnimation() to launch tasks
behind the current task. Includes animations for launching and
launched tasks.
Fixes bug 16157517.
Change-Id: I0a94af70b4748592e94673b958ee824cfb3d7ec0
/frameworks/base/services/core/java/com/android/server/wm/AppWindowAnimator.java
|
| eb94fa7975b1e8742f3b00cec6bd4f9d6b329e3a |
|
04-Jun-2014 |
Dianne Hackborn <hackbod@google.com> |
Improvements to low power mode.
Add new public API for monitoring low power mode.
BatteryService now puts device in to low power mode when
battery level is low.
Window manager now watches low power mode to turn off
animations.
Modifying the animator scale now gets propagated to all
processes.
Change-Id: I8fa566994764ddd4e1977631e28381ab9409f8ee
/frameworks/base/services/core/java/com/android/server/wm/AppWindowAnimator.java
|
| c2c0a61cf5f779b4726f089f28d966c03ccbba54 |
|
21-Feb-2014 |
Craig Mautner <cmautner@google.com> |
Add copyright notice to files missing them.
Fixes bug 13121968.
Change-Id: Ifd86581178e7e98bd72b832020e7c8379d40b2de
/frameworks/base/services/core/java/com/android/server/wm/AppWindowAnimator.java
|
| 9158825f9c41869689d6b1786d7c7aa8bdd524ce |
|
22-Nov-2013 |
Amith Yamasani <yamasani@google.com> |
Move some system services to separate directories
Refactored the directory structure so that services can be optionally
excluded. This is step 1. Will be followed by another change that makes
it possible to remove services from the build.
Change-Id: Ideacedfd34b5e213217ad3ff4ebb21c4a8e73f85
/frameworks/base/services/core/java/com/android/server/wm/AppWindowAnimator.java
|