Give SystemUI a chance to participate in display rotation
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
Loading
Please register or sign in to comment