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

Commit 838c2451 authored by Jorim Jaggi's avatar Jorim Jaggi
Browse files

Fix transition between two occluding activities

This fixes an issue when starting an activity that occldues
Keyguard with the window flag from an activity that is already
occluding Keyguard. Normally we wait until the transition starts
until the next activity had a chance to set its layout flag
(FLAG_SHOW_WHEN_LOCKED) with the UnknownVisibilityController.

Now, since setAppVisibility(false) was called after immediately
starting the activity, we removed the activity immediately from
the UnknownVisibilityController waiting list and then unoccluded
Keyguard.

We fix this by only adding an activity to the unknown visibility
list if it's a not a noDisplay activity as it will never add
a window in this case, so a relayout will never happen.

This regressed from I745e985766a1af97203e1d22b6443dabdd0c0363
because calling setVisible(true) was setting the token's visible
to true. Then, setVisible(false) was NOT ignored anymore.
Previously it was just ignored because the app wasn't made visible
yet from WM perspective.

Test: go/wm-smoke
Test: android.server.cts.KeyguardTransitionTests#testNewActivityDuringOccluded
Test: Launch camera from unlocked Keyguard by swiping from the
icon with animation transition scale set to 0.5. (regression test)

Change-Id: Idc2a5523f4653ae9788ba145c2d980343ae459f4
Fixes: 65061212
Bug: 37677242
parent bd54bcbc
Loading
Loading
Loading
Loading
+6 −1
Original line number Diff line number Diff line
@@ -1521,8 +1521,13 @@ final class ActivityRecord extends ConfigurationContainer implements AppWindowCo
    }

    void notifyUnknownVisibilityLaunched() {

        // No display activities never add a window, so there is no point in waiting them for
        // relayout.
        if (!noDisplay) {
            mWindowContainerController.notifyUnknownVisibilityLaunched();
        }
    }

    /**
     * @return true if the input activity should be made visible, ignoring any effect Keyguard
+4 −3
Original line number Diff line number Diff line
@@ -1268,6 +1268,10 @@ public class ActivityStackSupervisor extends ConfigurationContainer implements D

            r.app = app;

            if (mKeyguardController.isKeyguardLocked()) {
                r.notifyUnknownVisibilityLaunched();
            }

            // Have the window manager re-evaluate the orientation of the screen based on the new
            // activity order.  Note that as a result of this, it can call back into the activity
            // manager with a new orientation.  We don't care about that, because the activity is
@@ -1294,9 +1298,6 @@ public class ActivityStackSupervisor extends ConfigurationContainer implements D
                r.setVisibility(true);
            }

            if (mKeyguardController.isKeyguardLocked()) {
                r.notifyUnknownVisibilityLaunched();
            }
            final int applicationInfoUid =
                    (r.info.applicationInfo != null) ? r.info.applicationInfo.uid : -1;
            if ((r.userId != app.userId) || (r.appInfo.uid != applicationInfoUid)) {
+0 −1
Original line number Diff line number Diff line
@@ -365,7 +365,6 @@ public class AppWindowContainerController
                // Now that the app is going invisible, we can remove it. It will be restarted
                // if made visible again.
                wtoken.removeDeadWindows();
                mService.mUnknownAppVisibilityController.appRemovedOrHidden(wtoken);
            } else {
                if (!mService.mAppTransition.isTransitionSet()
                        && mService.mAppTransition.isReady()) {