Correct exit animation window retention logic.
The current logic in removeWindow will retain windows
for exit animation if mExiting is true or if isAnimating is true.
In the case that mExiting is false, but perhaps isAnimating is
true (because we are opening or resuming), we could also enter this
code path. This means that if an application removes its window
during an entrance animation, the window could be incorrectly retained
as if for an exit animation. This incorrectly retained window could be
eligible to receive WM focus, despite already having its input handle
being set, this would cause a null focus to be copied to the
InputManager leading to the ANR we observe in linked bug.
Bug: 26157153
Change-Id: Ib02964bcdfba665d7e7162cea8ed96315870d805
diff --git a/services/core/java/com/android/server/wm/WindowManagerService.java b/services/core/java/com/android/server/wm/WindowManagerService.java
index 6385caa..48bcb1f 100644
--- a/services/core/java/com/android/server/wm/WindowManagerService.java
+++ b/services/core/java/com/android/server/wm/WindowManagerService.java
@@ -2233,9 +2233,8 @@
// trigger its removal.
final boolean lastWinStartingNotAnimating = startingWindow && appToken!= null
&& appToken.allAppWindows.size() == 1 && !isAnimating;
- if (!lastWinStartingNotAnimating && (win.mExiting || isAnimating)) {
+ if (!lastWinStartingNotAnimating && win.mExiting) {
// The exit animation is running... wait for it!
- win.mExiting = true;
win.mRemoveOnExit = true;
win.setDisplayLayoutNeeded();
final boolean focusChanged = updateFocusedWindowLocked(