Android P WMS--Introduction to WMS

1.WMS Overview

WMS is the other service of the system. Whether for application development or Framework development, it is the key knowledge. It has many responsibilities. There are mainly the following points:

Window Management
WMS is the manager of windows. It is responsible for the start, add and delete of windows. In addition, the size and level of windows are also managed by WMS. The core members of window management are DisplayContent, Windows Token and Windows State.

Window animation
When switching between windows, the use of window animation can be more dazzling. Window animation is the responsibility of the WMS animation subsystem. The manager of the animation subsystem is Windows Animator.

Transfer Station of Input System
Input Manager Service (IMS) processes touch events by touching windows. It will find the most suitable window to process touch feedback information. WMS is the manager of windows. Therefore, WMS "deserves" to be the transit station of input system.

Surface Management
Windows do not have the ability to draw, so each window needs a Surface to draw for itself. Assigning Surface to each window is done by WMS.

The responsibilities of WMS can be summarized as follows.

2.windowState

Windows State is window. Every window has a surface to draw. Windows itself can't draw.

Types of Window s

There are many Window s in Android system. Generally speaking, the Framework defines three types of windows.

System Window
What are the common Windows systems? For example, when the power of the mobile phone is low, there will be a Window indicating low power. When we input text, we will pop up the input method Window, as well as the search Window, the call display Window and the corresponding Window of Toast. It can be concluded that the system Windows is independent of our application program. For the application program, we should deal with it. It is theoretically impossible to create a system Window, because there is no permission, which only the system process has.

Application Window
The so-called application Window means that the Window corresponds to an activity. Therefore, to create an application Window, it must be completed in the activity. Later in this section, we will analyze the process of creating Windows corresponding to Activity.

Sub-Window
The so-called child Windows means that this Windows must have a parent form, such as PopWindow, Dialog belongs to the application Windows, which is quite special.

Each window type defines a corresponding type
The type range of the application type window is 1-99

Application Type Window

The type range of subwindows is 1000-1999

child window

The window type range of the system is more than 2000

Windows of the system

The type value of the system Window > the type value of the sub-window > the type value of the application type window. Generally speaking, according to the size of the type value, we can deduce that the system window is above the sub-window and the sub-window is above the application window.

3.z-order

The layered layout is a three-dimensional space. The horizontal direction of the mobile phone is regarded as the X-axis, the vertical direction as the Y-axis, and there is a virtual Z-axis vertical to the screen from inside to outside. All windows (Windows State) are arranged on the Z-axis in order, as shown below. The z-axis coordinate is z-order, and the bigger it is, the more ahead its windows state is.

3.1. mBaseLayer Primary Order Confirmation

@/frameworks/base/services/core/java/com/android/server/wm/WindowState.java
WindowState(WindowManagerService service, Session s, IWindow c, WindowToken token,
        WindowState parentWindow, int appOp, int seq, WindowManager.LayoutParams a,
        int viewVisibility, int ownerId, boolean ownerCanAddInternalSystemWindow,
        PowerManagerWrapper powerManagerWrapper) {
        ...
    if (mAttrs.type >= FIRST_SUB_WINDOW && mAttrs.type <= LAST_SUB_WINDOW) {
        // The multiplier here is to reserve space for multiple
        // windows in the same type layer.
        mBaseLayer = mPolicy.getWindowLayerLw(parentWindow    //mBaseLayer Primary Order
                * TYPE_LAYER_MULTIPLIER + TYPE_LAYER_OFFSET;  ////TYPE_LAYER_MULTIPLIER = 10000    TYPE_LAYER_OFFSET = 1000
        mSubLayer = mPolicy.getSubWindowLayerFromTypeLw(a.type);  //mSubLayer order
        mIsChildWindow = true;

        if (DEBUG_ADD_REMOVE) Slog.v(TAG, "Adding " + this + " to " + parentWindow);
        parentWindow.addChild(this, sWindowSubLayerComparator);

        mLayoutAttached = mAttrs.type !=
                WindowManager.LayoutParams.TYPE_APPLICATION_ATTACHED_DIALOG;
        mIsImWindow = parentWindow.mAttrs.type == TYPE_INPUT_METHOD
                || parentWindow.mAttrs.type == TYPE_INPUT_METHOD_DIALOG;
        mIsWallpaper = parentWindow.mAttrs.type == TYPE_WALLPAPER;
    } else {
        // The multiplier here is to reserve space for multiple
        // windows in the same type layer.
        mBaseLayer = mPolicy.getWindowLayerLw(this)
                * TYPE_LAYER_MULTIPLIER + TYPE_LAYER_OFFSET;
        mSubLayer = 0;
        mIsChildWindow = false;
        mLayoutAttached = false;
        mIsImWindow = mAttrs.type == TYPE_INPUT_METHOD
                || mAttrs.type == TYPE_INPUT_METHOD_DIALOG;
        mIsWallpaper = mAttrs.type == TYPE_WALLPAPER;
    }
...
}

mBaseLayer = window type * 10000 + 1000. The window type is determined as follows

default int getWindowLayerFromTypeLw(int type, boolean canAddInternalSystemWindow) {
    if (type >= FIRST_APPLICATION_WINDOW && type <= LAST_APPLICATION_WINDOW) {
        return APPLICATION_LAYER;
    }

    switch (type) {
        case TYPE_WALLPAPER:
            // wallpaper is at the bottom, though the window manager may move it.
            return  1;
        case TYPE_PRESENTATION:
        case TYPE_PRIVATE_PRESENTATION:
            return  APPLICATION_LAYER;
        case TYPE_DOCK_DIVIDER:
            return  APPLICATION_LAYER;
        case TYPE_QS_DIALOG:
            return  APPLICATION_LAYER;
        case TYPE_PHONE:
            return  3;
        case TYPE_SEARCH_BAR:
        case TYPE_VOICE_INTERACTION_STARTING:
            return  4;
        case TYPE_VOICE_INTERACTION:
            // voice interaction layer is almost immediately above apps.
            return  5;
        case TYPE_INPUT_CONSUMER:
            return  6;
        case TYPE_SYSTEM_DIALOG:
            return  7;
        case TYPE_TOAST:
            // toasts and the plugged-in battery thing
            return  8;
        case TYPE_PRIORITY_PHONE:
            // SIM errors and unlock.  Not sure if this really should be in a high layer.
            return  9;
        case TYPE_SYSTEM_ALERT:
            // like the ANR / app crashed dialogs
            return  canAddInternalSystemWindow ? 11 : 10;
        case TYPE_APPLICATION_OVERLAY:
            return  12;
        case TYPE_DREAM:
            // used for Dreams (screensavers with TYPE_DREAM windows)
            return  13;
        case TYPE_INPUT_METHOD:
            // on-screen keyboards and other such input method user interfaces go here.
            return  14;
        case TYPE_INPUT_METHOD_DIALOG:
            // on-screen keyboards and other such input method user interfaces go here.
            return  15;
        case TYPE_STATUS_BAR:
            return  17;
        case TYPE_STATUS_BAR_PANEL:
            return  18;
        case TYPE_STATUS_BAR_SUB_PANEL:
            return  19;
        case TYPE_KEYGUARD_DIALOG:
            return  20;
        case TYPE_VOLUME_OVERLAY:
            // the on-screen volume indicator and controller shown when the user
            // changes the device volume
            return  21;
        case TYPE_SYSTEM_OVERLAY:
            // the on-screen volume indicator and controller shown when the user
            // changes the device volume
            return  canAddInternalSystemWindow ? 22 : 11;
        case TYPE_NAVIGATION_BAR:
            // the navigation bar, if available, shows atop most things
            return  23;
        case TYPE_NAVIGATION_BAR_PANEL:
            // some panels (e.g. search) need to show on top of the navigation bar
            return  24;
        case TYPE_SCREENSHOT:
            // screenshot selection layer shouldn't go above system error, but it should cover
            // navigation bars at the very least.
            return  25;
        case TYPE_SYSTEM_ERROR:
            // system-level error dialogs
            return  canAddInternalSystemWindow ? 26 : 10;
        case TYPE_MAGNIFICATION_OVERLAY:
            // used to highlight the magnified portion of a display
            return  27;
        case TYPE_DISPLAY_OVERLAY:
            // used to simulate secondary display devices
            return  28;
        case TYPE_DRAG:
            // the drag layer: input for drag-and-drop is associated with this window,
            // which sits above all other focusable windows
            return  29;
        case TYPE_ACCESSIBILITY_OVERLAY:
            // overlay put by accessibility services to intercept user interaction
            return  30;
        case TYPE_SECURE_SYSTEM_OVERLAY:
            return  31;
        case TYPE_BOOT_PROGRESS:
            return  32;
        case TYPE_POINTER:
            // the (mouse) pointer layer
            return  33;
        default:
            Slog.e("WindowManager", "Unknown window type: " + type);
            return APPLICATION_LAYER;
    }
}

3.2. Confirmation of mSubLayer suborder

SubLayer (called suborder) is used to describe whether a window belongs to a child window of another window, or to determine the relative position between the child window and the parent window.

There are three sub-windows in an Activity: Windows State1, Windows State2, Windows State3, Windows State1, Windows State2 in front of Window A and Windows State3 behind Window A. Why can these brothers be sorted in this way? This is the function of mSubLayer. The larger the sub-order, the closer they are to other brothers'windows. Before, on the contrary, if it is negative, it is behind the parent Window, such as Windows State 3 in Window A. The suborder is determined by calling subWindows Type To Layer Lw according to the type of Window. SubWindows Type To Layer Lw is also called in the construction method of Windows.

public int subWindowTypeToLayerLw(int type) {
       switch (type) {
       case TYPE_APPLICATION_PANEL:
       case TYPE_APPLICATION_ATTACHED_DIALOG:
           return APPLICATION_PANEL_SUBLAYER;//The return value is 1
       case TYPE_APPLICATION_MEDIA:
           return APPLICATION_MEDIA_SUBLAYER;//The return value is -2  
       case TYPE_APPLICATION_MEDIA_OVERLAY:
           return APPLICATION_MEDIA_OVERLAY_SUBLAYER;//The return value is -1  
       case TYPE_APPLICATION_SUB_PANEL:
           return APPLICATION_SUB_PANEL_SUBLAYER;//The return value is 2 
       case TYPE_APPLICATION_ABOVE_SUB_PANEL:
           return APPLICATION_ABOVE_SUB_PANEL_SUBLAYER;//The return value is 3  
       }
       Log.e(TAG, "Unknown sub-window type: " + type);
       return 0;
   }

3.3. Adjustment of window Z order

When Windows State is created and added to an array maintained by WMS, you need to call assignLayers Locked (windows) of Windows Layers Controller to adjust Z-order.

//The parameter windows is the window list
final void assignLayersLocked(WindowList windows) {
       if (DEBUG_LAYERS) Slog.v(TAG_WM, "Assigning layers based on windows=" + windows,
               new RuntimeException("here").fillInStackTrace());

       clear();
       int curBaseLayer = 0;
       int curLayer = 0;
       boolean anyLayerChanged = false;
      //Traversing the list of windows, the Z-order values calculated by the Z-order formula above are stored in the variable mBaseLayer of Windows State
       //This loop means that when a window of the same type is encountered, the latter window is offset by 5 on the basis of the previous window.
       for (int i = 0, windowCount = windows.size(); i < windowCount; i++) {
           final WindowState w = windows.get(i);
           boolean layerChanged = false;

           int oldLayer = w.mLayer;
           if (w.mBaseLayer == curBaseLayer || w.mIsImWindow || (i > 0 && w.mIsWallpaper)) {
               curLayer += WINDOW_LAYER_MULTIPLIER;
           } else {
               curBaseLayer = curLayer = w.mBaseLayer;
           }
          // Update the mAnimLayer of the window, which is the level of the window when the animation is displayed
           assignAnimLayer(w, curLayer);

           // TODO: Preserved old behavior of code here but not sure comparing
           // oldLayer to mAnimLayer and mLayer makes sense...though the
           // worst case would be unintentionalp layer reassignment.
           if (w.mLayer != oldLayer || w.mWinAnimator.mAnimLayer != oldLayer) {
               layerChanged = true;
               anyLayerChanged = true;
           }

　　　　　// Record the highest display level of the current application window in mHighest Application Layer
           if (w.mAppToken != null) {
               mHighestApplicationLayer = Math.max(mHighestApplicationLayer,
                       w.mWinAnimator.mAnimLayer);
           }
        　 //  For related windows such as split screens, their display levels need to be processed again
           collectSpecialWindows(w);

           if (layerChanged) {
               w.scheduleAnimationIfDimming();
           }
       }

　　　　// Adjust the level of special windows
       adjustSpecialWindows();

       //TODO (multidisplay): Magnification is supported only for the default display.
       if (mService.mAccessibilityController != null && anyLayerChanged
               && windows.get(windows.size() - 1).getDisplayId() == Display.DEFAULT_DISPLAY) {
           mService.mAccessibilityController.onWindowLayersChangedLocked();
       }

       if (DEBUG_LAYERS) logDebugLayers(windows);
   }