Immediately report drawing
No need to wait on the next relayout - this can only delay the
transition. Makes hot launches a lot more consistent.
However, this made it too fast! We then hit a race condition when
the app transition was already starting but no other layout was
done yet. When another layout was executed we noticed that we need
to report resized for the starting window, clearing it's drawn
state, which set startingDisplayed=false, which jumped the app
window animation to the end.
To fix this, make sure not to report another resized immediately
after the initial layout, as the client already knows the latest
(because it calls relayout at some point before it starts drawing).
Also fix "animating" async systrace for better analysis.
Test: Open/close size-mismatching task snapshot 100 times, ensure
no animation skipped.
Test: Look at app transition logs, ensure more consistent.
Test: Overall system sanity testing (open a couple of apps/dialogs
etc).
Bug: 32668632
Change-Id: Id795cd6a84f22e6a619089cb9554fc5033477ad2
diff --git a/services/core/java/com/android/server/wm/DisplayContent.java b/services/core/java/com/android/server/wm/DisplayContent.java
index 257f285..bbf7d9f 100644
--- a/services/core/java/com/android/server/wm/DisplayContent.java
+++ b/services/core/java/com/android/server/wm/DisplayContent.java
@@ -520,9 +520,16 @@
}
w.mLayoutNeeded = false;
w.prelayout();
+ final boolean firstLayout = !w.isLaidOut();
mService.mPolicy.layoutWindowLw(w, null);
w.mLayoutSeq = mService.mLayoutSeq;
+ // If this is the first layout, we need to initialize the last inset values as
+ // otherwise we'd immediately cause an unnecessary resize.
+ if (firstLayout) {
+ w.updateLastInsetValues();
+ }
+
// Window frames may have changed. Update dim layer with the new bounds.
final Task task = w.getTask();
if (task != null) {