Android System Binder Mechanism Learning Summary

I. Overview of the binder mechanism

In Android development, many times we need to use inter-process communication, so-called interprocess communication, the mechanism to achieve inter-process communication, such as sockets, pipes, etc., there are three ways to communicate between processes in Android:

1. Standard Linux Kernel IPC interface;

2. Standard D-bus interface;

3.Binder interface.

The binder mechanism is the most and most recognized, because the binder mechanism has the following advantages:

1. The binder mechanism is more concise and faster than other IPC mechanisms;

2. less memory consumption;

3. Traditional IPC mechanisms can increase the overhead of processes, as well as process overloading and security vulnerabilities, and the binder mechanism effectively avoids and solves these problems.

Binder mechanism is the core mechanism of Android system, almost throughout the entire Android system, Android system basically can be regarded as a binder based on the communication mechanism of C/s architecture, binder like the network, Connect the various parts of the Android system together. With the binder mechanism, you can implement the following functions:

1. Use drivers to advance interprocess communication;

2. Improve performance by sharing memory;

3. Allocate the thread pool for each process for process requests;

4. Reference counting and object reference mappings across processes are introduced for objects in the system;

5. Inter-process synchronous invocation.

Ii. Workflow of the binder mechanism

1. The client obtains the object (proxy) of the server. We need to be clear that the client process does not directly manipulate the methods in the server, if you want to operate the service side of the method, then there is a feasible solution is to establish a server-side process proxy object, the proxy object has the same function as the server process, to access a method in the server process, You only need to access the corresponding method in the proxy object;

2. The client sends a request to the server by invoking the proxy object.

3. The proxy object sends the user request through the binder driver to the server process;

4. The server process handles the request sent by the client, and after processing it returns the processing result to the client's server proxy object through binder driver;

5. The proxy object further returns the request result to the client process.

With the above 5 steps, a binder communication is completed.

Iii. composition of the binder mechanism

The binder mechanism consists of three parts, namely:

1.Client;

2.Server;

3.ServiceManager.

The relationship between three parts of a component:

1.Client, Server, ServiceManager are implemented in user space, while binder driver is implemented in kernel space;

2. In binder communication, the server process registers some service to ServiceManager, and ServiceManager is responsible for managing the service and providing the client with the relevant interface;

3.Client process to communicate with a specific service, you must first obtain information about the service from ServiceManager, and the client establishes communication with the server process where the service resides based on the service information received. The clent can then interact with the service;

The 4.Binder driver provides the device file/dev/binder to interact with the user space, and the Client, server, and ServiceManager communicate with the binder driver through the open and IOCTL file manipulation functions;

5.Client, Server, servicemanager the interaction between the three is based on binder communication, so through any of the relationship between the two, can explain the mechanism of binder.

Iv. Introduction to binder driven implementation.

The 1.Binder uses Aidl to describe the interface between processes;

The 2.Binder is a special character device with a device node of Dev/binder.

The 3.Binder driver is implemented by the following two files:

①kernel/drivers/staging/binder.h

②kernel/drivers/staging/binder.c

4. In the implementation of binder drives, the following functions play a key role:

① uses the Binder_ioctl () function to Exchange data with the user space;

②binder_write_read is used to read and write data, and the CMD field in the packet is used to distinguish different requests;

③ uses the Binder_thread_write () function to send a request or return a result, in the Binder_thread_write () function, by calling Binder_transaction () function to forward the request and return the result. When the request is received, the binder_transaction () function locates the process of the object through the handle of the object, and if the handle result is empty, the object is considered context_mgr, and the request is sent to the context The process in which the _mgr is located, puts all binder objects in the request into the RB tree, and finally puts the request into the queue of the target process to wait for the target process to read. ；

④ uses the Binder_thread_read () function to read the results;

⑤ implements data parsing in function Binder_parse ().

V. Data structures in Binder drivers

1.binder_work. Binder_work represents the work item to be processed by the process in Binder drive.

2.binder_node. Binder_node is used to define binder entity objects. Each of the Srevice components in the Android system corresponds to a binder entity object in the binder driver. The binder entities in the drive are also called "nodes", and you are the process of providing entities;

3.binder_ref. Binder_ref is used to describe a binder reference object. Each client component in the Android system corresponds to a binder reference object in the binder driver;

4.binder_ref_death. Binder_ref_death is a notification structure. As long as a process subscribes to the death notification of a binder referencing the corresponding entity, the binder driver creates a Binder_ref_death notification struct for the binder reference, saving it in the death domain of the corresponding binder reference structure of the current process. The Binder Reference object registers the death notification in the binder driver. There is a mechanism for the death notification of binder, which refers to the mechanism of the death notification of Binder: If the Binder entity object dies unexpectedly, the reference to the Binder entity object becomes invalid. Therefore, it is necessary to notify the binder object when it dies, to prevent and solve the problem of invalid binder drinking object to some extent;

5.binder_buffer. Binder_buffer is used to describe a kernel buffer that can transfer data between processes;

6.binder_proc. Binder_proc represents a process that is using the binder process communication mechanism to hold the information of each process or thread calling binder, such as thread ID, process ID, binder state information, and so on;

7.binder_thread. The binder_thread is used to store information for each individual thread, representing a thread in the binder thread pool;

8.binder_transaction. Binder_transaction is used to relay requests and return results, and to save incoming and outgoing process information;

9.binder_write_read. Binder_write_read represents data transmitted during communication between processes, and a CMD field in the packet is used to distinguish between different requests;

10.BinderDriverCommandProtocol. The commands contained in the struct binder_write_read are defined in the Binderdrivercommandprotocol;

11.BinderDriverReturnProtocol. The read operation command protocol is defined in Binderdriverreturnprotocol;

12.binder_ptr_cookie. Binder_ptr_cookie represents the death receive notification for a Binder entity object or service component;

13.binder_transaction_data. Binder_transaction_data represents the data transmitted during the communication process;

14.flat_binder_object. Flat_binder_object represents a Binder object. In an Android system, the data passed between processes is called a Binder object.

Vi. detailed implementation of binder.

1. Initialization of the device. The device initialization function of the binder mechanism Binder_init is located in Inder.c, and Binder_init invokes the device driver interface function Device_initcall when the device is initialized;

2. Open the device file. Binder mechanism, the function binder_open is used to open Binder device file/dev/binder. In an Android system, any process and thread of the driver can open a binder device, and the Binder_open function, in contrast to the Binder_release function, is used to free open space and the space allocated during the operation;

3. Implement memory mapping. After opening the binder device file/dev/binder, you need to call function mmap () to map the device memory to the user process address space, so that you can manipulate the device memory as you would the user memory. In binder devices, there is a limit to the mapping operation of memory, such as binder can not map the memory area with write permission, the maximum can map the memory area of 4MB;

4. Release the physical page. In the binder mechanism, the function binder_insert_free_buffer () is used to insert buffer in the process into the process information, and a free kernel buffer is added to the red-black tree of the free kernel buffer in the process;

5. Processing Kernel buffers:

①*binder_alloc_buf () is used to allocate kernel buffers;

②binder_insert_allocated_buffer () is used to add the allocated kernel buffer to the kernel buffer of the allocated physical page of the target process in the red-black tree;

③binder_free_buf () is used to release the kernel buffer operation;

④*buffer_start_page () and *buffer_end_page () are used to calculate the address of the virtual page occupied by the structure Binder_buffer;

⑤binder_delete_free_buffer () is used to remove structure binder_buffer;

⑥*binder_buffer_lookup () queries a kernel buffer based on a user-space address.

Vii. Binder Packaging Library

Android source code, the various levels have binder related implementations, which are mainly implemented by native natively, the other level of binder implementation is called the native Binder library to achieve.

The various levels of binder implementations are:

1.Binder Drive section. The implementation functions are as follows:

① Organization Binder service and where;

② calls binder-related processing threads;

③ complete the actual binder transfer.

2.Binder adapter layer. Binder Adapter layer is a binder-driven package, the main function is to operate the binder driver, so the application does not need to be directly associated with binder driver. The associated files include some content in IPCThreadState.cpp, ProcessState.cpp, and Parcel.cpp. Binder Core Library is the core implementation of the binder framework, mainly including IBinder, Binder (server side) and Bpbinder (client).

3. Top layer. The top-level binder framework and the specific client.

Three-layer structure

Android System Binder Mechanism Learning Summary