summaryrefslogtreecommitdiff
path: root/core/java/android/view/IDisplayWindowRotationCallback.aidl
Commit message (Collapse)AuthorAgeFilesLines
* Synchronize display change with the ShellNick Chameyev2022-05-101-29/+0
| | | | | | | | | | | | | | | | | | This CL adds synchronization of applying of the window container transaction with split-screen layout changes after the display size change. This is needed for the unfold animation to have the split screen layout ready for the first frame of the unfold animation on foldable devices. The flow is similar to the display rotation synchonization, now it is triggered on both physical display change and rotation. Bug: 204925795 Test: folding/unfolding, rotating with a split layout when Shell transitions enabled/disabled Change-Id: I30f391dae69cf38768daf49361660d87165f886d
* Move some window related files to android.window packageWale Ogunwale2020-03-221-1/+1
| | | | | | | | | | | | | Window management files on the client side have normally been dumped in either android.view or android.app package. This CL starts to centralized them in android.window package so there is better separation. Test: they pass Bug: 147406652 Bug: 152113464 Bug: 152117221 Change-Id: I4d64bd256e9b3581af0ccf9396f7dd2454132719
* Give SystemUI a chance to participate in display rotationEvan Rosky2019-11-111-0/+29
This adds support for registering a single DisplayRotationController to WMS. It gives a chance for the controller to suggest some task changes to be executed along with a display rotation. There is only one because it's a 2-way communication and there is only intended to be one client for now. This allows us to move Split and PiP presentation/layout logic out of WM into systemui because WM no-longer needs to be the one calculating the new bounds of everything during rotation. This uses the windowcontainer transaction because all the configuration changes and the display rotation need to happen synchronously; otherwise, relayouts can occur after the display is rotated, but before the configuration changes are applied. When this happens, apps get incorrect bounds/insets which can trigger erroneous lifecycle events in the app. The flow is like this: 1. DisplayContent/Rotation freezes screen 2. DisplayRotationController is notified of a rotation and provided a callback. 3. The Controller then evaluates/queues some task changes in a transaction and, when done, fires the provided callback. 4. The callback applies the config change transaction and continues the rest of the rotation synchronously. The DisplayWindowController is sys-ui piece that serves as an interface between system-ui components and display-related wm logic. For now it just facilitates the rotation calculation, but in the future it will have more general utility for display logic like inset/bounds calculation. Bug: 124011688 Bug: 133381284 Test: Added some wmtests and coretests. Change-Id: If10695f44fa076725ba17746842f6fbd64da5d20