Donate to e Foundation | Murena handsets with /e/OS | Own a part of Murena! Learn more

Skip to content
Commit fb61358b authored by Riddle Hsu's avatar Riddle Hsu
Browse files

Always use a DisplayArea for WindowingLayer

This fixes the case if FEATURE_WINDOWED_MAGNIFICATION is supported:
 Correct hierarchy
  Display 0
   > WindowedMagnification:0:31 (WindowingLayer)
   > HideDisplayCutout:32:35
   > Leaf:36:36
   > Overlays

 Wrong hierarchy after calling migrateToNewSurfaceControl
 (The DisplayArea 32~36 should not belong to 0~31)
  Display 0
   > WindowedMagnification:0:31 (WindowingLayer)
     >> HideDisplayCutout:32:35
     >> Leaf:36:36
   > Overlays

There are various assumptions that the real parent surface should be
used as the target of reparent except display. Such as onParentChanged
and animation leash management. So it might not be appropriate to be a
general override in WindowContainer.

To reduce confusing of WindowingLayer, this change makes the layer
name consistent with its purpose and window hierarchy. There will
be a real DisplayArea for WindowingLayer, so the exception case of
relationship between surface and container is gone.

Before:
 RootWrapper (DisplayContent#mSurfaceControl)
  > Display 1 (WindowingLayer)
    >> TaskDisplayArea
  > Overlays

After:
 Display 1 (DisplayContent#mSurfaceControl)
  > WindowingLayer
    >> TaskDisplayArea
  > Overlays

Bug: 326975721
Test: atest DisplayContentTests#testValidWindowingLayer
            DisplayAreaPolicyBuilderTest
Test: Kill systemui (which triggers setOrganizer ->
      sendDisplayAreaVanished -> migrateToNewSurfaceControl)
      and check surface hierarchy.

Change-Id: Id4c2723a67738827be81ffb6fd4f47cf3a094634
parent 96fd8a65
Loading
Loading
Loading
Loading
0% Loading or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment