Related concepts

Before introducing WMS, let’s cover a few related concepts;

WMS exists in the system_server system service process, view exists in the app process, all the windows are eventually managed through the wms, in order to facilitate the management of the app and the wms added between the WindowManager, used in the management interface between the application and the wms, management of the window order, messages and so on.

Activity and Window Related Concepts

•  Activity is only responsible for the life cycle and event handling;
•  Window controls only the view;
• 
  An Activity contains a Window. If an Activity does not have a Window, it is equivalent to a Service;
• 
  AMS unifies the scheduling of Activity across all applications;
• 
  WMS controls the display and hiding of all Window and where they are to be displayed;

Window

“Window” indicates that it is related to window, “Window” is an abstract concept, from the user’s point of view, it is an “interface”; from the SurfaceFlinger’s point of view, it is a Layer, which carries data and properties related to the interface; from the WMS point of view, it is a WindowState, which is used to manage the state related to the interface. From the perspective of SurfaceFlinger, it is a Layer, which carries data and properties related to the interface; from the perspective of WMS, it is a WindowState, which is used to manage the state related to the interface; the process of adding a Window is the process of allocating a piece of Surface;

• 
  represents the concept of a Window, which is the direct manager of all Views, any view is rendered through Window (click event is done by Window->DecorView->View; Activity’s setContentView is done through Window at the bottom);.
• 
  Window is an abstract class whose concrete and only implementation is PhoneWindow;
• 
  To create a Window you need to create it with the WindowManager.
• 
  WindowManager is the entry point for external access to the Window.
• 
  The Window implementation is located in the WindowManagerService.
• WindowManager 和 WindowManagerService ;
• 
  Abstract base class defining window style and behavior, used as a top-level view added to WindowManager, whose implementation class is PhoneWindow
• 
  Each Window needs to be assigned a Type (Application Window, Sub-Window, System Window); the window corresponding to Activity is an Application Window; PopupWindow, ContextMenu, OptionMenu are commonly used Sub-Windows; Toast and System Warning Reminder Boxes (e.g., ANR) are System Window, and the Hoverboxes of many applications are also System Window Types; and the Hoverboxes of many applications are also System Window Types; and the Hoverboxes of many applications are System Window Types. Hoverbox also belongs to the system window type;

Window is weakened on Android, mainly View;

WindowManager

Used as a management interface between the application and the window to manage window order, messages, etc.;

WindowManagerService

Abbreviated as WMS, WindowManagerService manages the creation, updating and deletion of windows, display order, etc. It is the real implementation class of the management interface WindowManager. It runs in the system_server process as a server, and the client (application program) interacts with it through IPC calls;

•  Z-ordered maintenance functions;
•  Input method management;
•  AddWindew/RemoveWindow;
•  Layout;
•  Token Management AppToken;
•  Active window management (FocusWindow);
•  Activity Application Management (FocusApp);
•  Transition animation;
•  System message collection thread;
•  System message distribution thread;

WMS, WindowManager, Window a relationship between the three; Window is the App side of the concept used to manage the View, it is an abstract concept, we really see the View rather than Window, View ultimately, if you want to display, you need to hand over to the WMS, the WMS will hand over to View SurfaceFlinger, and SurfaceFlinger will eventually hand over to OpenGL for real drawing, and then display to the screen after drawing;

Token

The main Token mentioned here is the WindowToken, a special kind of Binder token that wms uses to uniquely identify a window in the system;

 The type of the Window

 Window Type;

•  Application window;
•  Sub-Window;
•  System window;

mTokenMap

Save all display tokens “of type WindowToken” A window must belong to a certain display token;

mAppTokens, holds all display tokens belonging to an Activity (AppWindowToken, a subclass of WindowToken). mAppTokens list is ordered, and it is consistent with the order of the mHistory list in AMS, reflecting the order of Activity in the system;

mExitingTokens, which holds the display tokens that are in the process of exiting, etc;

WindowToken is used to represent a set of Window;

mWindowMap

Save all the state information “Type as WindowState”;

mPendingRemove, holds windows whose exit animation has finished playing and is about to be removed;

mLosingFocus, saves windows that have lost their input focus;

In the DisplayContent, there is also a list of windows that stores the windows displayed in this DisplayContent, and it is ordered. The position of a window in this list determines its Z-order when it is finally displayed;

mSessions

Holds all clients that want to seek window management services from WMS. Note that session is process-unique; the app process communicates with the session object by creating a session proxy object, which in turn establishes a connection to WMS;

WindowState

On the Client side with Window to represent, this Window to the WMS side of a different way of representation, is WindowState; similar to Activity in the App side is Activity, in the AMS side is ActivityRecord;

AppTransition

 Window animation for App startup;

 Startup process

WMS is also started in the startOtherService method of the run call of the SystemServer;

private void startOtherServices(@NonNull TimingsTraceAndSlog t) {

    
    wm = WindowManagerService.main(context, inputManager, !mFirstBoot, mOnlyCore,
            new PhoneWindowManager(), mActivityManagerService.mActivityTaskManager);
    ServiceManager.addService(Context.WINDOW_SERVICE, wm, /* allowIsolated= */ false,
        DUMP_FLAG_PRIORITY_CRITICAL | DUMP_FLAG_PROTO);
}

The static main method of WindowManagerService is called directly;

public static WindowManagerService main(final Context context, final InputManagerService im,
        final boolean showBootMsgs, final boolean onlyCore, WindowManagerPolicy policy,
        ActivityTaskManagerService atm, DisplayWindowSettingsProvider
        displayWindowSettingsProvider, Supplier<SurfaceControl.Transaction> transactionFactory,
        Supplier<Surface> surfaceFactory,
        Function<SurfaceSession, SurfaceControl.Builder> surfaceControlFactory) {
    DisplayThread.getHandler().runWithScissors(() ->
            sInstance = new WindowManagerService(context, im, showBootMsgs, onlyCore, policy,
                    atm, displayWindowSettingsProvider, transactionFactory, surfaceFactory,
                    surfaceControlFactory), 0);
    return sInstance;
}

It’s important to note that WMS is initialized in a separate thread, DisplayThread, and not in the main thread of the SystemServer; let’s look at what this DisplayhThread is first

public final class DisplayThread extends ServiceThread {}

public class ServiceThread extends HandlerThread {}

HandlerThread is essentially a HandlerThread, HandlerThread we have dealt with in the previous Handler, the main thing here is to get the Handler and then call its runWithScissors method, let’s take a look at the runWithScissors method;

public final boolean runWithScissors(@NonNull Runnable r, long timeout) {
    if (r == null) {
        throw new IllegalArgumentException("runnable must not be null");
    }
    if (timeout < 0) {
        throw new IllegalArgumentException("timeout must be non-negative");
    }

    if (Looper.myLooper() == mLooper) {
        r.run();
        return true;
    }

    BlockingRunnable br = new BlockingRunnable(r);
    return br.postAndWait(this, timeout);
}

A BlockingRunnable is used here, which means that blocking is done here, in handler.post, so that the message being posted executes before continuing down the line;

DisplayThread.getHandler().runWithScissors(new Runnable() {
    @Override
    public void run() {
        sInstance = new WindowManagerService(context, im, showBootMsgs, onlyCore, policy, atm, displayWindowSettingsProvider, transactionFactory, surfaceFactory, surfaceControlFactory)
    }
}, 0);
return sInstance;

That is to say, we have to wait until the WindowManagerService is created before we can move on and return sInstance;

Let’s take a look at what the new WindowManagerService does.

private WindowManagerService(Context context, InputManagerService inputManager,
        boolean showBootMsgs, boolean onlyCore, WindowManagerPolicy policy,
        ActivityTaskManagerService atm, DisplayWindowSettingsProvider
        displayWindowSettingsProvider, Supplier<SurfaceControl.Transaction> transactionFactory,
        Supplier<Surface> surfaceFactory,
        Function<SurfaceSession, SurfaceControl.Builder> surfaceControlFactory) {
    
    
    mAnimator = new WindowAnimator(this);

    mActivityManager = ActivityManager.getService();
}

Initializes some services that need to communicate with the WMS; after the WMS is created, a binding is made to the AMS;

wm = WindowManagerService.main(context, inputManager, !mFirstBoot, mOnlyCore,
        new PhoneWindowManager(), mActivityManagerService.mActivityTaskManager);
ServiceManager.addService(Context.WINDOW_SERVICE, wm, /* allowIsolated= */ false,
        DUMP_FLAG_PRIORITY_CRITICAL | DUMP_FLAG_PROTO);

mActivityManagerService.setWindowManager(wm);

After binding, the ready logic of wms is called;

wm.onInitReady();

try {
    wm.displayReady();
} catch (Throwable e) {
    reportWtf("making display ready", e);
}


try {
    wm.systemReady();
} catch (Throwable e) {
    reportWtf("making Window Manager Service ready", e);
}

 To summarize, here are two main points:

1. 
   The startup of WMS mainly involves three threads: system_server, android.display, android.ui; among them, WMS.H.handleMessage runs in android.display thread;
2. 
   There are three key steps in WMS: creating WMS objects, initializing display information, and handling systemready notifications.

 Window Type

Application Window

Includes all windows created by the application itself, as well as windows that the system is responsible for displaying before the application is up, with a hierarchy ranging from 1 to 99;

• 
  FIRST_APPLICATION_WINDOW=1; first application window
• 
  TYPE_BASE_APPLICATION=1; base window for all program windows, other application windows are displayed on it
• 
  TYPE_APPLICATION=2; all Activity’s windows, can only be used with Activity in the current APP
• 
  TYPE_APPLICATION_STARTING=3; the window before the target application window was started
• 
  LAST_APPLICATION_WINDOW=99; last application window

Application customized dialog box, or input method window, the child window must be dependent on some application window (set the same token), the hierarchy range is 1000~1999;

• 
  FIRST_SUB_WINDOW=1000; first sub-window
• 
  TYPE_APPLICATION_PANEL=FIRST_SUB_WINDOW; panel window, displayed on the upper level of the host window, can only be used with the Activity in the current app
• 
  TYPE_APPLICATION_MEDIA=FIRST_SUB_WINDOW+1; media window (e.g., video), displayed below the host window
• 
  TYPE_APPLICATION_SUB_PANEL=FIRST_SUB_WINDOW+2; sub-panel of the application window, can only be used in conjunction with Activity in the current APP (PopupWindow is this Type by default)
• 
  TYPE_APPLICATION_ATTACHED_DIALOG=FIRST_SUB_WINDOW+3; Dialog window, can only be used with Activity in the current APP.
• TYPE_APPLICATION_MEDIA_OVERLAY=FIRST_SUB_WINDOW+4；TYPE_APPLICATION_MEDIA，TYPE_APPLICATION_MEDIA
• 
  LAST_SUB_WINDOW=1999; last sub window

 system window

System design, not dependent on any application window, such as: Status Bar, Navigation Bar, Wallpaper, Caller ID window, KeyGuard, Toast, Volume Adjustment window, Mouse Cursor and so on, the tier range is 2000~2999;

• 
  FIRST_SYSTEM_WINDOW=2000; system window, not application creation
• 
  TYPE_STATUS_BAR; status bar, there can only be one status bar, located at the top of the screen, all other windows are located below it
• 
  TYPE_SEARCH_BAR; search bar, there can only be one search bar, located at the top of the screen
• 
  TYPE_PHONE; phone window, which is used for phone interactions (especially inbound calls), placed on top of all applications, below the status bar, belongs to the hover window (and for an Activity, if you press the HOME key, you will not see the desktop icon exception)
• 
  TYPE_SYSTEM_ALERT; system alert window, appears above the application window, belongs to the hover window, but will be disabled.
• 
  TYPE_TOAST; information window, used to display Toast, not a part of the Hover Window, but has the function of the Hover Window
• 
  TYPE_SYSTEM_OVERLAY; the top level window of the system, displayed above everything else, this window can not get the focus of the input, otherwise it affects the lock screen
• 
  LAST_SYSTEM_WINDOW=2999; last system window

 Well, that’s it for today’s WMS!