Donate to e Foundation | Murena handsets with /e/OS | Own a part of Murena! Learn more

Commit a6681166 authored by lumark's avatar lumark
Browse files

Fix app transition delayed cases

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
parent 3ba6ace8
Loading
Loading
Loading
Loading
+4 −1
Original line number Diff line number Diff line
@@ -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 */);
            }
+7 −0
Original line number Diff line number Diff line
@@ -2861,6 +2861,13 @@ class WindowState extends WindowContainer<WindowState> 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;