An analysis of Android windows

<span id="Label3"></p>first, the concept of windows in the development process, we often encounter, a variety of window-related classes, or METHODS. But what exactly is a window in Android's frame design? What is the relationship between Windows and the window class in the Android Framework? Take the phone QQ main interface as an example, as shown above, the status bar is a window, the main interface of Mobile QQ is a window, and the pop-up Popupwindow is also a window, we often use the Toast is also a window. These are windows like dialog,contextmenu, and Optionmenu and so On. What are the relationships between these windows and the window class, or is the same concept described by the window with the Windows class? In fact, the concept of the window, from a different point of view, its meaning is not the Same. We know that Windowmanagerservice (hereafter referred to as WmS) manages all windows. But for wms, a window is actually a View class, not the window class. The WmS is responsible for managing the z-order of these view, displaying the area, and distributing the messages to the corresponding VIEW. The view itself does not receive messages directly from the WmS, but rather by implementing the VIEWROOTIMPL.W class of the Iwindow interface, the following are the relationships of these classes: so here the window is divided into two layers: (1) in the WMS eye, The window is the view that can be displayed for Display. For wms, the so-called window is a View that is added through Windowmanagerglobal.addview (); (2) the window class is an abstraction for the interaction of windows, that is, for wms, all user messages are given directly to view/ ViewGroup to deal With. The window class removes some of the interaction from the View/viewgroup and defines the behavior of some windows, such as the menu, and the processing system buttons such as "Home", "back" and so On. thus, window describes the Windows only on the basis of a common window, and then abstracted a layer, to conform to a certain standard window unified a bit. The window described by Windows should be a subset of the Universal WINDOW. For example, Popupwindow is a window, but analyzing its source code lets you know that the class does not create any window Objects. Dialog, by Policymanager.makenewwindow (mcontext), creates a Window object to manage the Windows. When a Dialog is displayed, we can passAfter pressing back to dismiss it, but Popupwindow not, need to deal with their own. second, the window type to add a window is done by Windowmanagerglobal.addview (), analysis of the parameters of the AddView method, there are three parameters are essential, view, params, and Display. Display generally takes the Mdisplay in Windowmnagerimpl directly, indicating the device to be Output. View naturally represents the view to be displayed, and the params is windowmanager.layoutparams, which describes the window properties of the view, one of the important parameter types that describes the type of WINDOW. public void AddView (view view, viewgroup.layoutparams params, display display, Window parentwindow) {if (view = = Null) { Throw new IllegalArgumentException ("view must not is null"); } if (display = = Null) {throw new IllegalArgumentException ("display must not is null");} if (! ( params instanceof Windowmanager.layoutparams) {throw new illegalargumentexception ("params must be Windowmanager.layoutparams "); } ..... } Analysis WindowManager for the description of type assignable types, there are three types of Windows defined in the Framework: (1) application window activity corresponding window is the application window, all Activity default window type is Type_base _ap Plication. The default build method for WindowManager Layoutparams is implemented, and you can see that the default type is Type_ Application. The Dialog window type is type_application, and many Dialog subclasses, modifying the window like, like ContextMenu, are essentially used Dialog is implemented, but before the window is added, the type is modified and assigned a value of Type_ application_ attached_ Dialog. From this we can see that the WmS does not distinguish the application window from the Sub-window so clearly. Public layoutparams () {super (layoutparams.match_parent, layoutparams.match_parent); type = type_application; format = pixelformat.opaque;} (2) child window refers to the window must have a parent window, the parent window can be an app type window, can be any other type of WINDOW. For example, the front hand q interface, Click on the top right button to display a popupwindow, it is a sub-window, its type is generally type_ application_panel. Since it is called a child window, its relationship to the parent window is relatively easy to understand. B is a child window, and when a is not visible, B is also invisible. If a is invisible, adding b,b is not visible until a is visible, and B follows Together. (3) The System Window System window is different from the application window and does not need to correspond to Activity. Unlike child windows, there is no need to have a parent window. Generally speaking, the system window should be created by the system, such as the exception occurred, the ANR prompt box, such as the system status bar, screensavers and so On. however, The Framework defines some of the system windows that can be created, such as Type_toast,type _input_ method,type _wallpapter, and so On. Token means that we are not unfamiliar with the word token, which is often encountered during the development process, such as the exception of bad Token. What does token represent in the Android framework? Analyzing the source code, we find that most token objects represent a ibinder object. Mention ibinder, everyone is not unfamiliar, is the IPC communication mechanism of ANDROID. In the process of creating the window, the IPC communication involved consists of two aspects, one is the object of the VIEWROOTIMPL.W class that the WMS uses to communicate with the Application's process, and the other is the object that points to a activityrecord, which should naturally be used by the WMS For the Communication. We combed through the definition of tokens in the following places, respectively, about what tokens represent here. Analyze the View's atThe assignment of the Tachinfo. Viewrootimpl in the build method, Initializes a attachinfo instance, assigns its Session, and the W class object to Attachinfo. As you can see from the analysis, Mwindowtoken in attachinfo, and Mwindow are all points to Mwindow (class W instances) in Viewrootimpl. When a View attach to the window, Viewrootimpl executes the performtraversals, and if found to be the first call, passes its own mattachinfo to the root View (via dispatchattachedtowindow), Tell the View tree is now attch to Window, it can be displayed immediately. Root View (typically Viewgroup) passes this information to each sub-view in the view tree, so that each View's Mattachinfo is assigned the mattachinfo of Viewrootimp. The type and tokenwindowmanager.layoutparams in Windowmanager.layoutparams are used to describe the properties of a window, which is eventually passed to the WmS when the window is Added. And the WmS will be stored in the WindowState mattrs. Layoutparams has a lot of parameters, but the parameters related to window creation, The most important thing is type and token, here we can know by analyzing WmS's addwindow code: (1) The window type must be within the specified legal range, that is, the application window, A child window, one of the system windows, otherwise the check will fail; (2) if the system requires permission checks the following types do not require special claims Permissions: type_toast, type_dream, type_input_method, type_wallpaper, type_private_presentation, type_voice_interaction, Type_ Accessibility_ Overlay the following types are required to declare usage rights: android.permission.SYSTEM_ALERT_WINDOW_TYPE_PHONE, type_priority_phone, type_system_alert, Type_system_erroR, Type_system_overlay Other system windows, need to declare permissions: android.permission.INTERNAL_ system window (3) If it is an application, it is retrieved by token Windowtoken , must not be empty, but also the activity of the mapptoken, while the corresponding activity must not be Finish. Before analyzing the activation process of activity we know that during the startup process, the activity will first add a appwindowtoken to the Mtokenmap through the WmS's addapptoken (), where key is used IApplication Token Token. The Mtoken in activity, and the Mapptoken in the activity corresponding to phonewindow, is the token from AmS (the Attach method of activity is shown in the code). (4) if it is a subwindow, it will go through the Attrs.token to find its parent window, and if its parent window is not found, an exception will be thrown. Or an exception is thrown if the type of the parent window found is still a child window Type. The process of finding the parent window here is to take the Attrs.token to Mwindowmap to find the corresponding WindowState, and the key in Mwindowmap is IWINDOW. so, thus, to create a child window type, token must be assigned a value of the W class object in the Viewrootimpl of its parent window MWINDOW. (5) if it is the following system window, Type_input_ method,type_voice_interaction,type_wallpaper,type_dream,type_accessibility_overlay, Token cannot be empty, and the type of Windowtoken retrieved by token cannot be the corresponding type of its own. (6) if it is another system window, the token in the attrs will be cleared, no token is Required. Therefore other types of system windows, token in Layoutparams can be Empty. (7) after checking, If you need to create a new windowtoken, the Attrs.token will be key,add to mtokenmap. （8) after WindowState is created, it will take Iwindow as key (corresponding to the VIEWROOTIMPL.W class object in the application process mwindow, important thing to emphasize many times!! , added to Mwindowmap. thus, we want to successfully add a window, for the type and token assignment is required, otherwise do not say whether the correct display, the creation failed directly. How is the type and token assigned? Most directly, it is in the call Windowmanagerimpl of the AddView method, the value can be assigned Well. however, analyzing the display of some of the windows provided by the FrameWork, such as Dialog, does not see the token assignment before calling ADDVIEW. Its window type is the application window, according to the previous description of the check, token must not be null, but also must be the Activity of the mapptoken, otherwise create Failed. Here we analyze what to do if the token is not assigned a value, and what will be done with the call to Addview. The code will go back to Windowmanagerimpl and Start. The parent window here is not necessarily the true parent window, it is possible to describe a Window's Phonewindow object itself. It is possible Phonewindow a, need to add a window, here ParentWindow may be the A object itself. Here Windowmanagerimpl in the mparentwindow, exactly what is represented, with the creation of Windowmanagerimpl. For example, the analysis of Activity add window: here again, add a window, the Windowmanager.layout token of some of the assignment situation: (1) whether it is an application window, or a child window, and part of the system window, token must be assigned Value. otherwise, Creating the window throws an Exception. For the application window, token must be an Activity Mtoken. For a child window, token must be the Iwindow object of its parent window. For some system windows, the type of Windowtoken that token retrieves can no longer be of its own type. (2) You can assign tokens directly before calling Windowmanagerimpl's AddView to create a window. (3) If you call Windowmanagerimpl's AddView before, The token is not assigned a good Value. There's going to be someDefault logic to guarantee token legitimacy: A: Check that there is no default token set, if any, and the parent window is null, directly take the default token of the Setting. There is no case for setting up tokens in this way. B: If a parent window is set, the parent Window's Adjustlayoutparamsforsubwindow is called to check Tokens. For child window types, The parent Window's Iwindow object is assigned to Token. For the application window, or the system window, take the Mapptoken of the parent window Directly. (the parent window is a window object whose instance is Phonewindow.) ) three, window creation and removal before the creation and removal of the analysis window, Let's briefly introduce the Android GUI system, which contains the Following: (1) windows and graphics System-window and View Manager system (2) display compositing system- Surface flinger (3) User output System-inputmanager systems (4) Apply Framework System-activity Manager system relationships between them, as shown in: in short, Activity Manager System (which focuses on activitymanagerservice, or AmS) is responsible for Activity initiation and Lifecycle Management. An Activity corresponds to an application window, and the creation and management of the window is the responsibility of window and View manager System. For example, The phone screen shows three windows, a status bar window, a hand Q main interface window, and a popupwindow. The view system manages the complex layout of each window, and eventually the view Hierarchy's topmost root view is added as a window to the Windows Manager System. Window Manager System manages all of these added windows, managing the levels of these windows, displaying locations, and so On. Each window has its own surface,surface Flinger is responsible for crafting these Surface pieces into a FrameBuffer. That is, window Manager System is responsible for the creation and removal of windows, as well as the management of display Status. The specific drawing is the responsibility of Suerface Flinger. 3.1 Creation of the application window first, we analyze the creation of the application window, which is also our development process,The first Encounter. Starting with the development of the first Hello world Android app, we're already in touch with the application window. We know that each Activity corresponds to a phonewindow, and when we call setcontentview, the end result is to add our view tree as a child view into the Decorview of PHONEWINDOW. The root View of each Activity is actually a decorview. In the end, this decorview is added to the WmS by Windowmnagerimpl's AddView method in the Handleresumeactivity method of Activitythread. What did Phonewindow's Setcontentview do? Just through the Installdecor () method, the window is initialized with a few decorations. The so-called decoration refers to the interface to see the title bar, navigation bar ActionBar. The View that we set through Activity's Setcontentview is as the content of the window (as shown, as the child view of the Framelayout with ID android.r.content). here, We do not understand how the title bar of the window is Added. And why some properties of the window are set before the Setcontentview Call. Because the Generatelayout method is responsible for the Window's properties, it ultimately decides to use a different layout to generate the top-level layout of the WINDOW. The generatelayout is called only when Mcontentparent is null, and mcontentparent is null only when the first call to Setcontentview is made, and thereafter it is no longer null. As you can see from the diagram above, Phonewindow is only responsible for handling some of the common logic of application Windows. however, the process of adding a View as a window to the WmS is done by windowmanager. The implementation of WindowManager on the application side is windowmanagerimpl, that is to say, the getwindowmanager we get through Activity is actually windowmanagerimpl. So in the Handleresumeactivity method of activitythread, there are callsWindowmanagerimpl addview, Add the Phonewindow prepared Decorview as a window to the WmS. The code looks like This: the process of adding a window as shown, we know that the WmS is running in a separate process. The addtodisplay operation performed here iwindowsession should be an IPC Call. When each app window is created, a Viewrootimpl object is Created. After analyzing the creation of the subsequent subwindow and the creation of the system window, we will know that the creation of any window will eventually create a Viewrootimpl object. Viewrootimpl is a very important class, similar to the Activitythread is responsible for communication with ams, Viewrootimpl is an important responsibility to communicate with the WmS, it through the static variable swindowsession (iwindowsession Instance) to communicate with the WmS. For each application process, there is only one swindowsession object, which corresponds to the session subclass in the wms, and the WMS assigns a Session object to each application Process. The WindowState class has a Iwindow mclient parameter, which is assigned in the constructor method, is passed by the Session call addwindow, and corresponds to the instance of the W class in Viewrootimpl. Here we comb the correspondence between these Classes. As you can see, the essential process of creating a window is to create a WindowState object on the WmS side that represents the WINDOW. The WmS is responsible for managing some of these WindowState objects. So far, the process of creating an application window is Over. To summarize, for the acivity corresponding application window is created: (1) its type is type_ base_ application, defined as the application window, (2) to perform addview operation windowmanager, which is it? Analysis of the previous source code, is through the activity of the Getwindowmanager to obtain, and return is the activity of the mwindowmanager, and its assignment is in the Attch method, the direct fetch of the Window Mwindowmana Ger The Mwindowmanager of Window is also in the attach method, through Mwindow Setwindowmanager toInitialized. As you can see from the previous analysis, the Mwindowmanager in the final Window is created by Createlocalwindowmanager (this) to create a new Windowmanagerimpl object, the Object's Mparentwindow is the Mwindow in Activity. (3) What about the base token? View the Add window procedure, before calling the AddView method, does not assign a value to token? This is where the default assignment logic Goes. In the case of windowmanagerimpl, Mparentwidnow is the corresponding Phonewindow of Activity. So in the default check logic, it will go to its own Phonewindow adjustlayoutparamsforsubwindow, the Mapptoken assignment to Token. So far, the type and token are legal, and you can create a window. The Mapptoken in window has been assigned by calling Window's Setwindowmanager in the Activity's attach method, which is the value of Mtoken in the Activity. Dialog the corresponding application window is created in our impression, Dialog is a sub-window. But look at the source of Dialog, we will find the type of Dialog is type_application, application window. Like the window for Activity, Dialog has an instance of PHONEWINDOW. In the Dialog build method, A Window object is generated through Policymanager.makenewwindow (mcontext), which is actually the Phonewindow object, much like the Activity creation application WINDOW. One difference is that when invoking the Setwindowmanager of a Window, the parameter Apptoken and AppName pass are Null. Activity is the assignment of their own mtoken to the Past. next, when the application calls the show method, the Dialog is displayed, so the process of adding the View to the window should be performed in the show Method. Analysis here, There are a few questions to answer (1) The dialog TYPE is type_application, which represents the application Window. This application window is followed byWhat are the different application windows for Activity? When parsing the code, the Phonewindow instance of Dialog is found, and when Setwindowmanger is called, null is passed to the parameter apptoken, that is, the Phonewindow of the Mapptoken object is Empty. And the Activity of the Phonewindow Mapptoken equals its mtoken, must not be Empty. (2) the WindowManager of Activity is obtained through the getsystemservice of the Context. And eventually the AddView operation is performed through this windowmanger. How is this example of Windowmanger created? (3) Dialog before addview, also did not assign a value to Token. Obviously token values need to be assigned by default Logic. The default logic is very much related to the Mparentwindow in the WindowManager instance. Obviously Dialog in the Mwindowmanager Mparentwindow can not be empty, otherwise Dialog token will not be assigned, create the window will throw an Exception. There's One more Point. oh, Dialog is the application window type, token must be Activity's Mtoken oh. Speaking of which, do you already understand? If Mwindowmanager is the Mwindowmanager in the Activity, all the problems are Solved. Dialog Construction method, to pass a Context, we usually pass the activity of the example, to see the activity of the Getsystemservice Implementation. What happens if we pass a application Context? 3.2 Creation of sub-windows for WmS, no matter what the window is created, it is ultimately through Windowmanagerimpl's AddView to add a View. Token requirements vary for different types of windows, Type. The process of creating a window is essentially the Same. Commonly used sub-windows, there are popupwindow,contextmenu,optionmenu. We start with a specific subwindow to analyze the differences and the principles of Implementation. Popupwindow Analysis Popupwindow found that it is not with Dialog, and there is not a window object, in the Invokepopup method, directly add Mpopupview through WindowManager as a window. Its windowmanager.layoutparams is initialized by Createpopuplayout (anchor.getwindowtoken ()) and its type is WindowManager.LayoutParams.TYPE_ Application_ PANEL, which belongs to the child window Type. So its token is taken from Outside. The Popupwindow is always set to a token by Showasdropdown (anchor.getwindowtoken ()) or by Showatlocation. Here is also a summary of the Popupwindow display: (1) type is Type_application_ PANEL. (2) its mwindowmanager is obtained through the getsystemservice of the Context. The Context is likely to be passed through its construction method, or by passing the Contentview to Fetch. (3) the token is assigned before the ADDVIEW. Whether it is Showatdropdown or showatlocation, you need to pass a View anchor come in, token directly take the Anchor.getwindowtoken. The View's Getwindowtoken returns the Mwindowtoken.contextmenu (context Menu) in Viewrootimpl's attachinfo, which is a standard interaction of Android, typically long-press A view, you can display the current context Menu. When we do not handle long press events on our own, Android defaults to a long-press operation, and ShowContextMenu () is called, and the showcontextmenu of View will continue to call Showcontextmenuforchild if it has Parent, for a window with phonewindow, the root view of the view tree is decorview, so the Decorview method of the same name will eventually be called, which is handled as follows: the context menu really shows where it should be in the ContextMenubuilder in the show method, see, here will call Originalview Createcontextmenu method, and Originalview is a long-pressed View ah. next, call Menudialoghelper's Show method, to complete the operation of creating the window, and here is not the context menu display logic is very clear. Let's take a look at what the createcontextmenu of the view did, call itself the oncreatecontextmenu, and call Mparent's createcontextmenu, and so it goes all the way down the Loop. thus, the Story menu item for the parent view appears in each of the child Views. In summary, the context menu is essentially a Dialog (note here that the Dialog window type is assigned: WindowManager.LayoutParams.TYPE_ application_attached_dialog), The Framework's UI Framework provides a convenient way to borrow everyone to add menu Items. To summarize, the creation of ContextMenu: (1) The essence is a Dialog, but the type is modified to type_application_attached_dialog, as the child window, (2) the Context of Dialog is taken Menu.getcontext (), while Mmenu essence should be decorview. This decorview context is naturally the context of PHONEWINDOW. If you press and hold the view in the Activity's corresponding window, the natural Context is the Activity. (3) Final Menudialoghelper helper = mcontextmenu.show (originalview,originalview.getwindowtoken ()); You can see that the token passed is the windowtoken of the View being pressed, and this is a Iwindow object. (4) in fact, as long as the token has been given the correct value, here the Context itself is what type, not Important. Regardless of the type of Context, when getting windowservice, an instance of Windermanagerimpl will be Returned. Since token has been correctly assigned, there is no need to mparEntwindow The default logic to assign the Value. The Optionmenu (option menu) option menu is typically a menu that pops up after the user presses the "menu" key, to start optionmenu, one to press the "menu" key and the other to call the Openoptionsmenu Method. For a common window, all user messages are handled by the view in the window, but for windows that have a Window object (that is, the Phonewindow object), it already handles the "menu" key message for the WINDOW. Specifically in Phonewindow's OnKeyDown method, Onkeydownpanel is called and Onkeyuppanel is called in OnKeyUp. ultimately, the display of Optionmenu is done by calling Openpanel. Analysis of the implementation of openpanel, we know that Optionmenu is not Phonewindow object, just a View, through the panelfeaturestate to Manage. The WindowManager that is used to display Optionmenu is actually the mwindowmanager of the Phonewindow that is currently called openpanel, as in Dialog, AddView during the execution of Optionmenu Windowmanager.layoutparams's Tokey will be assigned to the Activity's Mapptoken. When the window is actually added, it is adjusted to the corresponding Viewrootimpl's W class Object. To display optionmenu, the essence is to update the contents of the panelfeaturestate, Window.callback defines some, specifically for the purpose of preparing optionmenu, and responding to Optionmenu Operations. Through these interfaces of windowcallback, the Android Framework handles the process of displaying the menu of options itself, giving the Activity the right to display the contents of the menu, which is what we do in the implementation process, The reason for displaying the Options menu is to overload these interfaces only. and Optionmenu's root view is also decorview, summarizing, Optionmenu's creation: (1) Its type is Type_ Application_ attached _ DIALOG, which belongs to the child window. (2) due to the Optionme Nu is in PHonewindow Openpanel Add the window, WindowManager directly take the Phonewindow Windowmanager. The WindowManager in Phonewindow is created by ((windowmanagerimpl) wm). Createlocalwindowmanager (this), and it is visible that its mparentwindow is the current PHONEWINDOW. (3) The token is not explicitly assigned before the DISPLAY. In addview, The default assignment logic is gone, and eventually the Adjustlayoutparamsforsubwindow of the current Phonewindow itself is Called. The type is a child window, which takes Phonewindow's Decorview Windowtoken assignment to Token. Decorview's Winodwtoken is an example of IWINDOW. Summarize the creation of the Window: (1) the value of type is in [first_sub_ window, last_ sub_ window]; (2) token must be the Iwindow object of the parent window, the parent window must exist, and (3) the child window is not visible when the parent window is not visible And think about it, in the OnCreate method of Activity, You can create a normal Dialog and display it. But create a sub-window type of Dialog and display it? 3.3 System Window Creation System window is divided into 4 categories: (1) type_toast, do not need to declare permission, do not need token, (2) the second class, do not need to declare permission, but need token, and have certain requirements for token; (3) The third category requires ANDROID. Manifest.permission.SYSTEM_ALERT_WINDOW permission; (4) class fourth, Android Required. Manifest.permission.INTERNAL_SYSTEM _window permissions; Toast window creation analyze the creation of the toast window, the code is as Follows: 3.4 The window removes any window type, and the window is removed by invoking the WindowManager Removeview to complete, the specific process is as follows: Viewrootimpl after receiving the command to delete the window, the following actions will be performed, see the source analysis in Detail: (1) determine whether the window can be deleted immediately, otherwise it will be executed when the next UI action ; (2) confirm the need to deletewindow, the Dodie method is executed, the View tree is notified via dispatchdetachedfromwindow, the window is deleted, and (3) Dispatchdetachedfromwindow performs the following actions 1, through dispatchdetachedfromwindow, notify the View tree, the window has been removed, you have detach from WINDOW. 2, the window corresponding to the hardrender, Surface to release, 3, through mwindowsession, notify the wms, the window to remove, the WmS will be associated with this window WindowState, and Windowtoken to remove, While updating the display of other Windows 4, notify choreographer, This window does not need to display, and this window related to some UI refresh operations, can be Canceled. (4) when the root view receives a Dispatchdetachedfromwindow call, it traverses each view in the view tree and passes the Notification. The mattachinfo of the View is cleared and reset is Null. Viewrootimpl.javaboolean die (boolean Immediate) {//if immediate removal is required, execute Dodieif (immediate &&!misintraversal) immediately { Dodie (); Return false;} If (!misdrawing) {destroyhardwarerenderer ();} else {mwindowattributes.gettitle ());} otherwise, send a message through handler, one will execute bar mhandler.sendemptymessage (msg_die); return true;} In dodie, The view tree is notified via dispatchdetachedfromwindow, the window has been removed void Dodie () {... synchronized (this) {if (mremoved) {return;} mremoved = true; If (madded) {dispatchdetachedfromwindow ();} ...} ...} Dispatchdetachedfromwindow perform the following actions//(1)By dispatchdetachedfromwindow, notify the view tree that the window has been removed and you have detach from WINDOW. (2) the window corresponding to the hardrender, surface to release,//(3) through mwindowsession, notify the wms, the window to remove, the WMS will be associated with this window windowstate, and Windowtoken to remove , while updating the display of other windows//(4) notification choreographer, This window does not need to display, and this window related to some UI refresh operations, can be Canceled. void Dispatchdetachedfromwindow () {if (mView! = null && mview.mattachinfo! = Null) {mAttachInfo.mTreeObserver.di Spatchonwindowattachedchange (false); Mview.dispatchdetachedfromwindow ();} ... destroyhardwarerenderer (); setaccessibilityfocus (null, null); mview.assignparent (null); mView = null; Mattachinfo.mrootview = null;msurface.release ();... try {mwindowsession.remove (mwindow);} catch (remoteexception e) {} ... unscheduletraversals ();} Iv. Summary Here We summarize the relevant contents of the Windows in Android: (1) in window system, the content is divided into two parts, the WMS and related classes running in the system service process (wms), and the other part is running in the application process windowmanagerimpl, Windowmanagerglobal,viewrootimpl and other related Classes. The WmS uses WindowState to describe a window, while the application process uses Viewrootimpl,windowmanager.layoutparms to describe the content of a window. (2) for WmS, The window corresponds to a View object, not a Windows Object. Add a window that is through windThe AddView method of Owmanager. In the same way, removing a window is done through the Removeview method. Updates the properties of a window through the Updateviewlayout method. (3) window class Description is a kind of windows with some common characteristics, and its implementation class is PHONEWINDOW. The Activity corresponding window, and Dialog corresponding to the window, will correspond to a Phonewindow object. The Phonewindow class handles the unification of some operations, such as Long press, press "back" key, etc. (4) the Android Framework divides windows into three types, application windows, sub-windows, and System Windows. Different types of windows, when performing the Add window operation, have different requirements for parameter tokens in Windowmanager.layoutparams. The application window, token in layoutparams, must be the mtoken of a valid Activity. While the child window, token in layoutparams, must be the W object in the parent Window's Viewrootimpl. System window, Some system windows do not need token, some system window token must meet certain requirements. (5) WindowManager can only be obtained by Context.getsystemserver (I.E. to obtain an instance of windowmanagerimpl). If the context is activity, it returns directly to the Activity's mwindowmanager, whose windowmanagerimpl.mparentwindow is the activity itself Phonewindo W. If this context is application, or Service, it returns an instance of Windowmanagerimpl directly, and Mparentwindow is Null. (6) before calling Windowmanagerimpl's addview, if no token assignment is given, the default token assignment logic is GONE. The default token assignment logic is this, and if Mparentwindow is not empty, its Adjustlayoutparamsforsubwindow method is Called. In the Adjustlayoutparamsforsubwindow method, if the window that is currently being added is, the application window, if its tokeN is empty, the current Phonewindow's Mtoken is assigned to Token. If it is a subwindow, the mwindowtoken in the mattachinfo corresponding to the current Phonwwindow will be assigned to Token. The Attachinfo Mattachino in View is from the mattachinfo of Viewrootimpl. So the token essence is the W class object in the Viewrootimpl of the parent window.<p><p> An analysis of Android windows </p> </p></span>