91b22809648a33d64c159e8496773b1b3b2ab6ca |
|
29-Jun-2016 |
Robert Carr <racarr@google.com> |
Only use one SurfaceControlWithBackground per AppToken. In the past, if an app never renders to a SurfaceView, it will be invisible despite having FLAG_OPAQUE. This means an app could leave a totally empty SurfaceView (never drawing in to it) on top of a second SurfaceView, and expect the second one to be visible. This is probably buggy app behavior because FLAG_OPAQUE means if they ever draw anything at all in to the top SurfaceView the bottom one will become totally invisible. However this has worked in the past, so we have to preserve things for apps. To accomplish this we ensure only the bottom most visible SurfaceView for a given AppToken will receive a background. We achieve this by synchronizing through the app token whenever visibility or layering of a SurfaceView changes. Bug: 29580298 Change-Id: I0023326323cb961b56404fd49093384e7b72aa54
/frameworks/base/services/core/java/com/android/server/wm/AppWindowToken.java
|
0e8524719559f0be9c8145dbf9f52100e1fb60c3 |
|
15-Jun-2016 |
Yorke Lee <yorkelee@google.com> |
Limit global drags to apps targeting SDK 24 and above Bug: 29127791 Change-Id: Ib5f85a207bdb79eeac0418fda78e452d225761bc
/frameworks/base/services/core/java/com/android/server/wm/AppWindowToken.java
|
f58631a6a265a12a64a5c697178e0f4784f562ac |
|
25-May-2016 |
Chong Zhang <chz@google.com> |
Destroy saved surfaces if one of the last visible windows gets removed Also, if by the time the app is closing, a window is still invisible in layout (or is already removed), mark the window as mAnimatingExit, so that the surface is destroyed (or saved again). If it's marked for removal, the window gets removed as well. bug: 28913302 Change-Id: Ifa3dc0742f9c8c09d741fd64dcdc01b49075628c
/frameworks/base/services/core/java/com/android/server/wm/AppWindowToken.java
|
26c8c42bbb2b998e609983886fad5968f033268d |
|
10-May-2016 |
Jorim Jaggi <jjaggi@google.com> |
Also freeze configuration when freezing bounds We also need to freeze the override configuration so we don't report the new configuration too early, which leads to bugs. Bug: 27915587 Change-Id: Idffadbb02ab0311796caa760ae1f467fd2d17768
/frameworks/base/services/core/java/com/android/server/wm/AppWindowToken.java
|
8e4bda9e0f7411a3bfad0c625177f67248ff8a12 |
|
05-May-2016 |
Chong Zhang <chz@google.com> |
Fix a flicker when window is removed during entering animation When animation is started with saved surfaces, app may decide to remove one of the child windows during early animation and replace it with a new window. This causes the app below (usually Recents) to show through for one or more frames. If we started animation early with a window, delay removal of that window until the app is allDrawn in the "traditional sense" (i.e. allDrawn without using any saved surfaces). bug: 28742353 Change-Id: I4ef663a947b737aae96c3ccfe13a9f4c1d0567f0
/frameworks/base/services/core/java/com/android/server/wm/AppWindowToken.java
|
32de365bd82a748cc366aee50d281faca9d44815 |
|
13-May-2016 |
Chong Zhang <chz@google.com> |
Fix replacing window timeouts Do not post app token with the timeout message, instead put the token in a list and post empty message only. bug: 28744782 Change-Id: If809d8ee16bcc31067f25ae5696b62d09ea4b864
/frameworks/base/services/core/java/com/android/server/wm/AppWindowToken.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/AppWindowToken.java
|
eb66557eeb923cf33a4c2e133776ab8cbc9aa571 |
|
10-May-2016 |
Chong Zhang <chz@google.com> |
Make sure preserved surface is removed when it's no longer needed Preserved surface might be used for format change as well as surface size change outside a drag resizing. We currently remove the preserved surface in prepareSurfaceLocked() after the window is shown, but sometimes app gets stopped before any animation pass is run. bug: 28546172 Change-Id: I7f883f4b5c6da4dce70f94173b368a912056d062
/frameworks/base/services/core/java/com/android/server/wm/AppWindowToken.java
|
e42d0e102dbdf5287703389183a69019b64fc35e |
|
03-May-2016 |
Wale Ogunwale <ogunwale@google.com> |
Don't remove all app token windows when window client dies AppWindowToken can contain windows from multiple clients (Processes) If one of the client dies we shouldn't remove all windows in the app token. We should only remove dea windows. Bug: 28467642 Change-Id: I8be6a98e0acc79719158567114f4902066069c1b
/frameworks/base/services/core/java/com/android/server/wm/AppWindowToken.java
|
b7b4a56a6e49e1bb9bac4294d10b4e3d341cfb2b |
|
29-Apr-2016 |
Chong Zhang <chz@google.com> |
Fix restoring surface for child windows Use allAppWindows instead of windows, as windows doesn't contain any child windows, it causes the child windows to be not restored until the child window does relayout. bug: 28296945 Change-Id: I7d272e660752002c08349128c3958aa041979c34
/frameworks/base/services/core/java/com/android/server/wm/AppWindowToken.java
|
4d7369adb3cf0e713d25abaefa74d6627ecb086e |
|
26-Apr-2016 |
Chong Zhang <chz@google.com> |
Request a wallpaper update pass when wallpaper target is set to visible Usually wallpaper target gets updated when some wallpaper target window finishes drawing. However in some cases, Recents app could be set to visible again before its stopped. (Which could happen when we started opening transition into some app with a saved surface, but the app draws so slow so that when user pressed Recents button again, the app still hasn't delivered first frame.) In this case, the surface is already drawn and we won't get a finish drawing again. We need to make sure the wallpaper target is updated. bug: 27742244 Change-Id: I8ff53f15f95bae8a99a5a0fd11e24e0186dc3345
/frameworks/base/services/core/java/com/android/server/wm/AppWindowToken.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/AppWindowToken.java
|
8bc8907ef142b4d60c1728f20cf18836833f1aad |
|
08-Apr-2016 |
Robert Carr <racarr@google.com> |
Correct window replacement string comparison. We were comparing the objects, not the strings, which happened to work in many cases as they were both the same package name String. Bug: 26668339 Change-Id: I025d05586cc6c11e788add967c7e6ad916cba276
/frameworks/base/services/core/java/com/android/server/wm/AppWindowToken.java
|
b439a63fdf9398e46ca44811fbfde35fd02911c4 |
|
08-Apr-2016 |
Robert Carr <racarr@google.com> |
Correctly prevent entrance animation for replacing windows. Prevention of entrance animation for seamlessly replacing windows, was not working for non child windows. To correct it, we simply bail from applying the app entrance transition. Bug: 26668339 Change-Id: I4349e6aef55c3957d81a0a168cf6ac1d7c8866f1
/frameworks/base/services/core/java/com/android/server/wm/AppWindowToken.java
|
d1a010f279447bbf2b186e4c24ff6bdb8ecedbf0 |
|
08-Apr-2016 |
Robert Carr <racarr@google.com> |
Replace secondary app windows across activity relaunch. Windows of TYPE_APPLICATION (as opposed to TYPE_BASE_APPLICATION) are not child windows in the sense of SurfaceView, etc, as they are independent windows like Modal Dialogs rather than embedded parts of other windows. Still though, we expect them to reappear following activity relaunch, and they won't be covered by window preservation, so we need to mark them for replacement. Bug: 26668339 Change-Id: I652b4137085f6ef4d6c9d54de609727f966ef4d6
/frameworks/base/services/core/java/com/android/server/wm/AppWindowToken.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/AppWindowToken.java
|
d78ddb409a8499c391322dd1e2b2a97446f9603d |
|
03-Mar-2016 |
Chong Zhang <chz@google.com> |
Some fixes for black screen when pressing home button Pressing home button sometimes involves a rotation (eg. when app is running in landscape mode but launch is fixed portrait mode). This will trigger a screen freeze, which clears the transition. We still need to add the opening app to the opening list even if transition is unset, otherwise it doesn't wait for app to draw first frame. Also during rotation, app, launcher and wallpaper all get relaunched. The transition can't start until the first frame on the new launcher window comes back. We can't start it based on the draw state of the old window, because the old window could get removed and readded shortly after we start the transition, and it shows up as a black frame. bug: 27391256 bug: 27295820 Change-Id: I346685076657eef209d0fab68f272e218b55e011
/frameworks/base/services/core/java/com/android/server/wm/AppWindowToken.java
|
8d5a542f66beae774354038f15dd1afe7fcf754b |
|
04-Mar-2016 |
Wale Ogunwale <ogunwale@google.com> |
Clear app token mAppStopped when app resumes. It is possible for an activity to be in the stopped state without setting it's visiblility to false in window manager. For example, the home acitivty behind the lock screen. Since the lock screen isn't an activity it doesn't affect the visiblity set of the home activity, so AM doesn't tell WM to hide the app token. However, AM uses another channel to detect that the device is locked and moves the activity into stopped state. WM on the other hand also detects that the device is locked and hides the window surfaces of all windows behind the lock screen. So, at this point AM has also told WM that the activity is stopped. Once you unlock the screen AM resumes the activity but doesn't report any visiblility changes to WM since it's internal state didn't change. So, if you go from the home activity to another app the home activity window will be destroyed before the activity is stopped because mAppStopped is set to true. We now set mAppStopped to false when the activity is resumed. Bug: 27286867 Change-Id: Ic75456d30abd582fa44f932f5aeeb449950157ee
/frameworks/base/services/core/java/com/android/server/wm/AppWindowToken.java
|
2728bf4bf9c4bc73837f41d3bf0251a7de6c9e16 |
|
03-Mar-2016 |
Wale Ogunwale <ogunwale@google.com> |
Added more log points for add/remove in window manager. Bug: 27286867 Change-Id: Iecb522a1ff7e093a8feef27fdd68c50b9a80d553
/frameworks/base/services/core/java/com/android/server/wm/AppWindowToken.java
|
9017ec0b150ee19ca1041b61c2560dff759686d7 |
|
25-Feb-2016 |
Wale Ogunwale <ogunwale@google.com> |
Remove starting window whenever the acitvity is stopped The main app window will never finish drawing at this point so there is nothing to trigger the removal of the starting window. Also, set ActivityRecord.mStartingWindowShown to true for some cases where we were telling WM to show starting window but not setting the flag that would later be used for clean-up. Bug: 26659857 Change-Id: I7a8582521853f1f95b77d8b08f4dd0cf778f8cbf
/frameworks/base/services/core/java/com/android/server/wm/AppWindowToken.java
|
c48a354733ff150e4a07f6b0743009001aa4f48d |
|
20-Feb-2016 |
Wale Ogunwale <ogunwale@google.com> |
Clean-up WindowState if exit animation is done before app finishes In ag/862571 we prevent window states from been removed before the app is stopped since it can still be rendering to the surface. The CL also left WindowState.mExiting as true after the exit transition animation runs. This is okay if the app finishes before the exit animation is done, but if the exit animation finishes before the app finishes, then we will always think we need to run an exit animation and not remove the windows when the app and later activity manager tries to remove the windows. mExiting is used to mean exiting animation is running, if it is set to true then all the code assumes an exit animation is still running and doesn't remove the window state. - Always set mExiting when animation is done. - Renamed mExiting to mAnimatingExit so it is more clear what it is used for - Allow window state to be removed is the current surface isn't shown. This should be save since there won't be any visual effect to the user. - Rename WindowState.mClientRemoveRequested to WindowState.mWindowRemovalAllowed and move setting it to true into WMS.removeWindow() so it catches all cases. - Cleaned-up the code some to be a little clearer. Bug: 27112965 Change-Id: I6f03d3c75b5b7728e42ceadc8703df40a3b4ae63
/frameworks/base/services/core/java/com/android/server/wm/AppWindowToken.java
|
4113ffac61596dc83409b2d7d3143cdfbbe01841 |
|
18-Feb-2016 |
Chong Zhang <chz@google.com> |
Make sure mExiting is cleared when app is set to visible Reset mExiting even if we are not going to do enter animation. Also make sure has surface state is set correctly if restoring. bug: 27235356 Change-Id: Ie6e78baefc8242015ed9c37ab221c39860682ab2
/frameworks/base/services/core/java/com/android/server/wm/AppWindowToken.java
|
5471e90ef97d92a94d6a0ca99f4ffc1e77a4b55a |
|
13-Feb-2016 |
Chong Zhang <chz@google.com> |
Clearing mDestroying flag when app is made visible again If not cleared window will remain invisible and can't receive inputs, which coud lead to ANR. Also continue looking for windows to be destroyed instead of stopping on first one that's not removed by client. bug: 27123118 Change-Id: I27048779886c69eb6e7ad5e21210be511416d8b6
/frameworks/base/services/core/java/com/android/server/wm/AppWindowToken.java
|
69abc194f32b5c955ac7beaf6db37269d596172d |
|
05-Feb-2016 |
Jorim Jaggi <jjaggi@google.com> |
Multi-window optimizations #1 - When the window doesn't have a surface, do not add it to mResizingWindows, so we don't report unnecessary resizes - computeDragResizing => false when window is not visible, so we never enter resizing mode even if the window decides to relayout in the background Change-Id: I8e6cdef86f1579d128973d4f2f12e87bf9b65524
/frameworks/base/services/core/java/com/android/server/wm/AppWindowToken.java
|
e12aece4cad849efbbe6a806f132613a56699230 |
|
03-Feb-2016 |
Robert Carr <racarr@google.com> |
Ensure surfaces stay alive until activity stop. Prior to this commit in this case of activity pause, with finishing=true the activity manager will notify us of app visibility and we will begin an exit animation. When this exit animation finishes, we will destroy the application surface (unless its eligible for saving). However there are two cases where this breaks down: 1. The exit animation finishes before the activity thread handles the stop transition. Many activities stop rendering on Pause but many do not and it is totally legal to do so. Sometimes this results in non fatal dequeue buffer errors and sometimes results in fatal errors with Pixel Buffers, etc... 2. We may resume the activity shortly after asking the window manager to pause it. If the window wasn't eligible for animation, we will immediately destroy it after being told of the visibility change following PAUSE_FINISHING. It's possible for this to complete before we process the resume. On the other hand the client happilly processes the resume and transitions back from PAUSE and then crashes once it attempts to use it's surface. In this commit we have the activity manager notify the window manager when an application has actually finished (or we have timed out waiting). For windows which have not been explicitly removed by the client, we defer destruction until we have received both this signal and the animation has completed. Bug: 26793431 Change-Id: Ib6ee8fbdd1f03450fbbfd62468a19e97774befab
/frameworks/base/services/core/java/com/android/server/wm/AppWindowToken.java
|
6bb8250e1b7b3345872d541071da227465fd7960 |
|
02-Feb-2016 |
Chong Zhang <chz@google.com> |
Don't clear mExiting if window is going to be removed. bug: 26819496 Change-Id: I7ab1f45f8d32bc086ded579b46b6b5e9b32771a0
/frameworks/base/services/core/java/com/android/server/wm/AppWindowToken.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/AppWindowToken.java
|
b1faf60b896afe235175354ffd90290ff93a54b4 |
|
27-Jan-2016 |
Wale Ogunwale <ogunwale@google.com> |
Use resizeMode integer instead of resizeable boolean. Changes activity manager and window manager to use resizeMode as defined by ActivityInfo#resizeMode instead of a boolean. Bug: 26774816 Change-Id: I8cef46d9fba6bfdd21df7da63ed5d5330ad03d4b
/frameworks/base/services/core/java/com/android/server/wm/AppWindowToken.java
|
eb22e8ed42bb146060e8ffc94444f70ea47fda04 |
|
21-Jan-2016 |
Chong Zhang <chz@google.com> |
Fixes for broken saved surface - Reset and restore the visibility flags and hasSurface states when surface is saved or restored. When the surface is in saved stated, we have to make the rest of the system believe that the window has no surface. - Set app windows to 'mExiting' when we start a transistion because window manager changes the visibility of the app. We can't rely on receiving a relayoutWindow from the app to invisible. We need to mark it exiting so that when the transition is done, the surfaces get removed (or saved if possible) promptly. - We need to save the surface if the app token is the last one in a task, regardless of whether it's visible, this means the whole task is going into background. But if the app has another visible token on top of it, we don't need to save it. For example one activity launches another activity, in this case we don't want to save the surface of the activity on the bottom. bug: 26573100 Change-Id: Id845f87b30cda1cebcc12ad2ac8dbf19a068a86e
/frameworks/base/services/core/java/com/android/server/wm/AppWindowToken.java
|
0102a8a8e957c38e8fe40e6cd184339ea9f38906 |
|
19-Jan-2016 |
Rob Carr <racarr@google.com> |
Merge "Replace SurfaceViews across resize trigerred relaunches."
|
23fa16b759f023ea18ab9f84e89df50d4b449dfd |
|
13-Jan-2016 |
Robert Carr <racarr@google.com> |
Replace SurfaceViews across resize trigerred relaunches. In resize modes where we are preserving the main application window, we need to tell the WindowManager to prepare to replace the child surfaces, or they will dissapear across relaunches. Bug: 26070641 Change-Id: I864168688dc320e9280e651f9c5df614f52bc96c
/frameworks/base/services/core/java/com/android/server/wm/AppWindowToken.java
|
4846ee3cc378001128680f2a3309c7e60bfcac75 |
|
07-Jan-2016 |
Jorim Jaggi <jjaggi@google.com> |
Optimize window relayouts when dragging divider - Communicate the resize mode to ViewRootImpl. If it is a docked divider resize, do not call relayout for every traversal. - Do not call Task.resizeWindows() unconditionally when changing Stack bounds. It might be just a move. - However, not calling relayout breaks layout bounds while relaunching. To fix that, do the following: -- Inform ViewRootImpl that the activity just relaunched, and force a relayout call in the next traversal so the client can pick up the unfrozen bounds. -- When unfreezing the bounds, cause a traversal in window manager. Bug: 25015474 Change-Id: Iab9a445dabce4f6ec1e25957038fe40a4be65246
/frameworks/base/services/core/java/com/android/server/wm/AppWindowToken.java
|
f596cd519a01d6796c0c2e1e92901a3a5874bb92 |
|
05-Jan-2016 |
Chong Zhang <chz@google.com> |
Some fixes for docking from navigation bar use case - Do not set replace window if we are keeping the window. - After we received the app's addWindow request, do a reset of the timeout timer to give the app more time to finish drawing. This reduces the chance of the flash due to the old window being removed before new window is drawn. - If we really hit timeout limit, make sure the replaced window is removed by using removeWindowInnerLocked(), not removeWindowLocked(). The latter does not actually remove the window if it's exiting, and this leaves the window in the stack and marked not for for replacing, then it can never be removed. bug: 26324082 Change-Id: I59594798079481cba9490c4754de1b16533e72fe
/frameworks/base/services/core/java/com/android/server/wm/AppWindowToken.java
|
0429f3522bca5bb86378dd3f013f995484ddbed6 |
|
22-Dec-2015 |
Jorim Jaggi <jjaggi@google.com> |
Freeze task bounds when relaunching To make sure that task is only laid out with the size that matches the current configuration, we have to "freeze" the task bounds when we send a configuration change. Without this change, it could happen that the app already laid out with the new task bounds, but still had the old configuration, leading to wrong layouts. Bug: 26311778 Bug: 25015474 Change-Id: I8d3a3fdf3735f446a4affbbdb4986dafc97623a5
/frameworks/base/services/core/java/com/android/server/wm/AppWindowToken.java
|
6cae765b67d3a3b37e2cacbc9816665b5bc080b9 |
|
26-Dec-2015 |
Wale Ogunwale <ogunwale@google.com> |
Added support for android.R.attr#alwaysFocusable Allows an activity to always be focusable regardless of if it is in a stack whose activities are normally not focusable. For example, activities in pinned stack aren't focusable. This flag allows them to be focusable. Also, changed ActivityInfo.#{resizeable, supportsPip} to use flags. Bug: 26273032 Bug: 26034613 Change-Id: I8c63e6d3256757e2e6931e08b8a65269f5169d35
/frameworks/base/services/core/java/com/android/server/wm/AppWindowToken.java
|
a1eb439eee65138280c560f96e2a6896f9c9112c |
|
10-Dec-2015 |
Robert Carr <racarr@google.com> |
Move window replacement tracking to window state. In preparation for supporting replacement of child windows we make replacement per window rather than per app. Bug: 26070641 Change-Id: Ifa332086599c125611e430219c9497bae7e2ce31
/frameworks/base/services/core/java/com/android/server/wm/AppWindowToken.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/AppWindowToken.java
|
13f7be9e0424266be4bf3b5c8c7fdc161e4fe091 |
|
03-Dec-2015 |
Robert Carr <racarr@google.com> |
Move surface save state tracking to WindowState. In the current set up, surface saving is managed by the app window token. So when destroySavedSurfaces is called, all saved surfaces assosciated with a given app will be destroyed. This causes pretty weird behavior where hiding child windows can destroy the parent window. We move this tracking to WindowState and allow child windows to exempt themselves. Bug: 25780116 Change-Id: I3ab92221d83297092dfd98a71e6a5fe96381de8b
/frameworks/base/services/core/java/com/android/server/wm/AppWindowToken.java
|
298a4dc8dd60700684f98dd6e959b854ea70faec |
|
02-Dec-2015 |
Wale Ogunwale <ogunwale@google.com> |
Merge "Prevent windows in pinned stack from gaining window focus."
|
d045c829a470b7c95daaa4786f7164ee8130546c |
|
02-Dec-2015 |
Wale Ogunwale <ogunwale@google.com> |
Prevent windows in pinned stack from gaining window focus. Windows in the pinned stack shouldn't receive input keys, so we prevent they from gaining window focus so the focus/input keys goes to the stack below the pinned stack. Also, cleaned up some code. Bug: 25580816 Change-Id: Iea1f944d167310233c3dbaea140a4ada568bb815
/frameworks/base/services/core/java/com/android/server/wm/AppWindowToken.java
|
0d3d1f825f399c62f2ba236b53bef17581e03a16 |
|
02-Dec-2015 |
Sungsoo Lim <sungsoo@google.com> |
Fixed typos: when when Change-Id: I80c0b8817dcbed45071e42d9ffa88bae52a93a81
/frameworks/base/services/core/java/com/android/server/wm/AppWindowToken.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/AppWindowToken.java
|
030979c1e4ad269efa747eb3c03a4b0e3d820f55 |
|
21-Nov-2015 |
Jorim Jaggi <jjaggi@google.com> |
Don't play animation when docking stack with affordance Change-Id: I1bb8ae4047e3de3a4ea159e7fad718914b9b5ba7
/frameworks/base/services/core/java/com/android/server/wm/AppWindowToken.java
|
3cd48043a32a9406980dd0daf49d90704a9ab4dc |
|
16-Nov-2015 |
Wale Ogunwale <ogunwale@google.com> |
Set-up dummy animation when setting a replacing window token Set-up dummy animation so we can start treating windows associated with the replacing app token like they are in transition before the new app window is ready for us to run the real transition animation. This allows us to make the right decisions at various call points where an animation is expected to be running for a replacing window but the real animation isn't set yet. Also, removed unused field indicating if an app token is animating a replacement window since it was always set to true and checked/set to the same value as AppWindowToken.mWillReplaceWindow. Bug: 25645069 Change-Id: Ie216ed5bd60fb2a15da61c7050c9344c48b1c5fb
/frameworks/base/services/core/java/com/android/server/wm/AppWindowToken.java
|
78a08ee876794586e1d429e67d4b94209415ea5a |
|
09-Nov-2015 |
Filip Gruszczynski <gruszczy@google.com> |
Fix blink when docking a window. We need to be very precise about removing the old window when the new one is shown. The right moment is immediately after the first frame of the new window entrance animation gets commited. This requires more infrastructure and flags, rather than depending on the old ones and hoping that they will match our needs. Bug: 25075151 Change-Id: I0fdbf38d0915ded3300d75fc7268e619b574bcf5
/frameworks/base/services/core/java/com/android/server/wm/AppWindowToken.java
|
e6a8351bc715999d1e42dcc1003a6eda6c318dd9 |
|
04-Nov-2015 |
Robert Carr <racarr@google.com> |
Extract application window usage of SurfaceController. Abstract the usage of SurfaceController from wm w.r.t application windows in to a new WindowSurfaceController class. This class tracks boring book keeping, logging, errors, etc...to lend clarity to difficult policy code in WindowStateAnimator et al. Change-Id: Ifcd5d48a51e68564f49e799ae793b320cac88645
/frameworks/base/services/core/java/com/android/server/wm/AppWindowToken.java
|
57f76f1c549f37ffb4c0eaac40b6ab633404b0f7 |
|
05-Nov-2015 |
Filip Gruszczynski <gruszczy@google.com> |
Animate the dock divider appearance/disappearance. We want to animate the dock divider appearance only after the entrance animation of the docked activity finishes, so these two don't clash. For disappearance they will animate together. Bug: 24913915 Change-Id: Ibe5c3960f21fcc5e64039b158605fa09017c5c34
/frameworks/base/services/core/java/com/android/server/wm/AppWindowToken.java
|
112eb8c1f76fff6a670d7c5f85e8c3d656cd3aa8 |
|
02-Nov-2015 |
Chong Zhang <chz@google.com> |
Save window when an app died while it's visible - If an app died visible, keep the dead window and leave it on screen. - Apply 50% dim over the dead window to indicate it's no longer active. - Monitor touch inputs on the dead window and restart the app on tap. bug: 24913379 Change-Id: I911da4e6135f2bffaf3b1bbe6f911ff689a278ff
/frameworks/base/services/core/java/com/android/server/wm/AppWindowToken.java
|
bef461f6129044bc092f0c3693bfc122d1acb6d1 |
|
27-Oct-2015 |
Chong Zhang <chz@google.com> |
Several fixes for saved surface - Do not save if the exiting app is no longer top of task - Mark saved surfaces as invalid when recoving memory, they will be reclaimed if they're hidden. - Save surface when visibility changed to GONE - Discard saved surface after rotation - Misc minor fixes and clean-up bug: 19940527 Change-Id: I5760c7a7b4bf37ef6bdd39cae793a97cf7579429
/frameworks/base/services/core/java/com/android/server/wm/AppWindowToken.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/AppWindowToken.java
|
b6e66624629448b7a8c8d5d1ec62f87ba109546d |
|
26-Oct-2015 |
Filip Gruszczynski <gruszczy@google.com> |
Improve infrastructure for replacing windows. We need to be more precise when removing the window that is being replaced. We used to depend on the fact that we can remove it after the first draw of the new added window. However, due to resizing the old window might reset its draw state and that will trigger a removal of that window. We need to add an information about the window that is replacing the old one and only when this new window draws itself, we remove the old one. This improves the transition after maximizing docked window. This is a situation where first resize operation finishes and immediately after we have a replacement operation. Bug: 24914011 Change-Id: Ia8e5bb7872787e663ba23f26588f9c4db1a5e574
/frameworks/base/services/core/java/com/android/server/wm/AppWindowToken.java
|
f77a6dbac6d8da23dea08449e930b29b62311ddb |
|
27-Sep-2015 |
Filip Gruszczynski <gruszczy@google.com> |
Merge "Refactoring: Delete AppWindowToken.willBeHidden field."
|
8aafd3a81ba4ffe04bc36990d18df9f2b8623743 |
|
27-Sep-2015 |
Filip Gruszczynski <gruszczy@google.com> |
Refactoring: Delete AppWindowToken.willBeHidden field. The only time AppWindowToken.willBeHidden is used is for determining if the app should contribute to calculating orientation. In the same check AppWindowToken.hiddenRequested will be or-ed with willBeHiden, so it's enough that hiddenRequested to be set. The only place where willBeHidden is set, is right before WMS.setAppVisibility is called, which will set hiddenRequested. Because of this willBeHidden is unnecessary. Change-Id: Iea35f39f72e7f0dcd76205ef580f3a74cac72d08
/frameworks/base/services/core/java/com/android/server/wm/AppWindowToken.java
|
61b009e0591df4fcaf5c57c6ce598044263d952f |
|
17-Sep-2015 |
Wale Ogunwale <ogunwale@google.com> |
Don't crop home activity windows to stack bounds. We crop windows to their stack bounds when the docked stack exists. We don't want to do this for the home activity since the docked stack isn't visible when the home activity is visible. Change-Id: Ibb3157dabbb6c979358ddc2098a01c6ddf6540e8
/frameworks/base/services/core/java/com/android/server/wm/AppWindowToken.java
|
55a309f8e2a972a2f0ef0cd86736d3c2f47a75f6 |
|
05-Sep-2015 |
Filip Gruszczynski <gruszczy@google.com> |
Maximize animation when activity is relaunched. This is the first step towards maximize operation animations. It builds upon preserving old window and starts clip+translate animation of the new window from the frame of the old window. It mostly uses the existing infrastructure, expanding the idea of opening apps list to include also relaunching apps and treating maximize operation as an app transition. Change-Id: I7be402bd329c2fe5bf7d53a2a910532286a8b194
/frameworks/base/services/core/java/com/android/server/wm/AppWindowToken.java
|
76cc44f31c6cc20c4bc2d6ec46c4b37da1a811a3 |
|
04-Sep-2015 |
Filip Gruszczynski <gruszczy@google.com> |
Defer removal of relaunching activity window due to config change. This is the first step towards having a better maximization experience. When the window gets replaced during relaunch of maximized activity we keep the old window around until the new one is added. Change-Id: Ia8ce26aee6577740cd38096ed2633216a07ceb60
/frameworks/base/services/core/java/com/android/server/wm/AppWindowToken.java
|
a6ab5c4efbbf438693fa976b54ac84c033109df0 |
|
24-Apr-2015 |
Wale Ogunwale <ogunwale@google.com> |
Cleaned-up unused session argument. Change-Id: Iff9d0df5f1643c581767a41a1ba4b1d43e5b45d8
/frameworks/base/services/core/java/com/android/server/wm/AppWindowToken.java
|
6dfdfd6741c5a3dd8d8a49ddbd6ee5dfe2fd292d |
|
15-Apr-2015 |
Wale Ogunwale <ogunwale@google.com> |
Added attribute showForAllUsers that deprecates showOnLockScreen The new name is more meaningful to what the attribute actually does. Also, force the FLAG_SHOWN_WHEN_LOCKED flag for windows that belong to acitivties with the showForAllUsers attribute set. Bug: 20227306 Change-Id: Ifd49166c3ec0e67ae43addc0fb30038523332ea5
/frameworks/base/services/core/java/com/android/server/wm/AppWindowToken.java
|
83162a90278d9d52d8fca7ee20ba314b452261de |
|
26-Jan-2015 |
Craig Mautner <cmautner@google.com> |
Eliminate groupId and add task to AppWindowToken Simplifies access by eliminating indirect referencing. Fixes bug 18088522 item #15. Change-Id: I9049192a7f3e1028d60c4f2d4d4a0d4aad590aa4
/frameworks/base/services/core/java/com/android/server/wm/AppWindowToken.java
|
e3119b7d353e71d1f94ddff932b722b4d285931e |
|
21-Jan-2015 |
Craig Mautner <cmautner@google.com> |
Refactor removeApp and removeTask for last removals. Move app token removal to the AppWindowToken class so cleanup can be done locally. Move task removal to the Task class so cleanup can be done locally. Call task removal when the last app is removed. Merge actions done prior to method calls into methods. Fixes bug 18088522 item #12. Change-Id: I5ce85d2bb309ceb82bd7404e27a56a7c31cd7359
/frameworks/base/services/core/java/com/android/server/wm/AppWindowToken.java
|
799bc1d383ea40637e88c4a9dba8671585202d99 |
|
14-Jan-2015 |
Craig Mautner <cmautner@google.com> |
Refactor moveStackWindowsLocked() The method had multiple inner loops and was a less efficient form of rebuildAppWindowsLocked(). Rewritten to use rebuildAppWindowsLocked() and small other refactors. Item #1 of bug 18088522. Change-Id: If93fa961922c77c9f0af719e535ae5ca5d30fe59
/frameworks/base/services/core/java/com/android/server/wm/AppWindowToken.java
|
3d7ca31c9e4a076cef5339ae58d5cafb2efbbc8f |
|
08-Jan-2015 |
Craig Mautner <cmautner@google.com> |
Remove AppWindowTokens from exiting apps with task When the task is removed from a task stack in window manager any exiting activities left in the stack were orphaned. This led to a memory leak. Removing all task activities from those that are exiting fixes this problem. Fixes bug 18943737. Change-Id: I0a5ea8d2d3be89af7ccaf01385a226a2eafdf507
/frameworks/base/services/core/java/com/android/server/wm/AppWindowToken.java
|
7b4655dbbebd9e6e9394efe145a35db41a6fbfd4 |
|
20-Nov-2014 |
Craig Mautner <cmautner@google.com> |
Ensure arraylist index is montonically decreasing A previous fix for IndexOutOfBoundsException (ag/584621) left a situation where the index would not decrement if the arraylist size didn't change. The size doesn't change if the window being removed is animating away. That caused window manager to remain in an infinite loop within removeAllWindows. This change ensures that the index diminishes each pass through the loop and doesn't exceed the bounds of the arraylist. Fixes bug 18362246. Change-Id: Ibca70d95622f3b152ede14857f0e913099dc7b88
/frameworks/base/services/core/java/com/android/server/wm/AppWindowToken.java
|
98e70d0908eaf259ac21fc75b252be3c25d788c3 |
|
10-Nov-2014 |
Wale Ogunwale <ogunwale@google.com> |
Fixed index out of bounds issue when removing windows. Child windows are also removed when WMS.removeWindowInnerLocked() is called to removed a window. This causes the number of windows to decrement by more than 1 which causes an out of bounds exception in AppWindowToken.removeAllWindows() which was expecting a decrement of 1. Changed code to only continue looping if the size of the Windows array is still greater than 0. Bug: 18202119 Change-Id: I6124717272c552ec98e89cbacaadcd964fdba02e
/frameworks/base/services/core/java/com/android/server/wm/AppWindowToken.java
|
7c9ee19cbd0360a62dc4322169afc1b0b9c9e022 |
|
15-Aug-2014 |
Craig Mautner <cmautner@google.com> |
Fix race condition between binder deaths If a Binder dies there is a race between activity manager and window manager to see who can handle the binderDied call first. If the activity manager wins the race it will remove the activity and task but leave the windows around. Until the WindowState.binderDied call is made and all animation is complete the windows will try to access the task that they were associated with. This fix removes the windows of an activity when the activity is removed. It also defers removal of the activity and task until exiting windows have completed their animation. Fixes bug 17031518. Change-Id: Idf52f55c5feb0cad4e3664ef2eae5b7e95bbf490
/frameworks/base/services/core/java/com/android/server/wm/AppWindowToken.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/AppWindowToken.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/AppWindowToken.java
|
e30e02f5d9a9141c9ee70c712d4f9d52c88ea969 |
|
28-May-2014 |
Dianne Hackborn <hackbod@google.com> |
Add system layer for voice interaction services. New window layer that voice interaction service windows go in to. Includes a new voice-specific content rectangle that voice activities are placed in to. Add specific animations for this layer, sliding down from the top (though this can be customized by the voice interaction service). Also add the concept of activities running for voice interaction services for purposes of adjusting the animation used for them, again sliding from the top, but not (yet?) customizable by the voice interaction service. Change-Id: Ic9e0e8c843c2e2972d6abb4087dce0019326155d
/frameworks/base/services/core/java/com/android/server/wm/AppWindowToken.java
|
9ef471f7f2f59de032d7cb9c3c7241486109979e |
|
07-Feb-2014 |
Craig Mautner <cmautner@google.com> |
Don't remove Activities and Tasks until animation done Just like stacks and displays, activities and tasks need to stick around until animations have completed. Change-Id: I54fe8f6855d60cbc3a25cbc6e762defd5ac50bf5
/frameworks/base/services/core/java/com/android/server/wm/AppWindowToken.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/AppWindowToken.java
|