From a6681166982e2f40db29e67e93500e093617803b Mon Sep 17 00:00:00 2001 From: lumark Date: Fri, 12 Apr 2019 01:47:54 +0800 Subject: [PATCH] Fix app transition delayed cases MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit When same app repeats to switch resume & stop quickly, it will have the timing that update app allDrawn state as true but quickly set as false due to activity stopped. If the next open transition didn’t get allDrawn in time by WindowSurfacePlacer#performTravesal, it will be delayed since allDrawn state is obsoleted. So when WindowState#mDestroying is in true to false state, it's need to check if the window belongs current waiting transition and then call WindowSurfacePlacer#performTravesal to update allDrawn state in time. Also fix another delayed case during launching app with trampoline activity in External display with freeform windowing mode, due to process closing transition for finishing trampoline activity that broken by the next acitivity already resumed, so the open transition can’t get drawn state and then got transition timeout. In finishCurrentAcitvityLocked, addd a check if the finishing activity is floating task, if so then we can just destroy it without waiting the next activity resume. Fix: 123433575 Test: manual - case 1) Repeats launch Contacts app and pressing home key 100 times without met app transition 5 secs delay. - case 2) Enabling Simulated display & forcing desktop mode, launch Files or Calendar app on external display without seeing app transition 5 secs delay. Change-Id: I58e3787974535b2d5b5690f188ace94026fa2687 --- .../core/java/com/android/server/wm/ActivityStack.java | 5 ++++- services/core/java/com/android/server/wm/WindowState.java | 7 +++++++ 2 files changed, 11 insertions(+), 1 deletion(-) diff --git a/services/core/java/com/android/server/wm/ActivityStack.java b/services/core/java/com/android/server/wm/ActivityStack.java index 419f5be5bbc80..0debaadf115d8 100644 --- a/services/core/java/com/android/server/wm/ActivityStack.java +++ b/services/core/java/com/android/server/wm/ActivityStack.java @@ -4089,11 +4089,14 @@ class ActivityStack extends ConfigurationContainer { // The activity that we are finishing may be over the lock screen. In this case, we do not // want to consider activities that cannot be shown on the lock screen as running and should // proceed with finishing the activity if there is no valid next top running activity. + // Note that if this finishing activity is floating task, we don't need to wait the + // next activity resume and can destroy it directly. final ActivityDisplay display = getDisplay(); final ActivityRecord next = display.topRunningActivity(true /* considerKeyguardState */); + final boolean isFloating = r.getConfiguration().windowConfiguration.tasksAreFloating(); if (mode == FINISH_AFTER_VISIBLE && (r.visible || r.nowVisible) - && next != null && !next.nowVisible) { + && next != null && !next.nowVisible && !isFloating) { if (!mStackSupervisor.mStoppingActivities.contains(r)) { addToStopping(r, false /* scheduleIdle */, false /* idleDelayed */); } diff --git a/services/core/java/com/android/server/wm/WindowState.java b/services/core/java/com/android/server/wm/WindowState.java index 08ade37c995ca..63d3609a08fb5 100644 --- a/services/core/java/com/android/server/wm/WindowState.java +++ b/services/core/java/com/android/server/wm/WindowState.java @@ -2861,6 +2861,13 @@ class WindowState extends WindowContainer implements WindowManagerP } mDestroying = false; destroyedSomething = true; + + // Since mDestroying will affect AppWindowToken#allDrawn, we need to perform another + // traversal in case we are waiting on this window to start the transition. + if (getDisplayContent().mAppTransition.isTransitionSet() + && getDisplayContent().mOpeningApps.contains(mAppToken)) { + mWmService.mWindowPlacerLocked.requestTraversal(); + } } return destroyedSomething;