Android interprocess communication (IPC) Mechanism Binder Brief Introduction

In Android, each application is made up of activity and service that are likely to run in the same process or run in different processes. So, how does the activity or service in the same process communicate? This is the binder interprocess communication mechanism to be described in this article.

We know that the Android system is based on the Linux kernel, while the Linux kernel inherits and is compatible with the rich Unix system interprocess communication (IPC) mechanism. There are traditional pipe (pipe), signal (Signal) and Trace (trace), the three communication means can only be used between the parent process and the child process, or between the sibling process, and later added the command pipeline (Named pipe), so that interprocess communication is no longer confined to the parent-child process or sibling processes In order to better support transaction processing in commercial applications, at/T Unix System V, there are three additional interprocess communication mechanisms called "system V IPC", namely Message queue (message), Shared memory (Share Memory) and semaphores (Semaphore); Later BSD Unix has made an important expansion of the "system V IPC" mechanism, providing an inter-process communication mechanism called the socket (socket). To learn more about these interprocess communication mechanisms, refer to the "Linux kernel source Scenario analysis" article in the article on Android learning startup.

However, instead of using the various interprocess communication mechanisms mentioned above, the Android system uses the binder mechanism because of the poor performance of the mobile device hardware and low memory characteristics. Unknown. Binder is not actually a set of new inter-process communication mechanism proposed by Android, it is based on Openbinder to achieve. Openbinder was first developed by Be Inc., followed by Palm Inc.. Now Openbinder's author Dianne Hackborn is working for Google and is responsible for the development of the Android platform.

As mentioned repeatedly, Binder is an inter-process communication mechanism, which is similar to the COM and CORBA Distributed component architecture, which is a bit more popular, in fact, it provides remote procedure call (RPC) function. From the literal point of view, Binder has the meaning of binders, then what is it bonded together? In the binder mechanism of the Android system, a system component consists of the client, server, Service Manager, and binder drivers, where client, server, and service Manager are running in the user space , the binder driver runs kernel space. Binder is a binder that binds the four components together, where the core component is the binder driver, and Service Manager provides the auxiliary management functionality that the client and server are in the Binder drive and service The manager provides the infrastructure for communication between Client-server. Service Manager and Binder drivers have been implemented on the Android platform, so developers can implement their own client and server components as per the specification. Easy to say, hard to do, for beginners, the binder mechanism of the Android system is the most difficult to understand, and the binder mechanism, whether from the system development or application development point of view, are the most important components of Android system, therefore, It is necessary to have a deeper understanding of how binder works. To learn more about how Binder works, the best way is to read binder-related source code, the originator of Linux Linus Torvalds once said a famous rtfsc:read the fucking source code.

Although reading binder source code is the best way to learn the binder mechanism, but also must not play unprepared for the war, because the binder is relatively boring and more difficult to understand, if you can be supplemented by some theoretical knowledge, it is better. Gossip less, online about the binder mechanism of the information is still a lot of, here do not want to write again in detail, strongly recommend the following two articles:

Android in layman's binder mechanism

Android Binder Design and implementation – design article

The binder mechanism of Android in layman's terms from the scene, in-depth introduction of binder in User space three components client, server and service manager of the relationship between Android The design and implementation of binder is a detailed introduction to the data structure and design principle of binder driver in kernel space. We are very grateful to the two authors for bringing us such a good binder study material. To summarize, the relationship between the client, Server, Service Manager, and binder drivers in the four components of the Android system Binder mechanism is as follows:

1. Client, server, and service Manager implementations in user space, binder drivers implemented in kernel space

2. Binder drivers and Service Manager have been implemented in the Android platform, developers only need to implement their own client and server in the user space

3. Binder driver provides device file/dev/binder interaction with user space, Client, server, and service Manager communicate with binder driver through open and IOCTL file operation functions

4. interprocess communication between client and server is implemented indirectly through binder drivers

5. Service Manager is a daemon that manages the server and provides the client with the ability to query the server interface

At this point, the binder mechanism finally has a perceptual understanding, but still feel not very well from top to bottom throughout the IPC communication process, so, intends to analyze the binder source code through the following four scenarios to further understand the binder mechanism:

1. How does Service manager become a daemon? That is, how Service Manager informs the binder driver that it is the context manager of the binder mechanism.

2. How does server and client get the Service Manager interface? That is, how the Defaultservicemanager interface is implemented.

3. How does the server start up its own services? How is Service Manager servicing server during server startup? That is, how the Iservicemanager::addservice interface is implemented.

4 How does Service Manager provide services to the client? That is, how the Iservicemanager::getservice interface is implemented.

In the next four articles, the binder source code will be analyzed according to these four scenarios, all of which will involve binder-related source code for user space to kernel space. Why isn't there a scenario where client and server are communicating between processes? This is because Service Manager, as a daemon, also acts as a server role. Therefore, as long as we can understand the third and fourth scenarios, we also understand how the client and server in the binder mechanism communicate with each other through the binder driver for interprocess communication.

To facilitate the description of the principle and implementation of the binder mechanism for inter-process communication between Android systems, in the next four articles, we have introduced the implementation of the binder mechanism based on the C + + language, but when we develop the application in the Android system, it is based on the Java language, Therefore, in the last article, we will detail the Java interface implementation of the Android system interprocess communication Binder mechanism in the application framework layer:

5. The Android system interprocess communication binder Mechanism is analyzed in the Java Interface Source code of the application framework layer.

Android interprocess communication (IPC) Mechanism Binder Brief Introduction