Android Binder Mechanism and its source code parsing Section 1 Overview

What is a binder?

Binder is a type of IPC. Do not know IPC? Google, the omnipotent Google.
In Linux, we know that resources are allocated and managed by processes. Processes run in independent spaces, which are closed and independent from each other. Then the problem arises. In a complicated operating system, what should we do if tasks need to be completed collaboratively between processes? This must involve process resource sharing and information interoperability. This requires the operating system to provide the IPC between processes. We know that there are many inter-process communication mechanisms in Linux: named pipelines, shared memory, sockets, signals, and so on. But none of these things will appear in Android. Hey, because Android provides a completely new communication mechanism: binder. Why is it brand new? Because it is based on openbinder, It is a castrated version of openbinder. Haha... you will know what a binder is. But why is it a binder?

Why is binder?

Is it more than a binder than Linux? Obviously, when Android runs on any device, it is clear to everyone: embedded devices. It only has limited resources. Binder is efficient, concise, and fast. These advantages are especially important at this time. Of course, there are other more important advantages. But more importantly, Google chose it. In fact, I personally think the pipeline is also good.

Initial binder driver

In this topic, I will not elaborate on the Binder Mechanism and the entire runtime framework first, because this is clearly explained on the Internet. It is very clear. I will be involved in later sections. Because I am a driver. So I tend to start from the underlying layer and from the binder driver. From bottom to top. Will analyze some important functions. This is because I have studied this document.CodeIt is a pleasure to have such a detailed code instruction document. However, I found that such information is rare on the omnipotent Internet. I think my later users or those who are equally interested should have the same idea or confusion. So I want to share something I know with you. Of course, not all of them are correct. Therefore, we welcome all people to criticize and correct them.

More and more. Answer the question. To complete IPC, binder uses aidl to describe interfaces between processes. In actual implementation, the binder exists as a portable device, and the device node is/dev/binder. It complies with the standard Linux Device Driver Model. The implementation code is in the following path: kernel/Drivers/staging/binder. h kernel/Drivers/staging/binder. C. During the implementation of the driver, binder_ioctrl is used to interact with the user space. We know that the CMD parameter of ioctrl can be used to differentiate different requests. The binder_thread_write function is used to send requests and return results. The binder_thread_read function is used to read the results. I will not talk about the binder objects and references here. You can check them online. However, I will refer to another blog post to describe the binder driver. (The content in the quotation marks below is to reference others' Blog content, the address is http://www.baidubuqing.com/node/212)

"

in modern operating systems, the address space of a process is fixed, and the address is unambiguous. A pointer in a process corresponds to a memory address, it is impossible to correspond to multiple addresses at the same time. Given a pointer, you can get what you want. But in the case of cross-process, things are completely different. The linear address space of different processes is the same. The pointer in one process is placed in another process, which is totally different. To implement cross-process pointers, you must use the operating system layer to map the addresses in one process to the addresses in another process only at the underlying system layer, this is what the binder driver does. Cross-process pointers (directly recorded as binder below) can exist in two ways: exist in local processes and exist in remote processes, what the driver does is to convert the two existing methods. When process a wants to use a binder that lives in process B, the driver finds the local process representation of the binder based on the representation of the binder in process a and obtains the process and actual pointer, then let it meet the requirements of process.
because the binder has these two different methods, when writing a Program , you must identify whether the binder is a pointer to the current process, this creates a lot of trouble for users and loses the original meaning of cross-process pointers. In order to unify user interfaces, both local and remote pointers use a set of interfaces, and C ++/Java shows up. In these two advanced languages, the cross-process pointer is actually a pointer to an object, so the binder is actually upgraded to a cross-process object, you only need to call the function of the object to use the binder. You do not have to worry about whether the object is in the current process or other processes. In terms of implementation, extract the basic operations of this object into basic interfaces and inherit them with two sub-classes respectively. One is used to implement local objects and the other is used to implement remote objects, you can use the basic interface when using the object. You don't have to worry about the process where the object is located. The details below are completed by the C ++ binder library. On the other hand, due to the existence of JNI, the Java-layer Binder on which Android applications rely to survive is actually implemented by calling C ++. Therefore, Android binder has half of the credit for being the binder Driver (kernel/Drivers/staging/Android/binder. c), and the other half of the credit belongs to the C ++ binder Library (Framework/base/libs/binder). The specific details of this library will be written later.

Two binder methods exist. One is the method of presence in the local process. In the local process, it is very simple. It can be expressed with a pointer of its own, but from the driver perspective, A pointer in a process is not enough. The driver must distinguish the pointer of all processes and add a parameter. Because the process itself is unique in the operating system, therefore, the two parameters in the driver, process and in-process pointer, can uniquely represent a binder. The existence of the binder in the remote process is also represented by a binary group in the driver. The first dimension is still the process, and the driver must know which remote process is maintained, the second dimension is a number, which is called ref, handle, and desc. (DESC can be written as DESC to avoid confusion.) It is a number that is programmed from 0, it is only related to the order of appearance of the binder in this process. The first non-local (remote) Binder in the process is remembered as 0, the second is remembered as 1, and so on, it has nothing to do with the actual pointer of the process where the binder actually resides. All remote binder in a process is sorted in a unified manner.

"

After reading the above, I will go directly to some of the key points I will be involved in: The description of important data structures and functions.