Commit 78e55425 authored Sep 10, 2019 by wilsonshih Committed by Wei Sheng Shih Sep 24, 2019

Check client hidden state before resetting draw state.

If there are more than activities switched to foreground very quickly,
imagine like: A->B->A, in previous fix, if we found the resumed activity
is hidden in server side, we will reset the drawing state. However, the
resumed activity may be currently visible at client side, and since the
previous transition may not have finished and we will clear the
AppWindowToken in clearChangeLeash, this AppWindowToken may never receive
onAnimationFinished callback, so the mClientHidden will stay in false.

Since server side doesn't require client side to relayout, the allDraw state
will remain in false, which will cause the second transition cannot start.
Therefore, even when resumed activity idled, the stopping activity cannot be
removed from processStoppingActivitiesLocked because isSelfAnimating remains
true.

Fix: 137898192
Bug: 127741025
Test: atest CtsWindowManagerDeviceTestCases:ActivityStarterTests
Test: Manual testing that b/134561008 didn't reproduce.

Change-Id: Ie76b33ec5f12591c3166612e69b49325d7276216

parent c50ac5df

services/core/java/com/android/server/wm/AppWindowToken.java

+14 −11

Original line number	Diff line number	Diff line
		@@ -548,6 +548,8 @@ class AppWindowToken extends WindowToken implements WindowManagerService.AppFree
		if (isHidden()) {
		waitingToShow = true;

		// If the client isn't hidden, we don't need to reset the drawing state.
		if (isClientHidden()) {
		// Let's reset the draw state in order to prevent the starting window to be
		// immediately dismissed when the app still has the surface.
		forAllWindows(w -> {
		@@ -561,6 +563,7 @@ class AppWindowToken extends WindowToken implements WindowManagerService.AppFree
		}, true /* traverseTopToBottom */);
		}
		}
		}

		// In the case where we are making an app visible but holding off for a transition,
		// we still need to tell the client to make its windows visible so they get drawn.