Reparent PiP overlay under task as soon as possible
For enter PiP animations started from Launcher, we send the signal to WMShell to reparent the overlay under task as soon as possible. This avoids flicker issue caused by race condition of cleaning up the transition leash before the reparenting was done, which made the issue of overlay being not attached to anything for few frames. Bug: 281711939 Test: winscope trace from comment#28, leash follows task Change-Id: I46764c925185c316b3aa309e3cb9f1a0a89948d4
This commit is contained in:
@@ -447,7 +447,7 @@ public class PipTaskOrganizer implements ShellTaskOrganizer.TaskListener,
|
||||
}
|
||||
|
||||
/**
|
||||
* Callback when launcher finishes swipe-pip-to-home operation.
|
||||
* Callback when launcher finishes preparation of swipe-pip-to-home operation.
|
||||
* Expect {@link #onTaskAppeared(ActivityManager.RunningTaskInfo, SurfaceControl)} afterwards.
|
||||
*/
|
||||
public void stopSwipePipToHome(int taskId, ComponentName componentName, Rect destinationBounds,
|
||||
|
||||
@@ -953,7 +953,8 @@ public class PipTransition extends PipTransitionController {
|
||||
if (swipePipToHomeOverlay != null) {
|
||||
// Launcher fade in the overlay on top of the fullscreen Task. It is possible we
|
||||
// reparent the PIP activity to a new PIP task (in case there are other activities
|
||||
// in the original Task), so we should also reparent the overlay to the PIP task.
|
||||
// in the original Task, in other words multi-activity apps), so we should also reparent
|
||||
// the overlay to the final PIP task.
|
||||
startTransaction.reparent(swipePipToHomeOverlay, leash)
|
||||
.setLayer(swipePipToHomeOverlay, Integer.MAX_VALUE);
|
||||
mPipOrganizer.mSwipePipToHomeOverlay = null;
|
||||
|
||||
Reference in New Issue
Block a user