a69243a5475c3cecc410c3328f221bab220cab8a |
|
15-Jun-2017 |
Jorim Jaggi <jjaggi@google.com> |
Don't even think about changing keyguard transit When camera was launched with a lockscreen wallpaper set, the wallpaper target was launcher in that case, which was also in mClosingApps because it was first getting shown by keyguard exit but then immediately hidden by starting the camera, before the transition started. Now since lockscreen wasn't the wallpaper target, launcher was already for some reason, and we changed the transit to WALLPAPER_CLOSE as a window with the wallpaper target was in mClosingApps. Fix this by never ever changing away from keyguard transits. Test: go/wm-smoke Test: ActivityManagerTransitionSelectionTests Test: Set lockscreen wallpaper, set animation duration scale to 0.5, insert a random sleep statement in SystemUI, launch camera from screen off while in trusted state and camera wasn't running before. Fixes: 37677242 Change-Id: I984b66d7f117034f3d55591284dd822b5ec76cbd
/frameworks/base/services/core/java/com/android/server/wm/WindowSurfacePlacer.java
|
e6c25d4a6f35449a8420f0d1e87529426786ad60 |
|
31-May-2017 |
Bryce Lee <brycelee@google.com> |
Handle not having main window in createThumbnailAppAnimator. A recent code change associated the SurfaceControl with the main window owner id. However, it is possible for the an AppWindowToken to not have a main window. This case is handled later in the method. This CL restores the original behavior of using the calling uid in the cases no main window is present. Change-Id: I8255be9e0d68adc75fda0947c64f869b7eeb76c9 Fixes: 62096254 Test: go/wm-smoke
/frameworks/base/services/core/java/com/android/server/wm/WindowSurfacePlacer.java
|
646038a3c354fe84abfd8b63f51563c7292d9b18 |
|
31-May-2017 |
Bryce Lee <brycelee@google.com> |
Merge "Revert "Handle not having main window in createThumbnailAppAnimator."" into oc-dev
|
7225427909880b917c8bd0183f87c3cb74a3a5a7 |
|
31-May-2017 |
Bryce Lee <brycelee@google.com> |
Revert "Handle not having main window in createThumbnailAppAnimator." This reverts commit 6db4d15d726b8830ad56766352a79fe0417cb9c2. Bug:62096254 Reason for revert: Breaking the build due to test references to class Change-Id: I6021c802d04a3a55a19f54fc94389957c8152ed9
/frameworks/base/services/core/java/com/android/server/wm/WindowSurfacePlacer.java
|
fd5129b978dde02e3233696ea52d0d477afad417 |
|
31-May-2017 |
Bryce Lee <brycelee@google.com> |
Merge "Handle not having main window in createThumbnailAppAnimator." into oc-dev
|
6db4d15d726b8830ad56766352a79fe0417cb9c2 |
|
31-May-2017 |
Bryce Lee <brycelee@google.com> |
Handle not having main window in createThumbnailAppAnimator. A recent code change associated the SurfaceControl with the main window owner id. However, it is possible for the an AppWindowToken to not have a main window. This case is handled later in the method. This CL restores the original behavior of using the calling uid in the cases no main window is present. Change-Id: Iad69fe383c2208c1db523c8b4601a8f927f9318a Fixes: 62096254 Test: go/wm-smoke
/frameworks/base/services/core/java/com/android/server/wm/WindowSurfacePlacer.java
|
aa7fa0135366b80d9bfdb7dffb6795b365a40607 |
|
25-May-2017 |
Winson Chung <winsonc@google.com> |
DO NOT MERGE Updating AnimationSpec and related internal APIs to use GraphicBuffer. - This reduces the copy of the hardware bitmap when it is parceled/unparceled. Bug: 38507414 Bug: 62021436 Test: Launch Overview to/from app, ensure that the header bar shows Test: go/wm-smoke Change-Id: I85a9a59a0a3699d1642158061d10fddef34393c3 Signed-off-by: Winson Chung <winsonc@google.com>
/frameworks/base/services/core/java/com/android/server/wm/WindowSurfacePlacer.java
|
97960fbf842d36d6a7ba694ce18449a3c5540612 |
|
22-May-2017 |
Matthew Ng <ngmatthew@google.com> |
Merge "Do not unminimize after rotate when minimized getting wrong transition" into oc-dev
|
26a1cecd2f9e99d7024d80748f165762a82df1e1 |
|
18-May-2017 |
Matthew Ng <ngmatthew@google.com> |
Do not unminimize after rotate when minimized getting wrong transition Docked divider was launching recents (which would unminimize) after rotation if there was more than 1 app window token in WindowManagerService.mOpeningApps and therefore this occurred intermittently. Also the app transition was incorrect WindowSurfacePlacer.handleAppTransitionReadyLocked() taking TRANSIT_NONE and converting it to something else (maybeUpdateTransitToWallpaper). Therefore pass through TRANSIT_NONE to prevent recents to run after rotating the screen even if more than 1 app window token is in mOpeningApps. Test: manual - play around with split screen then minimize and rotate Fixes: 38393264 Change-Id: Ifd536a8ce19f27c9244d68e3a63cad31e0b5d775
/frameworks/base/services/core/java/com/android/server/wm/WindowSurfacePlacer.java
|
e4338f843b234b8651d20aef15c901cbd6847bfc |
|
19-Apr-2017 |
Albert Chaulk <achaulk@google.com> |
Propagate UIDs for all SurfaceControl instances Previously, a default value was being propagated for surfaces constructed though paths other than WindowManagerService.createSurfaceControl. This allows us to handle all surfaces in VR in a better way Bug: 36589137 Test: Launch chrome (uses SurfaceView) Change-Id: I8434c356ebe51173cae161ec1405e3d5f9a17723
/frameworks/base/services/core/java/com/android/server/wm/WindowSurfacePlacer.java
|
ed7993b5d147a6741d26fe0b16cc9fa5e34ceaee |
|
28-Mar-2017 |
Jorim Jaggi <jjaggi@google.com> |
Introduce android.anim thread in system_server We create a new thread on which everything is running that directly impacts window animations, i.e. layout, anim tick and starting window creation. This is such that any work on android.display can not lead to jank in the window animation, specifically lock contention on activity manager lock that blocks callbacks from android.display into AM can not lead to window animation jank. Test: Run animation, take systrace, make sure animation is on android.anim Test: AppWindowContainerControllerTestTest: AppWindowContainerControllerTestss Fixes: 36792959 Change-Id: I5d41419a709b7984724e7053a3afdcc1ffe1aaa2
/frameworks/base/services/core/java/com/android/server/wm/WindowSurfacePlacer.java
|
87e5d55e98857bd43984c2395660d88ae20efcfc |
|
05-Apr-2017 |
Winson Chung <winsonc@google.com> |
Workaround for input ANR, always finish PiP menu activity. - Always finish the PiP menu activity when the interaction is complete (either the menu is hidden after showing, or when the user stops interacting with it and it was shown for the dismiss overlay) - Fix issue with bounds animation callback not working due to the app window being removed and not updating the app transition that its animation "finished" - Add additional logging throughout to trace PiP animation Bug: 36877782 Test: Enter PIP, tap to show menu, wait for it to hide, and then use wired headset button Change-Id: Ie88ba107d7fffdd182a4063ef4f324b58669d0ad
/frameworks/base/services/core/java/com/android/server/wm/WindowSurfacePlacer.java
|
3878ca3333da1bf5cbc83d33e5e8b3ce68c8c5e4 |
|
03-Feb-2017 |
Jorim Jaggi <jjaggi@google.com> |
Fix multi-dimen app transition delay tron event Make sure to log everything. Test: Open app, inspect log. Test: com.android.systemmetrics.functional.AppStartTests Bug: 33086172 Change-Id: I6fdfef625c09267dcf20724e853cf7471abc86c9
/frameworks/base/services/core/java/com/android/server/wm/WindowSurfacePlacer.java
|
6d41026f1b3dc910c9d34ab89993a280dc9679cf |
|
01-Mar-2017 |
Bryce Lee <brycelee@google.com> |
Clean up closing apps list when clearing anAppWindowToken's task. Previously it was possible for an AppWindowToken to be removed while on the closing apps list, used in transition animations. During these transitions, the visibility of the token is modified. Since visibility relies on the WindowContainer parent, a NullPointerException would occur. This changelist addresses the issue by making sure to remove any AppWindowToken from this list when its task is set to null. Change-Id: Id9234822b228f4658f04d42ac0fe7b49ded6f5a1 Fixes: 35352214 Test: manual (primarily code inspection)
/frameworks/base/services/core/java/com/android/server/wm/WindowSurfacePlacer.java
|
02886a82d876aa5e31a92444fec70208599c509c |
|
06-Dec-2016 |
Jorim Jaggi <jjaggi@google.com> |
Initial implementation of snapshots All this functionality is hidden behind a flag. If this flag is active, we disable the regular screenshots. Instead, we take a screenshot when an app transition for which a task is disappearing is starting. The screenshot gets stored into a gralloc buffer. SystemUI uses a new method to retrieve a snapshot gralloc buffer and then draws it using GraphicBuffer. createHardwareBitmap(). When starting an existing activity in an existing tasks, or when bringing an existing tasks to front from recents, we add a new snapshot starting window. For that, we reuse the existing starting window, but when creating the window, we use a fake window that draws the contents of the starting window. Test: runtest frameworks-services -c com.android.server.wm.TaskSnapshotControllerTest Bug: 31339431 Change-Id: If72df07b3e56f30413db5029d0887b8c9665aaf4
/frameworks/base/services/core/java/com/android/server/wm/WindowSurfacePlacer.java
|
ba41f4b9e3629c097cdd7b6538c5bcf4602728b8 |
|
15-Dec-2016 |
Jorim Jaggi <jjaggi@google.com> |
Clean up starting window to prepare for saved surfaces - Move all starting window logic to AppWindowContainerController - Use startingView to hold any kind of contents for startingWindow - Remove some conflicting code which looks very old and doesn't apply anymore. Test: Make sure starting window still works. Bug: 31339431 Change-Id: I018dd013ab7e64a44932b6d54ae9bb4a47f315d3
/frameworks/base/services/core/java/com/android/server/wm/WindowSurfacePlacer.java
|
72919d2c310db04fdb860e926ccb0bfe6e3aef08 |
|
09-Dec-2016 |
Wale Ogunwale <ogunwale@google.com> |
Untangle creation of Task from addition of AppToken in WM. Makes it easier to follow what is going on and also clean-up in preparation of stand way for AM to interact with containers in WM. Test: Existing tests pass and manual testing Change-Id: I91754b6d974dce2f696453cdaed175efb0f10c73
/frameworks/base/services/core/java/com/android/server/wm/WindowSurfacePlacer.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/WindowSurfacePlacer.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/WindowSurfacePlacer.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/WindowSurfacePlacer.java
|
f4ebe2e2ccfcbce9de7ad0c3b5399971201f66fd |
|
09-Nov-2016 |
Wale Ogunwale <ogunwale@google.com> |
Removed WallpaperController dependency on WindowList. WallpaperController now accesses the container hierarchy directly to determine the state of the wallpaper windows and targets. Bug: 30060889 Test: cts/hostsidetests/services/activityandwindowmanager/util/run-test \ android.server.cts.ActivityManagerTransitionSelectionTests Change-Id: Ib70beaf340f257ad4e1093cc127f81e7adf41636
/frameworks/base/services/core/java/com/android/server/wm/WindowSurfacePlacer.java
|
5a108c225a81cedacb1cec9b5b1986f2f3eff75c |
|
13-Oct-2016 |
Jorim Jaggi <jjaggi@google.com> |
The big keyguard transition refactor (2/n) Introduce UnknownVisibilityController, which keeps track of apps that may or may not be visible when launching an activity behind Keyguard. When Keyguard is occluded and we launch another activity, we don't know whether we still have to keep Keyguard occluded until the app has gone through the resume path and issued a relayout call to update the Keyguard flags. This class keeps track of that state and defers the app transition until the unknown visibility of all apps is resolved. Test: 1) Have an occluding activity that starts another occluding activity, ensure that there is no flicker. 2) Have an occluding activity while the Keyguard is insecure, start a DISMISS_KEYGUARD activity, ensure there is no flicker. 3) runtest frameworks-services -c com.android.server.wm.UnknownVisibilityControllerTest Bug: 32057734 Change-Id: I5145b272722ab8c31dd7c5383286f5c9473e26a4
/frameworks/base/services/core/java/com/android/server/wm/WindowSurfacePlacer.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/WindowSurfacePlacer.java
|
f7cab10b796d0f66eb690867ba327b4bb00165e3 |
|
26-Oct-2016 |
Wale Ogunwale <ogunwale@google.com> |
Introduced ReadOnlyWindowList 7th and Final step in making the modification of a display's WindowList private to DisplayContent. ReadOnlyWindowList provides an interface for external classes to DisplayContent to access the window list without being able to modify it. This will be important in upcoming CLs where it is important for us to keep track of when the window list changes. Bug: 30060889 Test: Manual testing and existing tests pass. Change-Id: I4de0b258a40fd4b21ef9cc9e3401488f76d25f83
/frameworks/base/services/core/java/com/android/server/wm/WindowSurfacePlacer.java
|
0303c5723edfdb4f2db37543544d7cbe9b14df97 |
|
20-Oct-2016 |
Wale Ogunwale <ogunwale@google.com> |
Have DisplayContent be the call point for adjusting wallpaper windows 4th step in trying to make the WindowList private to DisplayContent Have the rest of the system call DisplayContent when they need to adjust the position of the wallpaper windows in the window list instead of calling WallpaperController directly. That way the display content can control the window list that the wallpaper controller sees. Test: Existing tests pass and manual testing. Change-Id: Iaa7f421d7cd24d36e5a83e091f77b4a08d0ae123
/frameworks/base/services/core/java/com/android/server/wm/WindowSurfacePlacer.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/WindowSurfacePlacer.java
|
c69694abbdbfa3f0bedb034e7cc86823a72ff781 |
|
18-Oct-2016 |
Wale Ogunwale <ogunwale@google.com> |
Have DisplayContent be the call point for assigning window layers First step in trying to make the WindowList private to DisplayContent Have the rest of the system call DisplayContent when they need to assign layers to windows instead of calling WindowLayersController directly. That way all the various call points don't need to get the WindowList from DisplayContent to pass on to WindowLayersController. Test: Existing tests pass. Change-Id: If869abf7ba1c33b575908006ae5ad1557abc361c
/frameworks/base/services/core/java/com/android/server/wm/WindowSurfacePlacer.java
|
412754816d2b8e83f0f5f860b13f09f53d2da05f |
|
11-Oct-2016 |
Winson <winsonc@google.com> |
Adding PIP input consumer. - This CL provides the framework for manipulating the pinned stack using an input policy (to be determined later) provided by the SystemUI. Test: android.server.cts.ActivityManagerPinnedStackTests Test: #testNonTappablePipActivity Change-Id: I025c41fff26ed05a35d68e59f10330680ed11ea8
/frameworks/base/services/core/java/com/android/server/wm/WindowSurfacePlacer.java
|
d4a00a027265e5abfae335e38bd17fd744e3a2c3 |
|
10-Oct-2016 |
Wale Ogunwale <ogunwale@google.com> |
Cleaned-up some code in WindowManager This CL has no functional changes and I am just breaking this change out of another large CL I am working on. Test: existing tests pass. Change-Id: I4c93e2b1820dc31ba28f81692f2f8f6081e1f315
/frameworks/base/services/core/java/com/android/server/wm/WindowSurfacePlacer.java
|
0c4a40efc4fe01bb2fde452507241f910f79b833 |
|
07-Oct-2016 |
Wale Ogunwale <ogunwale@google.com> |
Fix wallpaper transition cts test failures Adjust wallpaper windows if an opening app has a window that can be a wallpaper target so that the right transition animation can be played. We previously relied on the chance that a previous layout pass might have set the target wallpaper correctly. Bug: 31626368 Test: run-test android.server.cts.ActivityManagerTransitionSelectionTests Change-Id: Idf5e516f4464944b7a31a55d206f05ca3d4ef407
/frameworks/base/services/core/java/com/android/server/wm/WindowSurfacePlacer.java
|
834bbbd753b73e7a84403910cab9e27f688b74a8 |
|
30-Sep-2016 |
TreeHugger Robot <treehugger-gerrit@google.com> |
Merge "Add override and merged config to WindowContainer"
|
441e4494682144aec2ec7f19060464af3d29c319 |
|
30-Sep-2016 |
Andrii Kulian <akulian@google.com> |
Add override and merged config to WindowContainer This consolidates usages of override and full (merged) configs in WM objects and also adds support of per-display configurations. Having full configs allows us to get current applied config at any level. Test: Manual tests pass. Added some new to WindowContainerTests. Change-Id: I996770433c80da41265f3e14048bd23cead097f9
/frameworks/base/services/core/java/com/android/server/wm/WindowSurfacePlacer.java
|
2b06bfc6e90aa293c7058fc6b1d1cf22fbb2ada2 |
|
28-Sep-2016 |
Wale Ogunwale <ogunwale@google.com> |
Made DisplayContent.mLayoutNeeded private scoped. And, added accessor methods for it to make it easier to debug who is setting it. Bug: 31794753 Test: Existing tests pass. Change-Id: I517c3e5cc7535cb90c47c112d42fa1dbf0b81583
/frameworks/base/services/core/java/com/android/server/wm/WindowSurfacePlacer.java
|
b4928a3c5651cd413d6315e2164a09c640f8b3e0 |
|
23-Sep-2016 |
TreeHugger Robot <treehugger-gerrit@google.com> |
Merge "Added RootWindowContainer"
|
d7755fe8d58dda06a77480d25107cf1b364cd78f |
|
23-Sep-2016 |
Robert Carr <racarr@google.com> |
Fix animation glitch with overlapping orientation changes. am: 42769fff6f am: f7f12caa73 am: 022505eb69 Change-Id: If73dd0a1f65a83af13e8621a6ae191c938b9668e
|
e05f5014905569d69d33ff323a3c62c046552789 |
|
17-Sep-2016 |
Wale Ogunwale <ogunwale@google.com> |
Added RootWindowContainer RootWindowContainer will be the root/head of the window hierarchy. Also, moved all access of DisplayContent into RootWindowContainer. Bug: 30060889 Test: Manual testing and existing tests still pass. Change-Id: Icdf80a4c053578fb91221e6f2b672e197054a6bf
/frameworks/base/services/core/java/com/android/server/wm/WindowSurfacePlacer.java
|
42769fff6ffe3369333ff8366f7eede5da9f2637 |
|
20-Sep-2016 |
Robert Carr <racarr@google.com> |
Fix animation glitch with overlapping orientation changes. Imagine the following scenario: 1. We want to begin a new app transition to an app which will change the orientation. 2. A rotation animation from a previous rotation change is in progress. 3. Windows have finished drawing the first orientation change, so the display is already unfrozen. In this case, we won't have a chance to select the new orientation which our pending transition requires, because updateRotationUncheckedLocked will bail due to the existing animation being in progress. This causes the app behind to be revealed in the incorrect orientation (sometimes creating landscape launchers) and the transition to be interrupted halfway by the screenshot. In this case we can just defer the app transition until the rotation animation has had a chance to complete. Bug: 31098404 Change-Id: I1ae1041d3018d5681b46cd39c2d582861f0b014e
/frameworks/base/services/core/java/com/android/server/wm/WindowSurfacePlacer.java
|
718071bcaff14244e228ada86de7b20fa0ea0cfb |
|
20-Sep-2016 |
TreeHugger Robot <treehugger-gerrit@google.com> |
Merge "Move updating stack override config to ActivityStack"
|
1e32e025ad5677ce4e3697ca026c2019fe0bd8e9 |
|
17-Sep-2016 |
Andrii Kulian <akulian@google.com> |
Move updating stack override config to ActivityStack Also added some multi-display TODOs. Change-Id: Iada3f84c4f57c9623fc7f116819d4e0267ebc32a
/frameworks/base/services/core/java/com/android/server/wm/WindowSurfacePlacer.java
|
68e5c9e93a8f1542cd988ac01ba1d98381ff4893 |
|
14-Sep-2016 |
Robert Carr <racarr@google.com> |
Log transaction state to RemoteSurfaceTrace. Test: cts-tradefed run singleCommand cts -o --module CtsWindowManagerHostTestCases --test android.server.cts.SurfaceViewMovementTests#testSurfaceMovesWithParent Change-Id: I2aeda867f0071bf6ac715153ab842a9f16cafa44
/frameworks/base/services/core/java/com/android/server/wm/WindowSurfacePlacer.java
|
828882a2da9c56c8a983b00da5d9902722aab7ea |
|
17-Sep-2016 |
TreeHugger Robot <treehugger-gerrit@google.com> |
Merge "Configuration renaming and minor cleanup in AM and WM"
|
8072d11f6a41a68600a15623ca5316ca0def1856 |
|
16-Sep-2016 |
Andrii Kulian <akulian@google.com> |
Configuration renaming and minor cleanup in AM and WM - Configuration members in AM and WM are renamed to mGlobalConfiguration. - Renamed parameters names in some methods to better represent their meaning. - Added and fixed some docs. Change-Id: Ie51f687fe4c10dbce776435f29d6b853fda50eec
/frameworks/base/services/core/java/com/android/server/wm/WindowSurfacePlacer.java
|
3f4433dadb7627153939ebb7d88d080c132b7f7f |
|
19-Aug-2016 |
Wale Ogunwale <ogunwale@google.com> |
Made Task.mAppTokens private scoped Also, remove TaskStack.getTask() method. Bug: 30060889 Change-Id: I1ed9710ff630b390d28e6f2146db4202e2bc860b
/frameworks/base/services/core/java/com/android/server/wm/WindowSurfacePlacer.java
|
9adfe5776d42c9ddfd4394958993304c9d355229 |
|
09-Sep-2016 |
Wale Ogunwale <ogunwale@google.com> |
Moved rebuilding of display WindowList to DisplayContent Some of this is also in WindowContainer and its children. However, I hope we can remove the concept of window list in the future. Bug: 30060889 Change-Id: I9e531327643c28a0ba35baa812b9c2942993d7b7
/frameworks/base/services/core/java/com/android/server/wm/WindowSurfacePlacer.java
|
63d4ecc7a5c23f1ebbd3d71e5054041d90df9762 |
|
09-Sep-2016 |
Wale Ogunwale <ogunwale@google.com> |
Moved window focus calculation to DisplayContent In prep. for using WindowContainer. Bug: 30060889 Change-Id: Ide3022b3129b3d190f631a07d7589a27c434e0c3
/frameworks/base/services/core/java/com/android/server/wm/WindowSurfacePlacer.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/WindowSurfacePlacer.java
|
24ad15ecee1c4e453b74bc432534a0a3649ca48d |
|
09-Sep-2016 |
Robert Carr <racarr@google.com> |
resolve merge conflicts of 6540c23 to master Change-Id: I9557b4f7aae5bb64d256da26a290b326f39c9104
|
5dc3f284bd4d4163738a5d133448a9193595fde3 |
|
08-Sep-2016 |
Robert Carr <racarr@google.com> |
Remove reuse of pending deferred transactions. Only defer transactions originating from repositionChild. There is no guarantee the frame we are suggested to synchronize to will ever arrive and synchronizing WM originated transactions to this can interfere with implementation of system policy. Anyway this code originally was fixing a case where transactions pushed by pulling down the notification shade, would interrupt animating SurfaceView's by pushing an undeferred transaction for those SurfaceView's. This doesn't seem to be occuring anymore even without this code. Furthermore even if it was occuring, we should prevent transactions from pushing updates for Surfaces where nothing has really changed, rather than attempt to chain the deferred transactions. Bug: 31293950 Bug: 27098060 Bug: 28858420 Change-Id: Ifb83fe78bb4e7d18376e53a743709648aa1e03bc
/frameworks/base/services/core/java/com/android/server/wm/WindowSurfacePlacer.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/WindowSurfacePlacer.java
|
571771c3fc912e63f83b75693c0f3c85ec9622da |
|
26-Aug-2016 |
Wale Ogunwale <ogunwale@google.com> |
Added WindowContainer.removeImmediately to support immediate removal There are 2 types of window conatiner removals. The ones that happen immediately and the ones that are deferred until the system is in a good state to handle them. WindowContainer and its child classes now support both through WC.removeImmediately() and WC.removeIfPossible() methods. The method names create a consistency in the codebase and also makes is obvious what the methods will do. Bug: 30060889 Change-Id: I459c2eef17e20cefc42e9cc542c9a3c69fc9b898
/frameworks/base/services/core/java/com/android/server/wm/WindowSurfacePlacer.java
|
9bc47736362d03b3f099bf018255571457403c1f |
|
10-Aug-2016 |
Wale Ogunwale <ogunwale@google.com> |
Removed child windows from WindowToken window list With the window container hierarchy model, containers should only link to their direct children and delegate any operation on decendants of their children to their children. Bug: 30060889 Change-Id: I99ca0d181d54cfe75bbe24c1b0daaa06cf7cfd9a
/frameworks/base/services/core/java/com/android/server/wm/WindowSurfacePlacer.java
|
f96cb3c34df22d5dec0c0dbc35c917ab1f8993d3 |
|
15-Aug-2016 |
Chong Zhang <chz@google.com> |
Revert "DO NOT MERGE -- Revert the following two commits as they're causing flickering" This reverts commit 44bd57ee25484bd74025c116f8a83d1df5990f34. bug: 30831873 bug: 30790402
/frameworks/base/services/core/java/com/android/server/wm/WindowSurfacePlacer.java
|
44bd57ee25484bd74025c116f8a83d1df5990f34 |
|
12-Aug-2016 |
Chong Zhang <chz@google.com> |
DO NO MERGE -- Revert the following two commits as they're causing flickering When double tapping Recents, need to reinvestigate. b/30831873 b/30790402 Revert "Clear WS.mDestroying on AWT.clearAnimatingFlags" This reverts commit c2661e52eae3161ac8c02e831290ad50ad395be2. Revert "Some fixes for transition animation selection" This reverts commit 73e9bc3f1557f0320c8af843dfb051f27187361d.
/frameworks/base/services/core/java/com/android/server/wm/WindowSurfacePlacer.java
|
671cb4ba9fee0cca18ba0a925392b2199e08723d |
|
12-Aug-2016 |
Chih-Hung Hsieh <chh@google.com> |
resolve merge conflicts of 76ce8e5 to stage-aosp-master am: ed935c32f4 am: ef57a0d629 am: 61bc404c0c Change-Id: I4b57bb0e5c418a8d3305c0b337afd290a778c9b4
|
19353b45e5145daa7415a91540666dc2fe2a0e12 |
|
12-Aug-2016 |
Andrii Kulian <akulian@google.com> |
Allow to keep screen on only if window can be seen am: b20addbdfb Change-Id: I09e12733e8073814f8d16c3d4025db8f042c2f25
|
305d610fd893ed838089130e0a4e1e6fea5e01ce |
|
12-Aug-2016 |
Chong Zhang <chz@google.com> |
Merge "Allow to keep screen on only if window can be seen" into nyc-mr1-dev
|
808621ca54d0d72c5e291c290bc13e3d3f3c0140 |
|
29-Jul-2016 |
Chong Zhang <chz@google.com> |
Some fixes for transition animation selection - Request wallpaper adjust after we clear mDestroying or mAnimatingExit flags, as these could affect wallpaper target selection result. - Adjust wallpaper before we check lower/upper target. As there could be pending operations that requested a wall- paper update. Lower/upper target is needed to correctly decide if the opening or closing apps had wallpaper. - Make sure lower/upper targets are set even when current target is clientHidden, in which case we should set wallpaper target to old target but the lower/upper still needs to be set up. Bug: 30790402 Bug: 30255354 Change-Id: Ie2c94439142cbb91660c5aa4164cc660831486d5 (cherry picked from commit ec8299ca4575cb5afe96bb60082d50cb8a01c74b)
/frameworks/base/services/core/java/com/android/server/wm/WindowSurfacePlacer.java
|
60091a978f21994e59388d90b90cc1dbe0537628 |
|
28-Jul-2016 |
Chong Zhang <chz@google.com> |
Dump out last real used app transit type Easier for debugging or testing bad exit animations. Bug: 30790402 Bug: 30255354 Change-Id: I8097195bfc918baf66ecc99b55f4845aba2eaff4 (cherry picked from commit 1c93f6de2dd74dfc7ee0f52aca6e8b491ace02f9)
/frameworks/base/services/core/java/com/android/server/wm/WindowSurfacePlacer.java
|
b20addbdfb6e09f1721798db531aeec73d45a374 |
|
10-Aug-2016 |
Andrii Kulian <akulian@google.com> |
Allow to keep screen on only if window can be seen If user has static wallpaper on lock screen and live wallpaper on home screen, when screen is locked, wallpaper will not be an obscuring window. In this case, if there is a non-obscured app window behind the lock screen which has FLAG_KEEP_SCREEN_ON set, it will not allow to turn screen off automatically, although it is not really visible behind lock screen. This CL restricts holding screen windows to only ones that can be seen. Same applies for screen and button brightness and user activity timeout settings. Bug: 30359386 Change-Id: I46de831211c943d8077282e3274b2df180739239
/frameworks/base/services/core/java/com/android/server/wm/WindowSurfacePlacer.java
|
a6cc361e34337c7fe293a56713910faf0f2f302c |
|
04-Aug-2016 |
Wale Ogunwale <ogunwale@google.com> |
Add child windows to their parent WindowToken Previously child windows were contained in their own WindowToken and also added to the parent window AppWindowToken.allAppsWindow. This complicated the token organization within WM as it was sometimes confusing which list to use WindowTokens.windows or appAppsWindow which led to many bugs fixed and still existing. I can't think of a good reason why the child windows just can't be tracked with the parent token so we will do that and fix whatever bug may come. This paves the way to consolidate WT.windows and AWT.appAppsWindow list since they will contain the same entries now and also fits in with the hierarchy model we will be using with WindowContainers. Also - Removed WindowState.mRootToken since a window and its children will now be in the same WindowToken. - Fixed NPE in WindowState.getTopParentWindow() - Temp. workaround to not re-add child windows in WT.reAddAppWindows since WindowState.reAddWindowLocked() will re-add any children of the parent window we are adding. Workaround can be removed when the class is switched to use WindowContainer. Bug: 30060889 Change-Id: I604ba4cce9ff8df4e81353cb648d6f54aa27084f
/frameworks/base/services/core/java/com/android/server/wm/WindowSurfacePlacer.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/WindowSurfacePlacer.java
|
e4da0c145e89274f98c683d4e045644400ea1a18 |
|
29-Jul-2016 |
Wale Ogunwale <ogunwale@google.com> |
Made WindowToken.windows protected. Pre-clean-up before switching class to using WindowContainer. Bug: 30060889 Change-Id: I2a0c09e99b742fa32e9cbe96e3bf97e5415da2c3
/frameworks/base/services/core/java/com/android/server/wm/WindowSurfacePlacer.java
|
ec8299ca4575cb5afe96bb60082d50cb8a01c74b |
|
29-Jul-2016 |
Chong Zhang <chz@google.com> |
Some fixes for transition animation selection - Request wallpaper adjust after we clear mDestroying or mAnimatingExit flags, as these could affect wallpaper target selection result. - Adjust wallpaper before we check lower/upper target. As there could be pending operations that requested a wall- paper update. Lower/upper target is needed to correctly decide if the opening or closing apps had wallpaper. - Make sure lower/upper targets are set even when current target is clientHidden, in which case we should set wallpaper target to old target but the lower/upper still needs to be set up. bug: 30255354 Change-Id: Ie2c94439142cbb91660c5aa4164cc660831486d5
/frameworks/base/services/core/java/com/android/server/wm/WindowSurfacePlacer.java
|
b0df7b2a2ae60fefbb70770a155466af548add8e |
|
29-Jul-2016 |
Chong Zhang <chz@google.com> |
resolve merge conflicts of 70327bd to master Change-Id: I9f5859fca0ed16406157dbb342a85a4f779f9218
|
1c93f6de2dd74dfc7ee0f52aca6e8b491ace02f9 |
|
28-Jul-2016 |
Chong Zhang <chz@google.com> |
Dump out last real used app transit type Easier for debugging or testing bad exit animations. bug: 30255354 Change-Id: I8097195bfc918baf66ecc99b55f4845aba2eaff4
/frameworks/base/services/core/java/com/android/server/wm/WindowSurfacePlacer.java
|
e05bcb15d5944dee38e21fe64315ebf6673e69c7 |
|
27-Jul-2016 |
Chong Zhang <chz@google.com> |
Cleanup mAnimatingExit flag before maybeUpdateTransitToWallpaper() If we get onStopped before next resume, but previous exit animation doesn't finish by the time the entering animation is started, notifyAppResumed() won't do a surface cleanup (since it's already stopped). Then maybeUpdateTransitToWallpaper() will think the wallpaper target (launcher) is invisible because of the mAnimatingExit==true, thus fails to pick WALLPAPER_OPEN animation. We need to clear mAnimatingExit and relevant flags before maybeUpdateTransitToWallpaper(). Currently we do it in handleOpeningApps but that's too late. bug: 30255354 Change-Id: Idb049c54978824709a190c413d82d42f40226aa7
/frameworks/base/services/core/java/com/android/server/wm/WindowSurfacePlacer.java
|
39d3c994fa59bb077eb5ec1d7c2d4cf61b159b54 |
|
22-Jul-2016 |
Robert Carr <racarr@google.com> |
Also report resize when frame changes without inset change. am: 31aa98bea8 am: e0b66c2964 Change-Id: Ib5b72acf703743db393174e6a58c6fa2d96c851a
|
31aa98bea8b41e4e0e1f0c78be18dce8ef597f79 |
|
21-Jul-2016 |
Robert Carr <racarr@google.com> |
Also report resize when frame changes without inset change. Currently we report resize via two main code paths: 1. Insets change. 2. Drag resizing/resized while not drag resizing. Unfortunately the case of IME dismissal with SOFT_INPUT_ADJUST_RESIZE will not trigger either. For #1, both the content and the parent frames are adjusted together (similar to a docked resize), and so we won't produce any insets beyond the system ones. For #2, we would only hit this path if we went through the Task, but this all happens in PhoneWindowManager layout. Prior to 3ccc5273 ("only resize during relayout"), the lack of resize reporting wasn't a significant issue, as we would go ahead and resize the dialog anyway. Assuming it wasn't in the middle of a frame it would eventually catch up and render things correctly. Following this change though we need to ensure we trigger the client calling relayout. We accomplish this simply by also reporting frame changes. Bug: 30191926 Change-Id: I95c7553e5e219e4a50c92f4d47621a32567a626f
/frameworks/base/services/core/java/com/android/server/wm/WindowSurfacePlacer.java
|
e4343ef468d4425d96b45e98a8556c2a76f9e030 |
|
19-Jul-2016 |
Wale Ogunwale <ogunwale@google.com> |
Switched WindowState to use WindowContainer for managing children Bug: 30060889 Change-Id: Ia451b623123210514e79f830f92f6459169911b6
/frameworks/base/services/core/java/com/android/server/wm/WindowSurfacePlacer.java
|
caa53afa0cae85a69da1b5bfb9b8368b152c917b |
|
17-Jul-2016 |
Wale Ogunwale <ogunwale@google.com> |
Made WindowState.mParentWindow private scoped. Bug: 30060889 Change-Id: Ic1d702cb6329fb2f03d006939f5610681d1d07bd
/frameworks/base/services/core/java/com/android/server/wm/WindowSurfacePlacer.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/WindowSurfacePlacer.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/WindowSurfacePlacer.java
|
7ed4d37b74850e2ed5dfd50109dc6fa919904c7c |
|
10-Jul-2016 |
Wale Ogunwale <ogunwale@google.com> |
Rename WindowState.mAttachedWindow to WindowState.mParentWindow Helps with code clarity and reduces confusion for upcoming WM object modeling changes. Also, along the same lines changes locations that check to see if WS.mAttachedWindow wasn't null to determine if the window is a child window to use WS.isChildWindow method instead. Bug: 30060889 Change-Id: I9b975ab9ff9bf09cdd3c0dcaddd3bf9232e88be8
/frameworks/base/services/core/java/com/android/server/wm/WindowSurfacePlacer.java
|
8784be6fe485939c3ae758edbcbbcb85d2b123ae |
|
29-Jun-2016 |
Chong Zhang <chz@google.com> |
Add a few trace points for animation loading. Also make sure focusMayChange is set as before commit 8c5d42. We only want to skip the applyAnimationLocked if animation is already set, make sure the rest are equivalent. bug: 29405575 Change-Id: I8342b82d9e6e02fab002e16ffcde4a7479bf6867
/frameworks/base/services/core/java/com/android/server/wm/WindowSurfacePlacer.java
|
7774bd554c28e33b732e449d029137537eb917da |
|
17-Jun-2016 |
Wale Ogunwale <ogunwale@google.com> |
Always report window move to client ag/1037916 added logic to only report window movement to the client if the window doesn't have a task or its stack is bounds animating. This causes problems on the client side for window that don't fall into this category as they will have the wrong information of where they are no screen. Bug: 29093176 Change-Id: I958174af430f2c4003a1c0a74956964d209c0e4a
/frameworks/base/services/core/java/com/android/server/wm/WindowSurfacePlacer.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/WindowSurfacePlacer.java
|
c7294607fc0debc54e92abac18bec2601a21ce27 |
|
13-May-2016 |
Robert Carr <racarr@google.com> |
Fixes for ending PiP animation. During the PiP animation, we have two basic requirements: 1. We need to scale windows to the pinned stack bounds. 2. We need to halt resize and movement notifications to the client. As we end the animation, we need to disable these states at differing times. First we need to deliver a final resize and movement notification to the client for it's new position. However, Surfaces may not immediately resize (in particular in the case of child windows, it may be some time!), furthermore Surfaces may resize at different times so we need to persist scaling on a Surface by Surface basis after reenabling resize notifications. Bug: 28559097 Change-Id: I6d52a3e213e08a34f4c0eea892b2a84cd4c20e18
/frameworks/base/services/core/java/com/android/server/wm/WindowSurfacePlacer.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/WindowSurfacePlacer.java
|
e22006d936e0928b4a335646f19a8ca18a7fb1e2 |
|
09-May-2016 |
Chong Zhang <chz@google.com> |
Fix a flicker when opening app again quickly while it's exiting If the app is waiting for an opening animation with a dummy placeholder, we need to skip the surface placement (in addition to the animateLocked). Also, when animating is changing from exiting to entering, the mAnimating flag needs to be cleared until the new animation starts. This prevents the surface placement to place it wrong before the new animaition starts. bug: 28599295 bug: 27742244 Change-Id: I26f0ead80ee9993a6c766ae8686ab11d1729519c
/frameworks/base/services/core/java/com/android/server/wm/WindowSurfacePlacer.java
|
6afe594461930e83cbf5ecf181bf43fcba0060dd |
|
05-May-2016 |
Chong Zhang <chz@google.com> |
Merge "Debug traces to facilitate screen timeout debugging" into nyc-dev
|
4ffc3180121b36eec2577b3c311ad4da44c3af56 |
|
05-May-2016 |
Chong Zhang <chz@google.com> |
Debug traces to facilitate screen timeout debugging bug: 27522448 Change-Id: I4d51be316e4aedecffb7001126849d7c6136d517
/frameworks/base/services/core/java/com/android/server/wm/WindowSurfacePlacer.java
|
d75962eb8377e0d5e500e4cf36f2abce9bbadfcc |
|
04-May-2016 |
Jorim Jaggi <jjaggi@google.com> |
Fix wrong import Bug: 28557404 Change-Id: I785bf29d094b26037e5ca0798af5df8a663b85cf
/frameworks/base/services/core/java/com/android/server/wm/WindowSurfacePlacer.java
|
363ab98fced07bf7647355367be9e6ef76751450 |
|
27-Apr-2016 |
Jorim Jaggi <jjaggi@google.com> |
Fix regression with docking from recents transition Because we move the task to the front in startRecentsActivity, we always overrode the app transition type. Instead, we should remove this logic and keep a flag whether the animation was prolonging was finished already. If it was finished already, don't start the prolonging when starting the transition. Bug: 27154882 Change-Id: I1cd9e323867726ebd4b131ed5c13c3834d0f1107
/frameworks/base/services/core/java/com/android/server/wm/WindowSurfacePlacer.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/WindowSurfacePlacer.java
|
43e38de2530fecbbdea81c52d0fde90333432356 |
|
15-Apr-2016 |
Ruchi Kandoi <kandoiruchi@google.com> |
window: Adds a Sustained Performance Mode window flag. Adds setSustainedPerformanceMode(boolean) API for applications to set the mode for a given window. The mode will be disabled automatically when the window is no longer in focus. Bug: 28150358 Change-Id: Ibe8bc564eeaaccbcaad5c4f792cda16da931dffd Signed-off-by: Ruchi Kandoi <kandoiruchi@google.com>
/frameworks/base/services/core/java/com/android/server/wm/WindowSurfacePlacer.java
|
679c807210e4d741b4c65ac67d298d1d56abf3ee |
|
08-Apr-2016 |
Robert Carr <racarr@google.com> |
Synchronize future unsync transactions to last sync. This ensures we don't push through an unsynchronized update while a synchronized one is pending. If the synchronized one is no longer pending, then our transaction is applied anyway and things continue as normal. Bug: 27098060 Change-Id: I08fe8f848848d25d01b1696e0340fcce61ac554f
/frameworks/base/services/core/java/com/android/server/wm/WindowSurfacePlacer.java
|
b20247636b0e0a75edcd327a047b9ea7a9d21b77 |
|
06-Apr-2016 |
Winson <winsonc@google.com> |
Disable landscape aspect-scaled behavior for TV. Bug: 27923205 Change-Id: Ibe45ba62a9de9c03480844235efc97e8b8299e61
/frameworks/base/services/core/java/com/android/server/wm/WindowSurfacePlacer.java
|
0d50d8660dac35f7eceb5d74756de0417095b427 |
|
30-Mar-2016 |
Vladislav Kaznacheev <kaznacheev@google.com> |
Add wallpaper input consumer to WindowManagerService This is an input consumer similar to the one used when hiding the navbar, but placed above wallpapers. It might be useful for processing touch events over "desktop" in freeform MW mode. Re-landing I9d6d28a624f750ad48fc39f9b149dd1f989cceba after fixing build. Bug:26688904 Change-Id: I89fdabd9c72cdd4a1d7ca626c33ddc99ddea97f9
/frameworks/base/services/core/java/com/android/server/wm/WindowSurfacePlacer.java
|
2769e7ebe9d9c5b7f1d10b21b32787b98522339f |
|
31-Mar-2016 |
Vladislav Kaznacheev <kaznacheev@google.com> |
Revert "Add wallpaper input consumer to WindowManagerService" This reverts commit 6013a558262d149023b32ab175c9b885b6c5b81d. Change-Id: I2711afe2e97a8b9a4bd94193202cb83113b3bd7e
/frameworks/base/services/core/java/com/android/server/wm/WindowSurfacePlacer.java
|
6013a558262d149023b32ab175c9b885b6c5b81d |
|
30-Mar-2016 |
Vladislav Kaznacheev <kaznacheev@google.com> |
Add wallpaper input consumer to WindowManagerService This is an input consumer similar to the one used when hiding the navbar, but placed above wallpapers. It might be useful for processing touch events over "desktop" in freeform MW mode. Bug:26688904 Change-Id: I9d6d28a624f750ad48fc39f9b149dd1f989cceba
/frameworks/base/services/core/java/com/android/server/wm/WindowSurfacePlacer.java
|
baba78319b954e8e42b8ecfc03b5fedc28a6168b |
|
24-Mar-2016 |
Chong Zhang <chz@google.com> |
Animate IME adjustment for docked stack through the divider This makes sure the top stack crop, divider position and bottom stack surface position moves together with the IME window. Currently the bottom stack and divider are moving together but top stack crop is changed immediately. bug: 27779495 Change-Id: I653ad9093621b218d9c11b0bb2efdddb1d33763e
/frameworks/base/services/core/java/com/android/server/wm/WindowSurfacePlacer.java
|
0907200095ec73e71c6520580a9b82126058ddf2 |
|
26-Mar-2016 |
Jorim Jaggi <jjaggi@google.com> |
Fix thumbnail disalignment on curved paths Bug: 27607141 Change-Id: I146deaa6ce049f27165a236b3aef95b9d4694ced
/frameworks/base/services/core/java/com/android/server/wm/WindowSurfacePlacer.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/WindowSurfacePlacer.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/WindowSurfacePlacer.java
|
192086eb8aff3fb873a7e03ade0b81652aacf25f |
|
11-Mar-2016 |
Jorim Jaggi <jjaggi@google.com> |
Implement transition for docking task in recents #1 - When the docking transition is happening, defer updating the bounds of the home stack until the transition is done. This is to preserve the scrim which is drawn in the recents activity. - Use the PROLONG_AT_START infrastructure to hide the task in recents when starting the app transition. - When recents finally get resized at the end of the transition, reset it's draw state so we don't move the old surface around, and the new surface gets drawn at the new position, to avoid flickering. - Remove hack around not layouting docked divider if it's not visible, it's not needed anymore and resulted in a wrong initial position. - Fix animation selection for docked stack divider. - Make sure win.moved() always gets called. Bug: 27607141 Change-Id: I76c35f09461f044a90e2c88335008284b5839cc0
/frameworks/base/services/core/java/com/android/server/wm/WindowSurfacePlacer.java
|
b58bbccd2d230901e93191bf8b244708014b0a38 |
|
23-Mar-2016 |
Chong Zhang <chz@google.com> |
Do not adjust bounds for IME until IME is actually displayed When the IME window is just relayout to visibe but not drawn yet, the given insets of the IME window may not be set. Adjusting the docked stack at the time may cause wrong bounds to be used. So we wait until the IME window is actually displayed before moving the bottom stack. Also move the divider together with the bottom stack when adjusting for the IME window. This makes it look less janky. We still have issues with the top stack's bounds changed too early, which has to be fixed separately. bug: 27779495 Change-Id: Ic53dc261d430a40677154be5b312a992aab49c79
/frameworks/base/services/core/java/com/android/server/wm/WindowSurfacePlacer.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/WindowSurfacePlacer.java
|
984600566be81ffeb2e25b43c96f6d158e16fa99 |
|
08-Mar-2016 |
Chong Zhang <chz@google.com> |
Merge "Some fixes for black screen when pressing home button" into nyc-dev
|
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/WindowSurfacePlacer.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/WindowSurfacePlacer.java
|
0d00c2e25bf8816dbd99f4fcd5c8221e80826a95 |
|
01-Mar-2016 |
Robert Carr <racarr@google.com> |
Reimplement PIP animation to not use drag resizing. When using drag resizing it is difficult to keep big surface surfaces (e.g. main app windows) and child windows in sync as we resize. Furthermore it's difficult to resize child windows quick enough to achieve more than a few frames a second as we have to propagate through the client UI thread. Our new implementation uses window scaling. Bug: 26454664 Change-Id: Iac96619cefc075b1412cfeba3d3c9bcd7ce22f52
/frameworks/base/services/core/java/com/android/server/wm/WindowSurfacePlacer.java
|
275561a74677f9d6c8f3f2cebc3cfea416ca586d |
|
23-Feb-2016 |
Jorim Jaggi <jjaggi@google.com> |
App transition delay tracking Add TRON logging for all kinds aspects when we execute an app transition. Bug: 27295491 Change-Id: Icb0cbdb92d4d5fbfedadd40a017a50eb217058aa
/frameworks/base/services/core/java/com/android/server/wm/WindowSurfacePlacer.java
|
9ecf7cfee8c681587bd7cf6468aff80178e2d2d9 |
|
20-Feb-2016 |
Wale Ogunwale <ogunwale@google.com> |
Merge "Clean-up WindowState if exit animation is done before app finishes" into nyc-dev
|
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/WindowSurfacePlacer.java
|
42625d1bc7ef99c4d4435e8cdebfe3eee57b8d97 |
|
12-Feb-2016 |
Jorim Jaggi <jjaggi@google.com> |
New behavior for docked stack when going home - We keep the docked stack visible when home task is visible even though it's not resizable. - We introduce the a new concept called "minimizing" the docked stack, which happens when going home. In this state, the docked stack is clipped of almost completely. - To achieve that, we introduce TaskStackBoundsAdjustController, which adjusts the bounds of the docked stack when minimized. Also, migrate the IME handling to this new class. - We also need to inform SysUI that it is now minimized so it can remove the drag affordance on the divider, and also make it a bit smaller. - When we detect an app transition, we check whether the home stack gets visible/invisible. We then start an animation which runs in sync with the normal app transition. For that we introduce DockedStackDividerController.animate(), which performs the animation. Bug: 27137961 Change-Id: I8623bc73cc6872bf28c5b1b8d5795974576811b2
/frameworks/base/services/core/java/com/android/server/wm/WindowSurfacePlacer.java
|
48ab53e5715cbd456662e1f5604252aa7707a3c8 |
|
03-Feb-2016 |
Rob Carr <racarr@google.com> |
Merge "Remove obsolete conditional preventing surface placement."
|
e352b18f17789897ba1d160b011e81e9b182f0ec |
|
03-Feb-2016 |
Robert Carr <racarr@google.com> |
Remove obsolete conditional preventing surface placement. This conditional seems obsolete and is preventing surface changes for dialogs on secondary displays. To show obsolesence, we can break down our cases based on display as follows: 1. Primary Display In this case we have a home stack, and we cannot enter this conditional. 2. Secondary Display (no home stack) a. Private displays - We allow layout without a homestack when type == TYPE_PRIVATE_PRESENTATION b. Other secondary displays - As TYPE_PRIVATE_PRESENTATION can only be on private displays (see addWindow) we always enter this conditional for taskless Windows (e.g. Dialogs) on secondary displays, and refuse to apply their surface changes. We can see if we remove the conditional, 1 will be invariant. 2a will remain invariant, except we allow layout when type != TYPE_PRIVATE_PRESENTATION. If there is a non private presentation window on a private display, an invariant has malfunctioned and we don't know what to do here (we don't enforce all the addWindow invariants at each surface change). In case 2b we will allow surface changes (where previously blocking them), and this seems correct, after all we wish to allow dialogs to appear on secondary displays right? Bug: 26154242 Change-Id: Ia8cbb079616a80f41b131cafe46c7408a558e307
/frameworks/base/services/core/java/com/android/server/wm/WindowSurfacePlacer.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/WindowSurfacePlacer.java
|
ce4ec406acce28395686234e04e8aa4c7f0e8cc9 |
|
22-Jan-2016 |
Filip Gruszczynski <gruszczy@google.com> |
Fix minor logging issues in WindowSurfacePlacer. Change-Id: If4ed3c36004cc8932db92adee74ab349ec2d95c4
/frameworks/base/services/core/java/com/android/server/wm/WindowSurfacePlacer.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/WindowSurfacePlacer.java
|
7fed68d116f037847f298b7d52f537998c315298 |
|
20-Jan-2016 |
Robert Carr <racarr@google.com> |
Do not clear exiting flag following explicit remove. If we begin an exit animation (setting the mExiting flag) in response to an explicit client remove request, we depend on mExiting in WindowStateAnimator::finishExit to perform the final clenaup of the window. If we are transitioning back in to the app, and it calls removeWindow before the app transition is ready, we could have handleOpeningApps clear the mExiting flag leaving this partially disposed window around due to the above mechanism. Bug: 26157153 Change-Id: I512fbbd080d423336796284fca490c2c22709180
/frameworks/base/services/core/java/com/android/server/wm/WindowSurfacePlacer.java
|
9ebbe6afe7a433f78ca3d30c9f215c53212c34ac |
|
17-Nov-2015 |
Sriram Viswanathan <tvsriram@google.com> |
Changes to support navigation bar system UI in car mode. The change has all the platform changes required to support modifications in the navbar dimensions and custom icons in car mode. The UX is not frozen yet, but have placeholder resources provided by android auto UX engineers. The change assumes that the car mode configuration is known to the WindowManagerService and uses its current ui mode to request the latest from the policy (PhoneWindowManager.java). The change is modeled on the way rotation is handled, where the Policy knows the different view attributes for uiMode and just returns back the window sizes based on the current uiMode requested. The policy does know the current uiMode, but the order of when that changes is not deterministic [from logs it does happen before any request to update UI occurs, but guess that could change]. Bug: 25996809 Change-Id: Ia46cbe5096382d26c9eb8ec74cf59a059b767edb
/frameworks/base/services/core/java/com/android/server/wm/WindowSurfacePlacer.java
|
c46f41c5b5ea5b626ed729030de100223493948d |
|
05-Jan-2016 |
Filip Gruszczynski <gruszczy@google.com> |
Fix flashing dialogs when IME enters/exits. The flashing is caused by changing the shown frame of the window prematurely, before the animation kicks in. After the animation kicks in, the shown frame goes back to the original position and then animates to the final position. We need the shown calculation to happen during layout for resizing and the layout might be triggered at any time before the animation is run. In order to avoid flashing, we don't calculate shown frame for windows that are animating during the layout and let the animation position the shown frame correctly later. Includes also logging for inset setting, which triggers layout run. Bug: 26323134 Change-Id: Ibe1efae798415d3564c659aa94c2b94af92c743a
/frameworks/base/services/core/java/com/android/server/wm/WindowSurfacePlacer.java
|
bd0d937303ae54d8a5bb5f08080c4164302daefc |
|
29-Dec-2015 |
Chong Zhang <chz@google.com> |
Notify client when the window is moved because of a resize We need to notify the client that the window has moved if a resize results in a move without size change. This makes sure that relevent info on client side (such as mAttachInfo.mWindowLeft/Top) gets updated to the new frame. Things like View.getLocationOnScreen() may depend on these to function. Bug: 25565385 Change-Id: I5b9ded0b16243c14494f9a69257d56570ee8996d
/frameworks/base/services/core/java/com/android/server/wm/WindowSurfacePlacer.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/WindowSurfacePlacer.java
|
28ba3832142a963d800ba9fa56c1e06cc1dd97f7 |
|
15-Dec-2015 |
Rob Carr <racarr@google.com> |
Merge "Move window replacement tracking to window state."
|
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/WindowSurfacePlacer.java
|
b4ec0a312de422440374638195d4709cc74227e9 |
|
14-Dec-2015 |
Wale Ogunwale <ogunwale@google.com> |
Fixed bug with task record not updating to fullscreen sometimes null is normally passed in to AMS.resizeStack API if the caller wants to change the stack size to fullscreen. However, it is possible for the caller to also pass in a bounds that corresponds to the fullscreen bounds of the display the stack is on. When this happens, the call to window manager to resize the stack correctly detects that the bounds is equal to the fullsceen bounds of the display and sets the stack to fullscreen, but the task record state isn't updated to fullscreen since they were previously calculated on the activity manager side. We now check if the bounds corresponds to the fullscreen bounds on the activity manager side and set it to null so that the task record state is correctly updated. Bug: 25683717 Change-Id: Ife753c6e6c034fd8df663ab897d245f1d354bda7
/frameworks/base/services/core/java/com/android/server/wm/WindowSurfacePlacer.java
|
4cbc315305379b0892cc4fb347d7050f3058f81e |
|
07-Dec-2015 |
Filip Gruszczynski <gruszczy@google.com> |
Fix thumbnail header animations in freeform to recents. The thumbnail header animations were constructed based on opening apps, in this case Recents. This is obviously wrong, but used to work because there was only one closing app in non-multi window world. For the animation to work correctly, i.e. each thumbnail have its own header animation, we need to correctly construct animations for either opening apps or closing apps (depending on the transition type we are seeing). The CL also refactors handleAppTransition into smaller methods. Bug: 24913782 Change-Id: I9f30a53d2f90f0628bb8c6238b2d0f35592b8f63
/frameworks/base/services/core/java/com/android/server/wm/WindowSurfacePlacer.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/WindowSurfacePlacer.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/WindowSurfacePlacer.java
|
19723a4a2bca0660f7ee7c29926af285d94ab5a2 |
|
26-Nov-2015 |
Filip Gruszczynski <gruszczy@google.com> |
Revert "Destroy docked divider surface when it's hidden." This reverts commit cb5f57bc580d7f73b93c8f504daa4dcd74cdce72. Change-Id: I1f77e1ccd5382ed57b8e4165afd79db5223f51c1
/frameworks/base/services/core/java/com/android/server/wm/WindowSurfacePlacer.java
|
b15758ab7a6481717d0d29612e870d7241061c31 |
|
17-Nov-2015 |
Chong Zhang <chz@google.com> |
Support scrolling for non-resizeable tasks in side-by-side mode Display toast when a non-resizeable task is put into side-by-side mode. Scroll the task upon a two-finger scroll gesture. bug: 25433902 Change-Id: I69967056a564cfe7773afb80aa7e7ea7167a791a
/frameworks/base/services/core/java/com/android/server/wm/WindowSurfacePlacer.java
|
cb5f57bc580d7f73b93c8f504daa4dcd74cdce72 |
|
24-Nov-2015 |
Filip Gruszczynski <gruszczy@google.com> |
Destroy docked divider surface when it's hidden. Also includes bunch of small refactorings: * destroying surfaces is now fully contained within WindowManagerServices and mDestroySurface can be privatized; * WMS.isDockedStackResizingLocked can be removed; * mScreenCaptureDisabled changes from being SparseArray<Boolean> to SparseBooleanArray, which not only avoids boxing but also makes code simpler (no need to check for null) Bug: 25844096 Change-Id: I0e5462760ffbc947ce6dc52ef429fa270ffc6786
/frameworks/base/services/core/java/com/android/server/wm/WindowSurfacePlacer.java
|
0abb20f37425fcde40f56e8dcaf7f191db820415 |
|
19-Nov-2015 |
Chong Zhang <chz@google.com> |
Fix black wallpaper when docking a non-resizeable task Separate WindowState.isFullscreen into two methods, isFrameFullscreen() that returns whether the window frame is fullscreen, and isObscuringFullscreen(), which returns whether the window is actually covering fullscreen. In case of a docking task that's non-resizeable, the window frame is fullscreen but since the stack is not fullscreen, the window is cropped to stack bounds and is not obsuring the screen. bug: 25433902 Change-Id: I7cd80381601fdc1fe87d04608b6a453806920590
/frameworks/base/services/core/java/com/android/server/wm/WindowSurfacePlacer.java
|
f52dd205b9d31e0edcfdfff4ed98259c07ca38b7 |
|
16-Nov-2015 |
Filip Gruszczynski <gruszczy@google.com> |
Don't animate move triggered by resizing using dock divider. Also includes some small, nice refactoring: * move code that sets the move animation into WindowStateAnimator; * a few fields can be made private in WindowStateAnimator this way; * one boolean flag in WindowStateAnimator popped out as unused after being privatized, so could be deleted. Bug: 25690109 Change-Id: I8144114244892c4f27aff21455e8e76eddbd039f
/frameworks/base/services/core/java/com/android/server/wm/WindowSurfacePlacer.java
|
69cf50f759e264aea0fc7d389ae85cd3121e4cb9 |
|
13-Nov-2015 |
Wale Ogunwale <ogunwale@google.com> |
Fixed bug where stack crop wasn't applied when it should - Apply stack crop if window isn't animating when replacing window. We were previously not applying the crop if replacing window regardless of the animation state. - Apply stack crop if the current docked window isn't animating. We were previously not applying if any window in the system is animating. - Also created setter/getter methods for WindowAnimator.mAnimating to make debugging easier. Bug: 25645069 Change-Id: I671549626e218358a7dea9e78bd0b2a1f1b3a51e
/frameworks/base/services/core/java/com/android/server/wm/WindowSurfacePlacer.java
|
4c9ba52acad52f1c1087415e04b2a17614707e40 |
|
11-Nov-2015 |
Chong Zhang <chz@google.com> |
Fixes for dim bounds and touch bounds - Change dimming and touch related usage to use task's "max visible bounds", which is the app within a task that's covering the maximum visible area looking down from top. This solves the problem where an app pops up a dialog window. We should dimming (and allow touch) the entire task area, not just the dialog's visible area. - Fix initial bounds used in drag moving/resizing, this should be visible bounds of the app main window, not the original task bounds. - Fix touch region set up for freeform apps, even when task is not full screen, we should get the max visible bounds first (as freeform app could have dialogs too). bug: 25494928 bug: 25487005 bug: 25613403 Change-Id: Ib1c6a1665fb83ded2fcb0a7ea92cf1def5372edd
/frameworks/base/services/core/java/com/android/server/wm/WindowSurfacePlacer.java
|
7248c568a01b4215380b0ca5d0e9583535ff2cf1 |
|
09-Nov-2015 |
Filip Gruszczynski <gruszczy@google.com> |
Fix no thumbnail animation from app to recents. Bug: 25584190 Change-Id: Ifdb7e51f077ddeff907c1e23c925cd374ed794b0
/frameworks/base/services/core/java/com/android/server/wm/WindowSurfacePlacer.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/WindowSurfacePlacer.java
|
61f39a7b988f6a22681a3f9e0bf8121f72ff88c4 |
|
29-Oct-2015 |
Jorim Jaggi <jjaggi@google.com> |
Migrate docked divider drawing to SysUI Move docked divider drawing to SysUI. This let's us have real time shadows in the future. Keep DockedStackDividerController for placing/visibility in window manager. Change-Id: I82c10add626d30f2ba180ee2a21cdbe6ddfe0371
/frameworks/base/services/core/java/com/android/server/wm/WindowSurfacePlacer.java
|
2f7d292596bdba15e441046e3a2e047f37d6ea59 |
|
29-Oct-2015 |
Jorim Jaggi <jjaggi@google.com> |
Supply app transition specs with a future Because we retain activity surfaces now, the app transition specs which were calculated/generated after the onPause() call when going from recents -> app were too slow. Instead, supply a cross-process future, which gets fetched when the window manager is about to be ready to execute the app transition. In practice, this still gets executed immediately after the onPause call. If we have a retained surface, this adds some latency, but since we absolutely need the specs to execute the transition, we have that latency no matter where exactly we generate the specs. If we don't have a retained surface, the specs are not calculated on the critical path, so it's faster. Bug: 19940527 Change-Id: I80d2c6f6b3a6568a70339619ecefbc3bd8409bd8
/frameworks/base/services/core/java/com/android/server/wm/WindowSurfacePlacer.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/WindowSurfacePlacer.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/WindowSurfacePlacer.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/WindowSurfacePlacer.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/WindowSurfacePlacer.java
|
c402520fe0fe8e85e2f905343ce2a2a740c48d9a |
|
22-Oct-2015 |
Jorim Jaggi <jjaggi@google.com> |
Coalesce layout traversal when resizing stacks When resizing the docked stack, the other stacks are also resized, leading to multiple layout traversals. Coalesce these by introducing the concept of layout traversal coalscing. In addition, don't cause layout refreshs for the stacks that are currently not visible. Bug: 25015474 Change-Id: I5692d00c044572a1bbb3ea218b0c31572585f5bd
/frameworks/base/services/core/java/com/android/server/wm/WindowSurfacePlacer.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/WindowSurfacePlacer.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/WindowSurfacePlacer.java
|
2a6a2c2de8ce2743679f488f056f22cd1adfd726 |
|
14-Oct-2015 |
Filip Gruszczynski <gruszczy@google.com> |
Change WindowState.mShownFrame to WindowState.mShownPosition. We never use this field as a rectangle, we only depend on its left-top corner. Using a frame is only confusing about the purpose of this field. Change-Id: I5d6e6321db4fa3203bb7e0f1975ae6ddd1ec09bb
/frameworks/base/services/core/java/com/android/server/wm/WindowSurfacePlacer.java
|
cd9c97db8de38fdfadab6411733f4680deebca07 |
|
04-Oct-2015 |
Filip Gruszczynski <gruszczy@google.com> |
Adjust docked stack divider for orientation. Bug: 24575031 Change-Id: Iabebaab386a5e4df3e9af36be329bc0384fd6c87
/frameworks/base/services/core/java/com/android/server/wm/WindowSurfacePlacer.java
|
0689ae903628f12ff073376b655b9d972533796b |
|
01-Oct-2015 |
Filip Gruszczynski <gruszczy@google.com> |
Fix lack of dim layer behind "Power off" window. This enables dim behind functionality for both tasks and stacks and groups it inside a controller that manages the dim layers (including shared dim layers for full screen tasks/stacks). Bug: 24331704 Change-Id: I0d1ba996d9e00d05e0203166b82268da00fbb35e
/frameworks/base/services/core/java/com/android/server/wm/WindowSurfacePlacer.java
|
e95b0aef6d259ff9322bd9a34e36e61737844eee |
|
30-Sep-2015 |
Filip Gruszczynski <gruszczy@google.com> |
Improve visibility and layering of dock divider. We adjust the visiblity of the divider now after every layout. The divider was far too high in the priority list, based on the wrong assumption that as a part of the system UI it needs to be constantly visible. It should stay at the same level as applications, because it's almost as a part of application. Layering gets improved by having the relaunch animation receive zorder top, just as if it was entering. The window that is being replaced fakes this too, since it's not being animated, but should share the behavior. Bug: 24500829 Change-Id: Iad3369a5ab6721b1bf7a94e8979dcf33e0805c7f
/frameworks/base/services/core/java/com/android/server/wm/WindowSurfacePlacer.java
|
49b80afaf9e71d6b5d4cab26f1459d84d1070f19 |
|
24-Sep-2015 |
Filip Gruszczynski <gruszczy@google.com> |
Entry animation for docking windows. We achieve the animation in the same way we would do that for maximizing windows. We preserve the exiting window of relaunched activity until the activity adds a new one. Then we animation the new window from the bounds of the old window to the dock bounds. This mostly reuses existing infrastructure for maximize animations, but unfortunately needs scaling. The before window might be have one dimension larger than after window and using cropping is not sufficient. Change-Id: I9538ba983a0af1e64ea48aad6836173d6fd25f3b
/frameworks/base/services/core/java/com/android/server/wm/WindowSurfacePlacer.java
|
5a2f2cb3de21beaa0b760bb0be1928909012f81e |
|
17-Sep-2015 |
Wale Ogunwale <ogunwale@google.com> |
Fixed issue with relaying-out sysui when resizing a freeform task. WindowState.getTask() was returning the focusedApp task for windows without an AppToken (e.g. status bar, nava bar, wallpaper). We then check to see if the config associated with the task has changed and tell the client window to resize if it as. The config would have changed in this case since we are using the focus app task (task we are currently resizing) to determine config changes for all windows without appTokens. Changed the logic so this is no longer the case. Also, cleaned-up the use of getTask(). Bug: 23939846 Change-Id: I473671021282695d282a8a2b82d679722273ca09
/frameworks/base/services/core/java/com/android/server/wm/WindowSurfacePlacer.java
|
09b21efb97d539543259b33e2da9d4c7a41966c8 |
|
14-Sep-2015 |
Chong Zhang <chz@google.com> |
Use fullscreen sized buffer for drag resizing - When drag resizing starts, set the surface size to fullscreen (plus any surface insets requested by win attrs), so that we don't reallocate buffers and the buffers don't get rejected by surfaceflinger due to size-mismatch. - When drag resizing ends, restore the surface size to the original. - Update shown frame before setSurfaceBoundariesLocked(), as the top-left of the window could change, we need to update the surface position. This fixes incorrect window positing during resizing by corners on top/left. - When doing tap-detection, skip non-freeformed tasks. This fixes the bug where clicking near border of a window could dismiss it. Change-Id: I5dc9fc34ff05685320b8fe5d491b9c066c6726e8
/frameworks/base/services/core/java/com/android/server/wm/WindowSurfacePlacer.java
|
24966d4789c7a2054650ec1a5ed7450f0d691224 |
|
06-Sep-2015 |
Filip Gruszczynski <gruszczy@google.com> |
Refactorings for Window Manager module. Following improvements were applied: * extract code from a very large method WindowSurfacePlacer.performSurfacePlacementInner into WindowsurfacePlacer.applySurfaceChangesTransaction; smaller methods are easier to understand; * WindowStateAnimator.showSurfaceRobustlyLocked can be privatized, it is only called from one place; also there is unnecessary check for whether mSurfaceControl is not null; * prepareAppTransition code can be mostly moved into AppTransition; it calls mostly methods from this class; as a result some methods from AppTransition can be privatized; * requestTraversalLocked can be moved into WindowSurfacePlacer, which allows mTraversalScheduled to be a private field inside the placer; this way WindowSurfacePlacer can nicely control and hide the need for layouts. Change-Id: I99006c859ef224f5dad933f5c15d2cb2b9738a9e
/frameworks/base/services/core/java/com/android/server/wm/WindowSurfacePlacer.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/WindowSurfacePlacer.java
|
4501d23cedbaaa33a7a28a76af61e7b097dc2d66 |
|
02-Sep-2015 |
Filip Gruszczynski <gruszczy@google.com> |
Refactor layout and surface placement into a separate class. OMG, WindowManagerService below 10kLOC. Barely. Change-Id: I7062c10c767c01c08466b3903736ee35b341f2a5
/frameworks/base/services/core/java/com/android/server/wm/WindowSurfacePlacer.java
|