Essentials of Android Binder driver's Working Mechanism

Essentials of Android Binder driver's Working Mechanism

Recently, I have read many books, articles, and Android source code for Android Kernel Analysis. I feel that I have a thorough understanding of the working mechanism of Android Binder.

 

However, it takes a lot of time and effort to achieve this. For most people, I am afraid it will not be as easy as I am to spend so much money to understand this. Therefore, I would like to give a brief introduction to the working mechanism of the Android Binder driver, so that you do not have to spend too much time to understand its purpose.

 

1. Let's first introduce the problems to be solved by the Binder Driver.

The Binder driver must solve the problem of small-scale data transmission between different processes running in the same Android operating system.

Note: Android uses the Android Shared Memory Driver to solve the problem of large-scale data transmission between different processes. The Binder Driver is used to transmit small-scale data (for example, dozens of bytes to dozens of KB ).

Android Driver is the kernel part of the entire Android Binder system. The Android Binder system aims to provide an object-oriented API for communication between different processes running in the same Android operating system, similar to Microsoft DCOM or CORBA. To provide such an object-oriented API, Android requires an efficient inter-process communication mechanism, which is the purpose of the Android driver.

 

2. Why don't we directly use the Linux shared memory mechanism to transmit data between processes?

This is because, in addition to data transmission, Android also needs this Driver to support the following features.

1. Security Mechanism: only specific users and processes can access this data. Linux shared memory does not support this mechanism.

2. Reference count: The corresponding Server process can release the memory only when the Client process no longer needs it. Linux shared memory does not support this mechanism.

3. In addition, the Android Binder driver also supports the descriptor transmission of exaggerated processes. In this way, a process can directly read the files opened by another process, instead of reading the file content to the memory and then copying it to another process.

 

Iii. virtual memory space of Linux Processes

The following uses the x86 CPU Linux implementation as an example to review the knowledge about virtual memory space of Linux processes.

1. Each process has 4 GB of virtual memory space

2. The 4G space is divided into two parts. 0 ~ 3G is the User Space, 3 ~ 4G is the Kernel Space ).

3. For 0 ~ For 3G user space, Linux maps different processes to different physical memory. For example, the physical address pointed to by process A's virtual address 0x01234567 is different from the physical address pointed to by process B's virtual address 0x01234567. This is the so-called process isolation.

4. For 3 ~ 4 GB kernel space. Linux maps all processes to the same physical memory. In other words, the virtual address 0xC1234567 of process A and the virtual address 0xC1234567 of process B point to the same physical address. In this part of the virtual memory space, user-State processes cannot be accessed. Only processes that switch to the kernel-state can access 3 ~ of a process ~ 4 GB kernel space.

 

 

Iv. exact meaning of transferring data from process A to process B

To transfer data from process A to process B is to transfer A user space of process A (0 ~ 3G) content is copied to a user space of process B (0 ~ 3 GB) memory.

 

Therefore, to copy data from process A to process B, we need:

1. Switch to the kernel state. Because only the kernel state can access the user State Space of all processes.

2. read data from the user space of process.

3. Find a memory space in the user-state space of process B, allocate physical memory to it, and then copy the data to the physical memory.

4. Then process B can read data from its user space.

 

5. How does the Binder Driver transmit data between processes?

In fact, what the Binder driver has to do is the steps listed above.

However, for each process, the Binder driver will find a user-state and kernel-state memory space for each process through the ioctl system call after the process opens the binder driver, and use it as the Binder buffer.

Note that for a process, the Binder buffer is mapped to the same physical memory address in the user and kernel states.

 

Next, let's take a look at how data is transmitted between two processes that use the Binder for communication:

1. The Client process has a piece of memory to pass to the Server process.

2. Switch to the kernel state

3. Binder driver reads the user space of the Client process (0 ~ 3 GB) memory content

4. The Binder driver copies the read content to the Binder buffer of the Server process.

5. Then, when the Server process is executed, it can be in its user space (0 ~ 3G) read the passed content. Because the Binder Buffer is also mapped to the user-state space of the Server process.

6. After the Server process finishes processing the read messages, it needs to store the processing results in the memory of a user-state space and want to return them to the Client process.

7. Switch to the kernel state

8. Binder driver reads the user space of the Server process (0 ~ 3G) processing result

4. The Binder driver copies the read content to the Binder buffer of the Client process.

5. Then, when the Client process is executed, it can be in its user space (0 ~ 3G) read the passed content. Because the Binder Buffer is also mapped to the user-state space of the Client process.

 

This is how the Binder driver implements inter-process communication.

As for the details, such as the implementation of the security mechanism, we will not go into detail. For more information about Binder systems, see Lao Luo's article titled source code Scenario Analysis of Android systems. The article contains more than two hundred pages. However, to understand this content, you must have a deep understanding of Linux Kernel.

 

Zookeeper