Android Advanced: Does the Context corresponding to Dialog have to be an Activity? Detailed analysis from the source code

[[419839]]

Preface

When creating a Dialog, I know that a context is required in the Dialog constructor, but I don't have a specific concept of this "context", which results in a program error.

Then I found that the only context environment required by Dialog is activity.

So the following article will thoroughly sort out this issue from the perspective of source code;

1. Dialog creation failed

In the Dialog constructor, pass in an Application context. See if the program reports an error:

 Dialog dialog = new Dialog(getApplication());
     TextView textView = new TextView(this);
 textView.setText( "Use Application to create Dialog" );
     dialog.setContentView(textView);
 dialog.show();

Run the program, and it crashes as expected. Let's take a look at the error message:

 Caused by : android. view .WindowManager$BadTokenException: Unable to   add window -- token null is not for an application  
 at android.view.ViewRootImpl.setView ( ViewRootImpl.java:517)
 at android.view.WindowManagerImpl.addView ( WindowManagerImpl.java:301)
 at android.view.WindowManagerImpl.addView ( WindowManagerImpl.java:215)
 at android. view .WindowManagerImpl$CompatModeWrapper.addView(WindowManagerImpl.java:140)

There are two points we need to pay attention to in this error log

• The program reported a BadTokenException;
• The program error is in the setView method of ViewRootImpl;
• We must be wondering what BadTokenException is. Before explaining this, we first need to understand Token. After understanding the concept of Token, combined with the setView method of ViewRootImpl, we can understand what BadTokenException is and how it is generated.

Token Analysis

1. Token details

Token literally means token in Chinese. It is used as a security mechanism in the Android system. Its essence is a Binder object, which acts as a verification code in the process of cross-process communication. For example, in the process of starting the activity and drawing the interface, the communication between the three processes of ActivityManagerService, application, and WindowManagerService will be involved. At this time, Token acts as an authentication function in these three processes. ActivityManagerService and WindowManagerService use the Token passed by the application's activity to distinguish which activity controls the application. Specifically:

• In the process of starting an Activity, first, ActivityManagerService will create an ActivityRecord to be managed by itself, and at the same time create an IApplication (essentially a Binder) for this ActivityRecord.
• ActivityManagerService passes this binder object to WindowManagerService, allowing WindowManagerService to record this Binder.
• When ActivityManagerService completes the addition of the data structure, it will return an ActivityClientRecord data structure to ActivityThread, which contains the Binder object Token.
• After ActivityThread gets the Binder object of this Token, it needs to ask WindowManagerService to add a corresponding window on the interface. The Token is included in the WindowManager.LayoutParams data passed to WindowManagerService when adding the window.
• Finally, when WindowManagerService adds a window, it needs to compare the Binder of this Token with the Binder previously saved by ActivityManagerService. If it passes the verification, it means it is legal. Otherwise, it will throw the BadTokenException.
• At this point, we know what BadTokenException is, and then we will analyze why the Application context will report a BadTokenException, while the Activity context will not.

2. Why do we need a token?

Because WMS needs to use this token to determine the position of the window (not the coordinates). If there is no token, it will not know which container the window should be placed in.

Because the WindowManger of the non-Activity Context does not have a ParentWindow, the corresponding container cannot be found on the WMS side, that is, it does not know where to place the Dialog Window.

Another reason is that there is no SYSTEM_ALERT_WINDOW permission (of course, permissions are required. The subcontainer of DisplayArea.Tokens has a higher level than the Window of ordinary applications, which means it will be displayed in front of the Window of ordinary applications. If permission control is not added, it will be abused).

After obtaining the SYSTEM_ALERT_WINDOW permission and specifying the Window.type of the Dialog as SYSTEM_WINDOW, it can be displayed normally because WMS will create a WindowToken specifically for the SYSTEM_WINDOW type window (now there is a container) and place it in DisplayArea.Tokens (now you know where to put it);

3. Create dialog process analysis

1. The activity interface is finally connected to WindowManagerService through the setView method of ViewRootImpl, so that WindowManagerService draws the interface on the mobile phone screen. From the above exception log, we can also see that the Dialog interface is also connected to WindowManagerService through the setView of ViewRootImpl to complete the drawing of the interface.

Let's first look at the Dialog constructor. Regardless of the one-parameter constructor or the two-parameter constructor, the three-parameter constructor will eventually be called:

 Dialog(@NonNull Context context, @StyleRes int themeResId, boolean
 createContextThemeWrapper) {
 ......
 //1. Create a WindowManagerImpl object
        mWindowManager = (WindowManager) context.getSystemService(Context.WINDOW_SERVICE);
 //2. Create a PhoneWindow object
        final Window w = new PhoneWindow(mContext);
 mWindow = w;
 //3. Enable dialog to respond to user events
 w.setCallback(this);
        w.setOnWindowDismissedCallback(this);
 //4. Set WindowManager for the window object
        w.setWindowManager(mWindowManager, null , null );
        w.setGravity(Gravity.CENTER);
        mListenersHandler = new ListenersHandler(this);
 }

From this code, we can see that the creation of a dialog is essentially the same as the creation of an activity interface. Both require the creation of an application window Window and an application window view object manager WindowManagerImpl.

Then Dialog also has a setContentView method:

 public void setContentView(@LayoutRes int layoutResID) {
        mWindow.setContentView(layoutResID);
 }
 Still call the setContentView method of PhoneWindow. Next, let's look at the show method of dialog:
 public void show() {
 ......
 //1. Get the DecorView encapsulated by the setView method
        mDecor = mWindow.getDecorView();
 ......
 //2. Get the member variable WindowManager.LayoutParams that has been initialized when PhoneWindow is created
        WindowManager.LayoutParams l = mWindow.getAttributes();
 if ((l.softInputMode
                & WindowManager.LayoutParams.SOFT_INPUT_IS_FORWARD_NAVIGATION) == 0) {
            WindowManager.LayoutParams nl = new WindowManager.LayoutParams();
 nl.copyFrom(l);
            nl.softInputMode |=
                    WindowManager.LayoutParams.SOFT_INPUT_IS_FORWARD_NAVIGATION;
 l = nl;
 }
 try {
 //3. Add DecorView to the screen through WindowManagerImpl
            mWindowManager.addView(mDecor, l);
 mShowing = true ;
            sendShowMessage();
 finally
 }
 }

This code is similar to the makeVisible method of activity, so I won't go into details here. The comments are enough to make it clear. Then call the addView method of WindowManagerImpl:

 @Override
 public void addView(@NonNull View   view , @NonNull ViewGroup.LayoutParams params) {
        applyDefaultToken(params);
        mGlobal.addView( view , params, mDisplay, mParentWindow);
 }
 Then the addView method of WindowManagerGlobal is called:
 public void addView( View   view , ViewGroup.LayoutParams params,
            Display display, Window parentWindow) {
 ......
 //1. Convert the incoming ViewGroup.LayoutParams type params into
 wparams of type WindowManager.LayoutParams
        final WindowManager.LayoutParams wparams = (WindowManager.LayoutParams)
 params;
 //2. If WindowManagerImpl is created in the activity method, it is not empty
        if (parentWindow != null ) {
            parentWindow.adjustLayoutParamsForSubWindow(wparams);
 } else {
 ......
 }
 ViewRootImpl root;
 View panelParentView = null ;
        synchronized (mLock) {
 ......
            root = new ViewRootImpl( view .getContext(), display);
 view .setLayoutParams(wparams);
 //3. Store the view object view , ViewRootImpl and wparams in the corresponding positions of the corresponding collections respectively
            mViews.add ( view );
            mRoots.add (root);
            mParams.add (wparams);
 }
        // do this last because it fires off messages to start doing things
 try {
 //4. Contact WindowManagerService through ViewRootImpl to draw the view to the screen
            root.setView( view , wparams, panelParentView);
        } catch (RuntimeException e) {
            // BadTokenException or InvalidDisplayException, clean up.
            synchronized (mLock) {
 final int   index = findViewLocked( view , false );
                if ( index >= 0) {
                    removeViewLocked( index , true );
 }
 }
 throw e;
 }
 }

 //2. If WindowManagerImpl is created in the activity method, it is not empty
  if (parentWindow != null ) {
           parentWindow.adjustLayoutParamsForSubWindow(wparams);
 } else {
 ......
 }

2. Here, we will first determine whether a parentWindow of type Window is empty. If it is not empty, we will adjust some property values ​​of a variable wparams of type WindowManager.LayoutParams through the Window's adjustLayoutParamsForSubWindow method. When an application requests the WindowManagerService service, it will pass in a Token. In fact, that Token will be stored in the token variable of wparams through the Window's adjustLayoutParamsForSubWindow method. That is to say, if the Window's adjustLayoutParamsForSubWindow method is not called, the token variable of wparams will be empty. Then let's take a look at how the token variable of wparams is assigned:

 void adjustLayoutParamsForSubWindow(WindowManager.LayoutParams wp) {
        CharSequence curTitle = wp.getTitle();
        if (wp.type >= WindowManager.LayoutParams.FIRST_SUB_WINDOW &&
            wp.type <= WindowManager.LayoutParams.LAST_SUB_WINDOW) {
 ......
 } else {
            if (wp.token == null ) {
                wp.token = mContainer == null ? mAppToken : mContainer.mAppToken;
 }
 ......
 }
        if (wp.packageName == null ) {
            wp.packageName = mContext.getPackageName();
 }
        if (mHardwareAccelerated) {
            wp.flags |= WindowManager.LayoutParams.FLAG_HARDWARE_ACCELERATED;
 }

Here we can see that this code will first make a judgment if the value of wp.type is between WindowManager.LayoutParams.FIRST_SUB_WINDOW and WindowManager.LayoutParams.LAST_SUB_WINDOW. If not, wp.token will be assigned a value. wp.type represents the window type, which has three levels: system level, application level, and sub-window level. Here, it is used to judge whether it is at the sub-window level. The default value of Dialog's WindowManager.LayoutParams.type is application level, so it will take the else branch and assign mAppToken to wp.token. As for what mAppToken is, we will analyze it later.

3. Look at the addView method of WindowManagerGlobal, which calls the setView method of ViewRootImpl. Let's see how ViewRootImpl connects to WindowManagerService to pass token:

 public void setView( View   view , WindowManager.LayoutParams attrs, View   
 panelParentView) {
 synchronized (this) {
            if (mView == null ) {
                mView = view ;
 try {
 ......
 //1. Call the WindowManagerService interface request through the binder object mWindowSession
                    res = mWindowSession.addToDisplay(mWindow, mSeq, mWindowAttributes,
                            getHostVisibility(), mDisplay.getDisplayId(),
                            mAttachInfo.mContentInsets, mAttachInfo.mStableInsets,
                            mAttachInfo.mOutsets, mInputChannel);
                } catch (RemoteException e) {
 ......
                    throw new RuntimeException( "Adding window failed" , e);
 finally
                    if (restore) {
                        attrs.restore();
 }
 }
 ......
                if (res < WindowManagerGlobal.ADD_OKAY) {
 ......
                    switch (res) {
 case WindowManagerGlobal.ADD_BAD_APP_TOKEN:
 case WindowManagerGlobal.ADD_BAD_SUBWINDOW_TOKEN:
                            throw new WindowManager.BadTokenException(
 "Unable to add window -- token " + attrs.token
                                    + " is not valid; is your activity running?" );
 //2. If the request fails (token verification fails), a BadTokenException is thrown
 case WindowManagerGlobal.ADD_NOT_APP_TOKEN:
                            throw new WindowManager.BadTokenException(
 "Unable to add window -- token " + attrs.token
                                    + " is not for an application" );
 case WindowManagerGlobal.ADD_APP_EXITING:
                            throw new WindowManager.BadTokenException(
 "Unable to add window -- app for token " +
 attrs.token
                                    + " is exiting" );
 case WindowManagerGlobal.ADD_DUPLICATE_ADD:
                            throw new WindowManager.BadTokenException(
 "Unable to add window -- window " + mWindow
                                    + " has already been added" );
 case WindowManagerGlobal.ADD_STARTING_NOT_NEEDED:
                            // Silently ignore   -- we would have just removed it  
                            // right away, anyway.
 return ;
 case WindowManagerGlobal.ADD_MULTIPLE_SINGLETON:
                            throw new WindowManager.BadTokenException(
 "Unable to add window " + mWindow +
                                    " -- another window of this type already  
 exists");
 case WindowManagerGlobal.ADD_PERMISSION_DENIED:
                            throw new WindowManager.BadTokenException(
 "Unable to add window " + mWindow +
 " -- permission denied for this window type" );
 case WindowManagerGlobal.ADD_INVALID_DISPLAY:
                            throw new WindowManager.InvalidDisplayException(
 "Unable to add window " + mWindow +
 " -- the specified display can not be found" );
 case WindowManagerGlobal.ADD_INVALID_TYPE:
                            throw new WindowManager.InvalidDisplayException(
 "Unable to add window " + mWindow
                                    + " -- the specified window type is not valid" );
 }
                    throw new RuntimeException(
 "Unable to add window -- unknown error code " + res);
 }
 ......
 }
 }
 }

There are two things to note about this code:

• The WindowManagerService service is requested through a binder object of mWindowSession, and a variable mWindowAttributes of type WindowManager.LayoutParams is passed to WindowManagerService, which contains a token object representing the current activity. Then the screen view is created through the WindowManagerService service.
• The success of the request will be determined based on the return result of the request to the WindowManagerService service. If the request fails, an exception will be thrown. The comment is the exception thrown in the example at the beginning of the article. At this time, attrs.token is empty. Why is it not empty if the context of creating the dialog is changed to activity?

4. Analyze why the context Activity for creating Dialog is different

1. From the above analysis, we can see that attrs.token is assigned in the adjustLayoutParamsForSubWindow method of Window. The default WindowManager.LayoutParams.type of Dialog is at the application level. Therefore, if you can enter this method, attrs.token will definitely be assigned. Now there is only one situation. If it is not the context of activity, you will not enter this method. At this time, let's look at the addView method of WindowManagerGlobal:

 public void addView( View   view , ViewGroup.LayoutParams params,
            Display display, Window parentWindow) {
 ......
 //2. If WindowManagerImpl is created in the activity method, it is not empty
        if (parentWindow != null ) {
            parentWindow.adjustLayoutParamsForSubWindow(wparams);
 } else {
 ......
 }
 ......
 }

From here, we can see that if the parentWindow of the Window type is null, the adjustLayoutParamsForSubWindow method will not be entered. Therefore, we can conclude that if the fourth parameter parentWindow of the WindowManagerGlobal of the activity context is not null, then we will analyze why other contexts will cause parentWindow to be null.

WindowManagerGlobal calls the addView method in the addView method of WindowManagerImpl:

 @Override
 public void addView(@NonNull View   view , @NonNull ViewGroup.LayoutParams params) {
        applyDefaultToken(params);
        mGlobal.addView( view , params, mDisplay, mParentWindow);
 }
 The addView method of WindowManagerImpl is called in the first method of Dialog:
 public void show() {
 ......
 try {
            mWindowManager.addView(mDecor, l);
 mShowing = true ;
            sendShowMessage();
 finally
 }
 }

Compare these two methods. It can be seen that the addView method of WindowManagerImpl calls the addView method of WindowManagerGlobal with two additional parameters, mDisplay and mParentWindow. We only look at the latter one, which has an additional Window type mParentWindow. It can be seen that mParentWindow is not assigned in the show method of Dialog. So where is it assigned? Searching for mParentWindow in the WindowManagerImpl class, it is found that it is assigned in the two-parameter constructor of WindowManagerImpl. From this we can guess that if the activity context is used, the two-parameter constructor is used when creating the WindowManagerImpl instance, while other contexts use the one-parameter constructor. Now the question is focused on how WindowManagerImpl is created.

Let's look back at how WindowManagerImpl is created in the Dialog constructor:

 Dialog(@NonNull Context context, @StyleRes int themeResId, boolean
 createContextThemeWrapper) {
 ......
        mWindowManager = (WindowManager) context.getSystemService(Context.WINDOW_SERVICE);
 ......
 }
 Then check the getSystemService method of activity and the getSystemService method of Application respectively:
 Activity's getSystemService method
 @Override
 public Object getSystemService(@ServiceName @NonNull String name ) {
 ......
       if (WINDOW_SERVICE.equals( name )) {
 return mWindowManager;
       } else if (SEARCH_SERVICE.equals( name )) {
           ensureSearchManager();
 return mSearchManager;
 }
 return super.getSystemService( name );
 }

In this method, the activity's mWindowManager object is directly returned. The activity's mWindowManager object is in the activity's attach method:

 final void attach(Context context, ActivityThread aThread,
            Instrumentation instr, IBinder token, int ident,
            Application application, Intent intent, ActivityInfo info,
            CharSequence title, Activity parent, String id,
            NonConfigurationInstances lastNonConfigurationInstances,
            Configuration config, String referrer, IVoiceInteractor voiceInteractor) {
 ......
      mWindow.setWindowManager((WindowManager)context.getSystemService(Context.WINDOW_SERVICE),mToken, mComponent.flattenToString(),
                (info.flags & ActivityInfo.FLAG_HARDWARE_ACCELERATED) != 0);
 ......
 }

2. Let's look at the setWindowManager method of Window:

 public void setWindowManager(WindowManager wm, IBinder appToken, String appName,
            boolean hardwareAccelerated) {
 //1. Save the Token passed by ActivityManagerService to mAppToken
 mAppToken = appToken;
 //2. Create WindowManagerImpl
        mWindowManager = ((WindowManagerImpl)wm).createLocalWindowManager(this);
 }

There are two places to note in this code. First, the Token passed by ActivityManagerService is assigned to Winow's mAppToken. This token will eventually be saved to attr.token. The specific operation is in Window's adjustLayoutParamsForSubWindow method. Second, the createLocalWindowManager method of WindowManagerImpl is called to create WindowManagerImpl:

 public WindowManagerImpl createLocalWindowManager(Window parentWindow) {
 return new WindowManagerImpl(mDisplay, parentWindow);
 }

It can be seen here that if the context of creating Dialog is activity, the constructor of WindowManagerImpl with two parameters will be called, resulting in parentWindow not being empty.

3. Application's getSystemService method:

Since Application is a subclass of Context, the getSystemService of Application will eventually be transferred to the getSystemService method of ContextImpl

 @Override
 public Object getSystemService(String name ) {
 return SystemServiceRegistry.getSystemService(this, name );
 }
 The getSystemService method of SystemServiceRegistry is called directly, and this method will get the return value of the createService method of the anonymous inner class CachedServiceFetcher<WindowManager>.
 @Override
 public WindowManager createService(ContextImpl ctx) {
 return new WindowManagerImpl(ctx.getDisplay());
 }});

From this method, we can see that when the context is Application, the constructor of a parameter of WindowManagerImpl is called, so parentWindow is empty;

Summarize

• When creating a dialog, if the context passed into the constructor is not an activity type, the variable mParentWindow of WindowManagerImpl type is Window, which causes WindowManagerGlobal's addView to not call Window's adjustLayoutParamsForSubWindow method, and thus does not assign a value to attr.token, causing authentication failure in the WindowManagerService service and throwing a BadTokenException exception;
• To show a normal Dialog, you need a container token instead of the Activity itself. We usually pass the Activity, but the Activity just happens to correspond to a WindowState container on the WMS side.

This article is reproduced from the WeChat public account "Android Development Programming"