Introduction to the Android binder mechanism

Android developers may have some experience, early in the beginning, the work is mainly to achieve a variety of UI interface, as well as the implementation of the business logic of the application. At this stage, we will gradually become familiar with the view system, gradually learn to achieve a variety of interface and animation effects. Later, when we want to learn more about Android, such as the start-up process of Android four components, AMS, PMS and so on, will encounter a thing called Binder. Combined with the author's experience, Binder can be said to be an important foundation for an in-depth understanding of Android systems. Binders act as a mechanism for inter-process communication between Android systems, throughout every aspect. The startactivity and startservice that we use most often are communicated through the binder mechanism to the process where AMS resides. This paper mainly introduces the system structure of binder mechanism, and I believe that after reading it, the reader will have a general understanding and grasp of binder.

Note: When I beginner binder, I have seen some of the binder introduction of the article, and early tangled in some articles in the binder code details, feel very laborious. This paper only introduces the binder mechanism on the macro level. Believe that the reader first understand the overall structure of binder, then go into the details, learning effect will be better.

What is binder and what can be done?

Binder is an inter-process communication mechanism within an Android system. Androd systems, different apps run in different processes, and different components of the same app may run in different processes (android:process in the Androidmanifest file). When a process wants to provide services to other processes, it needs to provide services through interprocess communication. For example: We have a APP1 that has a service component that can provide a calculator. When another APP2 also want to use the service of the APP1 inside the services of the calculator, because different apps run in different processes, so, APP2 is unable to directly use the service inside the APP1. Because the process is crossed, it can only be done through interprocess communication mechanisms.

Besides the image point, APP1 the process has an object object1, which has a method method1. Another process where the APP2 is located, want to use the Object1 Method1 method. Binder may help us get a reference to a Object1 object in the APP2 process, allowing us to call directly through OBJECT1.METHOD1 () just like local objects. With binder, we can break through the limits of the process, pass objects to other processes, and make it easier for other processes to invoke the object's methods.

Why use binder?

After understanding what binder is and what it can do, you may have questions about how the Android system, based on the linux,linux itself, has a lot of inter-process communication options, why Android does not use an inter-process communication method that comes with Linux, And the new creation of a binder? Do you repeat the wheel?

Linux comes with inter-process communication: file, signal, socket, Pipe, shared memory ..., why use binder? The author concludes that there are two main reasons:

1 historical reasons. Binder was not originally designed for Android, and at first there was a openbinder that was used in a kernel OS called palm COBALTW. Later, the Palm COBALTW was transplanted to the Linux system, and Openbinder was transplanted along with it. When Google set up the Android development team, it hired an engineer called Dianne Hackborn, who was the core of Openbinder. Later in the process of Android communication, found that binder is appropriate, it is a natural use of the Android system Binder.

2 Binder Some of its own characteristics and advantages. Binders are suitable for use in Android systems for both security and efficiency when it comes to interprocess communication. In this regard, the first impression can be.

What are the components of binder?

A binder system consists of four parts: Binder client, Binder server, Binder driver, Service registration query module

Binder Client : The process that wants to use the service

Binder Service Side : The process of actually providing services

Binder Driver : We first get a reference to an object in a server-side process through binder, which, through this reference, directly invokes the object's method to get the result. When this reference object executes the method, it passes the request of the method call to the binder driver, then the binder driver passes the request to the server process, and after the server process receives the request, invokes the "real" object of the server to execute the called method, and after the result, the result is sent to the binder driver. The binder driver sends the result to our client, and finally, we have a return value in the client process call. Binder driver, equivalent to the role of a transit person. With the help of this intermediary, we can invoke objects in other processes.

Service Registration Query Module : When we invoke objects in other processes, we first get this object. This object actually represents what another process can offer us (and, more directly, what methods are available in the object for the client process to invoke). First, the server process to register in a certain place, tell the system I have an object can be exposed to other processes to provide services. When the client process needs this service, it goes to the registered place to find the object through a query.

How do the binder parts work?

Here's how binder works from a client-side process point of view

As a client process, it simply wants to use the services provided by the server-side process:  but because of the isolation of the process, the client's Processa is unable to read and write the contents of the PROCESSB in the service, but the system kernel can, And the binder driver is running in the kernel state. Binder driver to help us transfer the request can be:  with binder driver, for the client side and the service side, you need to specifically with the binder driver to deal with, In order to help the client and the service side to shield off the binder driver deal with this very low work, we can design a proxy for client and service, so that they can only deal with agents, The task of working with binder drivers is placed in the agent: The reader may want to ask, if you want to implement the client side and service side, through the above way, although logically independent out of two agents (proxy of the client agent, proxy stub on the server), These two agents are not to be implemented by themselves? If you want to do it yourself, what is the point? ANDROIDSDK provides us with a aidl tool. We just need to create a new Aidl file, like creating a normal interface (slightly different) to define the interface method inside. After the definition, ANDROIDSDK will automatically generate a Java file for us based on the interface definition inside the AIDL, which includes the client Agent proxy and the server proxy stub, and automatically generates code that communicates with the binder driver. In the above picture, the reason that the client proxy is called proxy, the service agent is called stub, is because the Aidl auto-generated proxy, the two proxy class name is the proxy and stub. The real work we do is only the real service function logic.   Another step closer to thinking, for the client, the more desirable state is that the client does not have to know whether the object being called is a local object, or an object in a server-side process. According to the picture above, the client obviously knows that he is invoking a remote object, so it is tuned by a proxy. We use some system-provided Xxxmanager (Activitymanager, Packagemanager, Wifimanager, PowerManager, etc.) during the development of Android applications. One of the things that these managers want to accomplish is to help the client block out the implementation details of the binder. With these manager,client in use, first obtain a manager object through Getservicemanager (XXX), followed by a directCall the packaged service method in the manager. In this way, the manager actually communicates with the Xxxservice in the other process through the binder driver, but it doesn't have to be known to the client at all. For example, for some system services, Activitymanager, Packagermanager, and so on, not only for the client screen of binder-related details, but also to the real service-side object provided by the service API filtering and control, You can expose only a subset of the service APIs to the client.   Last question: to the above picture, the premise is that the client first obtains a proxy or manager, and then completes the subsequent interprocess communication. So how does the client get to the manager or proxy? First, take some system services as an example: As mentioned earlier, the binder mechanism of the four components, one is "Service registration query Module", corresponding to the context Manager in the Android system running process named: ServiceManager. In all the service processes, ServiceManager first start, the reason is not difficult to understand, if the other service process started before ServiceManager, where to register?   as shown, PROCESSB needs to register with ServiceManager if the service's process PROCESSB started after the ServiceManager process starts. "Registration" This action, the essence is to step into the communication, from PROCESSB to ServiceManager, at this time, the service became the client of the cross-process communication, ContextManager became the server. Client-to-server communication, as mentioned above, requires a proxy or manager. Where does this proxy or manager get it? The problem seems to be trapped in a cyclic deadlock? Because of the special status of ContextManager, the reader can understand that the system to it a bit special treatment, the service can be from a global fixed place directly to the proxy or Manager, rather than as the client through the query to get Proxy/manager. Get the client agent, the specific registration of the communication process as mentioned above, no longer repeat. So far, the service has been successfully registered in ContextManager.   When the client initializes the manager, the manager also, like the service, gets contextmanager directly from a fixed locationAgent, through the agent, to query ContextManager, get a "provide the proxy object to serve." When the manager has this object, the client can use the service through the manager, invoke the logic   when it implements the client and service, how does the client get the proxy object? Let's start with the implementation: typically we create a service in the app by using service components. Other apps are connected to the service via Bindservice, and the proxy agent object can be obtained by onserviceconnected callback. Concrete implementation can refer to:http://blog.csdn.net/singwhatiwanna/article/details/17041691  Summary

This paper briefly introduces the logic of Binder cross-process communication mechanism, hoping to help students of binder to get started quickly and submit their learning efficiency. The pictures and ideas used in this article are from this document:

Http://events.linuxfoundation.org/images/stories/slides/abs2013_gargentas.pdf, add in some of the author's own thinking and summary. If there are mistakes in some places, please feel free to communicate.

Also recommend a binder primer article: http://weishu.me/2016/01/12/binder-index-for-newer/

Introduction to the Android binder mechanism