7c70647f0fe0bdeff0255c5fa827e206a245330b |
|
06-May-2017 |
Matthew Ng <ngmatthew@google.com> |
Update the app window's thumbnail layer after starting window is removed This fixes the case when bottom app is resuming in portrait mode on a tablet where the thumbnail's title bar appears over the docked app (from the top) only when device slows down (or slow down the animation). This is caused by the StartingWindow removing itself from the display and not updating the thumbnail that is still animating while all the other windows updated their z-ordering. When the apps update their z-order, they lower the dock stack's z-order because the starting window (which was behind the dock stack) is gone. However the thumbnail still has the same z-order meaning that the thumbnail will sit on top of the docked app. So when the starting window disappears, the z-order for the thumbnail will also update to fit behind the docked app. Also simplified the thumbnail layer code. Fixes: 35860227 Bug: 62029108 Test: manual, dock an app in top and bottom, go to recents, slow down device animations by 5-10x, resume any bottom task Change-Id: I79bc92b79e50a7b646b7b6c22802e55e04cc1799
/frameworks/base/services/core/java/com/android/server/wm/AppWindowAnimator.java
|
dc9385aad49bf2ba24c1221a5d4558a1ac69f97a |
|
13-May-2017 |
Jorim Jaggi <jjaggi@google.com> |
Immediately report drawing No need to wait on the next relayout - this can only delay the transition. Makes hot launches a lot more consistent. However, this made it too fast! We then hit a race condition when the app transition was already starting but no other layout was done yet. When another layout was executed we noticed that we need to report resized for the starting window, clearing it's drawn state, which set startingDisplayed=false, which jumped the app window animation to the end. To fix this, make sure not to report another resized immediately after the initial layout, as the client already knows the latest (because it calls relayout at some point before it starts drawing). Also fix "animating" async systrace for better analysis. Test: Open/close size-mismatching task snapshot 100 times, ensure no animation skipped. Test: Look at app transition logs, ensure more consistent. Test: Overall system sanity testing (open a couple of apps/dialogs etc). Bug: 32668632 Change-Id: Id795cd6a84f22e6a619089cb9554fc5033477ad2
/frameworks/base/services/core/java/com/android/server/wm/AppWindowAnimator.java
|
6914f0838e460666e9ec260213e1feb6aa7443dc |
|
21-Mar-2017 |
Robert Carr <racarr@google.com> |
Fix various flashes when moving stacks. In this CL we fix two new pinned stack reparenting flashes and implement a new approach to an old docked stack flash fix, which had been broken in refactoring. First we examine the case of dismissing the docked stack and WindowState#notifyMovedInStack. Previously we invoked this when reparenting from the docked to the fullscreen stack (by way of position in stack). It was used to solve an issue where we were visually hidden by the docked stack crop, but we were still waiting on an animation pass to set the hidden flag. Our old solution was if mJustMovedInStack was set, we would just defer updating our crop until one animation pass had occurred. We broke this incidentally in refactoring by not calling the method that sets it anymore. However it's somewhat brittle so I was hesitant to restore it. The fundamental requirement is for the ActivityManager to perform multiple operations (change stack, update visibility) in a single atomic step and this wasn't expressed clearly. This mirrors some challenges we have with the pinned stack transitions as well. 1. When dismissing the pinned stack, we move the task to the fullscreen stack. We need a mechanism to prevent its bounds from updating before its visibility is updated. 2. When moving to fullscreen while over home, we have layering issues with the home stack, as we will be moved to the fullscreen stack before the fullscreen stack is brought to the front of the home stack. This may not seem like a visibility issue, but if the home activity were simply hidden the layering wouldn't matter! Evidently, all three of these issues can be solved with a batching mechanism from ActivityManager to WindowManager. As all changes are ultimately Surface changes, SurfaceControl.open/closeTransaction provides such a mechanism. The only additional complication is that normally visibility updates on SurfaceControl are deferred to the animation thread, which may not execute within the bounds of our transaction. This however, is easily dealt with: In AppWindowToken, if we are becoming hidden without animation, then we simply apply this change without waiting for the UI thread Bug: 35396882 Bug: 34857388 Bug: 36393204 Bug: 36462635 Test: Intensive manual testing of dismissing docked and pinned stack + pinned->fullscreen transition. Change-Id: Ic110797670cc7ff656a580fd186d4deb44fa54dd
/frameworks/base/services/core/java/com/android/server/wm/AppWindowAnimator.java
|
dee1b3f80c363fa6d3c9e87acd729161bce56c23 |
|
27-Feb-2017 |
Robert Carr <racarr@google.com> |
Only adjust window layers from WindowLayerController Various animation adjustment logic will directly set mAnimLayer outside of WindowLayerController. If we end up setting this layer very high, we can end up moving it above the special windows collected in WindowLayersController. Bug: 33702491 Bug: 35396882 Test: bit FrameworksServicesTests:com.android.server.wm.WindowTokenTests Change-Id: I9850529ecd6f0067bc24421515b39b645885a3ec
/frameworks/base/services/core/java/com/android/server/wm/AppWindowAnimator.java
|
6213caa42d89cc446de4f8f9ba00630f166f23cc |
|
02-Dec-2016 |
Wale Ogunwale <ogunwale@google.com> |
Revert "Revert "WindowList be gone!"" This reverts commit ffa5a9de0c127cb77ddec625fea101ddddb7ad32. Bug: 33098800 Bug: 33098294 Test: Existing tests pass. Change-Id: I5803a010c5a224dd1cf452a4a7beb3a4c0a043f4
/frameworks/base/services/core/java/com/android/server/wm/AppWindowAnimator.java
|
ffa5a9de0c127cb77ddec625fea101ddddb7ad32 |
|
23-Nov-2016 |
Jorim Jaggi <jjaggi@google.com> |
Revert "WindowList be gone!" This reverts commit 4551c8bbee4114fa884938dbe90ac0d06ca78fc5. Reason for revert: Broke a lot of things! Bug: 33098800 Bug: 33098294 Change-Id: I307b1c7ee39445d6155a4bbce2bf5f289de55285
/frameworks/base/services/core/java/com/android/server/wm/AppWindowAnimator.java
|
4551c8bbee4114fa884938dbe90ac0d06ca78fc5 |
|
10-Nov-2016 |
Wale Ogunwale <ogunwale@google.com> |
WindowList be gone! The use of DisplayContent.mWindow list to track all windows is no longer needed as we can now get windows through the window container hierarchy with methods like forAllWindows. The window list was also a very complicated logic to understand and maintain, so it won't be missed :) Bug: 30060889 Test: Existing tests pass Change-Id: I590cb33aa0f42bcd4a26ddce102f05e657f54144
/frameworks/base/services/core/java/com/android/server/wm/AppWindowAnimator.java
|
fe762344f4475a3a336bb46aef2d59c1fabf32ab |
|
13-Oct-2016 |
Jorim Jaggi <jjaggi@google.com> |
The big keyguard transition refactor (1/n) The heart of this change are two things: 1) Instead of using the force hide mechanism to hide windows behind Keyguard, we actually make the activities invisible in activity manager. 2) When Keyguard is going away, we change the visibilities in activity manager and run an app transition. At the very core we move the responsibility of hiding activities to ActivityStack, which checks whether Keyguard is showing, and then hides all non-show-when-locked activities. For that, we need to check whether any window of an activity has SHOW_WHEN_LOCKED set. We introduce a callback from WM -> AM in case these Keyguard flags have changed. Furthermore, we decide whether to occlude Keyguard in KeyguardController, which just checks whether the top activity has SHOW_WHEN_LOCKED set. When this state changes, we prepare an occlude/unocclude app transition, and in PWM we just inform the Keyguard about the animation so SysUI can play along this animations in a mostly synchronized manner. Since we now use an app transition when unlocking the phone, we get lockscreen launch animations for free - window manager automatically waits until the activity is drawn, or directly executes the transition if there is nothing to animate. Thus, we can remove all the infrastructure around "waitingForActivityDrawn". The logic to show/hide non-app windows is moved to policy, and we add the ability to run animations on non-app windows when executing an app transition. Test: 1) runtest frameworks-services -c com.android.server.wm.AppTransitionTests 2) Manually test unlocking Keyguard: 2a) Without security 2b) With security 2c) With security but trusted 2d) Portrait while activity behind is in landscape 3) Test launching things from Keyguard 3a) Without security 3b) With security 3c) Launch camera without security 3d) Launch camera with security 3e) Launch camera with securtiy and trusted 3f) Launch voice affordance 4) Set no notifications on lockscreen, drag down, make sure you get the correct animation 5) Test clicking "emergency" on bouncer 5b) Test "Emergency info" on emergency dialer 5c) Test clicking edit button on emergency info, should show pattern on Keyguard Bug: 32057734 Change-Id: Icada03cca74d6a612c1f988845f4d4f601087558
/frameworks/base/services/core/java/com/android/server/wm/AppWindowAnimator.java
|
ae9adbfb758712caaf11b4ba5c5fd15848dcc3c5 |
|
19-Oct-2016 |
Wale Ogunwale <ogunwale@google.com> |
Removed WindowState.getWindowList() 2nd step in trying to make the WindowList private to DisplayContent. WindowState.getWindowList() was an indirect way to the the window list from the display content. Test: Manual testing and existing tests pass. Change-Id: I634ed446661371e70b99c701c23e1bdd59ada0bc
/frameworks/base/services/core/java/com/android/server/wm/AppWindowAnimator.java
|
b0f3b836b9fe98d395fdbadf2cdd3603f4e0145a |
|
17-Oct-2016 |
Wale Ogunwale <ogunwale@google.com> |
Clean up use of DisplayContent from WindowState. Follow up to ag/1483993 where WindowTokens can now only be on one display. Clean-up some existing code that dealt with having WindowTokens on multiple displays. Test: Existing tests pass. Change-Id: Ie908eda37bc44097dea773b0fc163d35cc9baf35
/frameworks/base/services/core/java/com/android/server/wm/AppWindowAnimator.java
|
5136249a7147fb205e1b861c1d42a7d1f13b73cc |
|
09-Sep-2016 |
Wale Ogunwale <ogunwale@google.com> |
Support for specifying orientation in WindowContainer Also, - Fixed failing tests when they are ran as a package vs. individual classes due to multiple window manager instance. - Correct some isVisible logic to so a window container that is invisible is not said to be visible, because one of its children is visible. Bug: 30060889 Change-Id: I1bb8730361be2a9f5ce88cd59b7d57d5a459bde6
/frameworks/base/services/core/java/com/android/server/wm/AppWindowAnimator.java
|
15ead903c69b043eeb44fc627929d4919e985df3 |
|
02-Sep-2016 |
Wale Ogunwale <ogunwale@google.com> |
Some code clean-up in WindowManager. - Renamed DisplayContent.findTaskForControlPoint to DisplayContent.findTaskForResizePoint as it is trying to find a task from the resize point. - Renamed DisplayContent.checkForDeferredActions to DisplayContent.onCompleteDeferredRemoval as the method removes containers whose removal were deferred. - Added methods TaskStack.hasMultipleTaskWithHomeTaskNotTop() and topTaskIsOnTopLauncher() - And some other minor clean-up relating to me trying to break-up a big CL. Change-Id: I64d03cbd9ee69bf8fa0013a49283cd434b7c8fbe
/frameworks/base/services/core/java/com/android/server/wm/AppWindowAnimator.java
|
44f2180c554684d8ce015116ad057dca06bba87d |
|
02-Sep-2016 |
Wale Ogunwale <ogunwale@google.com> |
Introduced WindowContainer.hasContentToDisplay We have lots of "is visible" methods and this change is an attempt to rename one of the methods to match closer to what is actually does and differentiate it from other "is visible" methods. WC.hasContentToDisplay() returns true if the container or one of its children as some content it can display or wants to display (e.g. app views or saved surface). WC.isVisible() returns true if the container or one of its children is considered visible from the WindowManager perspective which usually means valid surface and some other internal state are true. Bug: 30060889 Change-Id: Ifbd6c277eb65a53b8035b6f34fc45196962632c1
/frameworks/base/services/core/java/com/android/server/wm/AppWindowAnimator.java
|
2049dbf0e9f658c1f5234fb0a1f0af6942b7eb58 |
|
03-Aug-2016 |
Wale Ogunwale <ogunwale@google.com> |
Replaced use of WT.appWindowToken with WT.asAppWindowToken Not a perfect implementation, but slightly less confusing as the child class is no longer a member variable of the parent class. Also renamed WindowToken.service to WindowToken.mService to be consistent with how we name in other places. Bug: 30060889 Change-Id: Ib21472a784a4f24e7789d443876cf0912d9e89de
/frameworks/base/services/core/java/com/android/server/wm/AppWindowAnimator.java
|
9f25beee3a8cd6f452534006ea9068178cbb4ce1 |
|
02-Aug-2016 |
Wale Ogunwale <ogunwale@google.com> |
Made AppWindowToken.allAppWindows private Pre-clean-up before switching class to using WindowContainer. Bug: 30060889 Change-Id: Ic3d47d47b922668eeb70988ce883267b46ca9d72
/frameworks/base/services/core/java/com/android/server/wm/AppWindowAnimator.java
|
adde52ee32b656bb436f7e92f39f7d0d97cc9306 |
|
16-Jul-2016 |
Wale Ogunwale <ogunwale@google.com> |
Made WindowState.mChildWindow private scoped This involved: - Moving method that operated on mChildWindows and mostly touched WindowState fields into WindowState class. - Creating new methods for getting information about child windows outside WindowState class instead of accessing the child list directly. - And, tests ;) Bug: 30060889 Change-Id: I339cecb926b44b5db7ead1970e356304d5429c8f
/frameworks/base/services/core/java/com/android/server/wm/AppWindowAnimator.java
|
9d14790d299d1e2b96db287601c86f82850019c9 |
|
16-Jul-2016 |
Wale Ogunwale <ogunwale@google.com> |
Track hidden state of window in itself vs. all child windows. It makes the code easier to follow if the hidden state of a window is tracked in itself vs. all chils windows. Child windows can call WS.isParentWindowHidden to get the hidden state of their parent window. Also, moved the performShowLocked method from WindowStateAnimator to WindowState since most of the fields modified in the method belong to WindowState. And, don't forget the test for the change ;) Bug: 30060889 Change-Id: I5be13b936a2284fd8fe10218b80fe41cc197d1a7
/frameworks/base/services/core/java/com/android/server/wm/AppWindowAnimator.java
|
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
|