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

Commit 90fbb6a0 authored by Tiger's avatar Tiger
Browse files

Don't let exiting starting window control system bars 

When an activity (appA) starts another activity (appB) behind a starting
window (winS), the app window (winA) of A will lose the window focus.
And then mTopFullscreenOpaqueWindowState will control the system bars
while there is no focused window. WinS might become the controlling
window temporarily before it is removed. The controlling windows could
be:

winS --> winA --> winS (exiting) --> winA --> winB

If the requested visibilities of system bars between winS and winA are
different, system bars might look flickering.

This CL is to let winA keep controlling system bars until the app window
(winB) of appB becomes the focused window. The controlling windows with
the new logic will be:

winS --> winA --> winB

Fix: 322768312
Test: Cold-start `The Spectator` on a device with a pinned taskbar and
      set animator duration scale to animation off. See if taskbar
      flashes on the starting window.
Change-Id: Ic3081d97edf755a3bd2d6ec8703f6ca42bb39dab
parent 599156ec

services/core/java/com/android/server/wm/DisplayPolicy.java

+13 −2
Original line number Diff line number Diff line
@@ -47,6 +47,7 @@ import static android.view.WindowManager.LayoutParams.PRIVATE_FLAG_INTERCEPT_GLO 
import static android.view.WindowManager.LayoutParams.PRIVATE_FLAG_LAYOUT_SIZE_EXTENDED_BY_CUTOUT;

import static android.view.WindowManager.LayoutParams.PRIVATE_FLAG_TRUSTED_OVERLAY;

import static android.view.WindowManager.LayoutParams.PRIVATE_FLAG_UNRESTRICTED_GESTURE_EXCLUSION;

import static android.view.WindowManager.LayoutParams.TYPE_APPLICATION_STARTING;

import static android.view.WindowManager.LayoutParams.TYPE_BASE_APPLICATION;

import static android.view.WindowManager.LayoutParams.TYPE_NAVIGATION_BAR;

import static android.view.WindowManager.LayoutParams.TYPE_NAVIGATION_BAR_PANEL;
@@ -1533,9 +1534,19 @@ public class DisplayPolicy { 
        // Check the windows that overlap with system bars to determine system bars' appearance.

        if ((appWindow && attached == null && attrs.isFullscreen())

                || attrs.type == TYPE_VOICE_INTERACTION) {

            // Record the top-fullscreen-app-window which will be used to determine system UI



            // If this is the exiting starting window, don't let it control the system bars.

            // The app window behind it should be the controlling window instead. Reason: when an

            // activity starts another activity behind a starting window, the app window of the

            // first activity will lose the window focus. And then mTopFullscreenOpaqueWindowState

            // will control the system bars. The logic here is to let first app window keep

            // controlling system bars until the second app window is ready.

            final boolean exitingStartingWindow =

                    attrs.type == TYPE_APPLICATION_STARTING && win.mAnimatingExit;



            // Record the top-fullscreen-app-window which will be used to determine the system UI

            // controlling window.

            if (mTopFullscreenOpaqueWindowState == null) {

            if (mTopFullscreenOpaqueWindowState == null && !exitingStartingWindow) {

                mTopFullscreenOpaqueWindowState = win;

            }