Associate freezing display with a target display id.
Currently, start/stop freezing is always associated with the default
display. As a result, any animations that result from freezing will
occur on the default display. One situation this happens is during a
configuration change, where a screen rotation can be triggered. In
the case of adding a secondary display, a configuration change is
always triggered to apply the override configuration at the display
level. As a result, the default display exhibits a rotation animation
upon unfreezing during surface placement.
This changelist passes down the display id associated with the action
so that the animations may be applied to the right display. In the
scenario described perviously, the secondary display id is passed down
and therefore is the target of the rotation animation during
unfreezing.
Fixes: 35486733
Test: go/wm-smoke
Test: cts-tradefed run singleCommand cts-dev --module CtsViewTestCases --test android.view.cts.SurfaceViewSyncTest#testSmallRect
Change-Id: I87e56f5901934327fc50b3c7e543b5e36b8ff34f
diff --git a/services/core/java/com/android/server/wm/AppWindowToken.java b/services/core/java/com/android/server/wm/AppWindowToken.java
index 525e0ff..71ecaf6 100644
--- a/services/core/java/com/android/server/wm/AppWindowToken.java
+++ b/services/core/java/com/android/server/wm/AppWindowToken.java
@@ -1107,7 +1107,7 @@
mAppAnimator.lastFreezeDuration = 0;
mService.mAppsFreezingScreen++;
if (mService.mAppsFreezingScreen == 1) {
- mService.startFreezingDisplayLocked(false, 0, 0);
+ mService.startFreezingDisplayLocked(false, 0, 0, getDisplayContent());
mService.mH.removeMessages(H.APP_FREEZE_TIMEOUT);
mService.mH.sendEmptyMessageDelayed(H.APP_FREEZE_TIMEOUT, 2000);
}