Understanding Android System Binder Mechanism _android

I. Overview of the binder mechanism

In Android development, many times we need to use interprocess communication, so-called interprocess communication, to achieve interprocess communication mechanism there are many kinds of, such as socket, pipe, and so on, Android in the way of communication between the main three kinds:

1. Standard Linux Kernel IPC interface;

2. Standard D-bus interface;

3.Binder interface.

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

1. Compared with other IPC mechanisms, the binder mechanism is more concise and fast;

2. The memory consumption is relatively less;

3. Traditional IPC mechanisms can increase process overhead and process overload and security vulnerabilities, and the binder mechanism effectively avoids and solves these problems.

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

1. Use the driver to promote interprocess communication;

2. Improve performance by sharing memory;

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

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

5. Synchronous calls between processes.

Ii. The working process of the binder mechanism

1. Client gets the object (proxy) for the server. We need to be clear that the client process does not directly manipulate the methods in the service side, if you want to manipulate the methods in the server side, a viable solution is to create a proxy object for the server process on the client, which has the same functionality as the server-side process, to access a method in the service-side process, Only need to access the corresponding method in the proxy object;

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

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

4. The service-side process processes the request which the client sends over, after processing, returns the processing result to the client by the Binder drive the service end proxy object;

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

Through the above 5 steps, completes one binder communication.

Iii. composition of the binder mechanism

The binder mechanism consists of three parts, namely:

1.Client;

2.Server;

3.ServiceManager.

Relationships between three parts of a component:

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

2. In binder communications, the server process registers some service into the ServiceManager, ServiceManager manages the service and provides the client with the relevant interface;

3.Client process to communicate with a specific service, you must first obtain information about the service from the ServiceManager, the client based on the service information and the server process where the service is located to establish communications, After that, Clent can interact with the service;

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

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

Iv. Introduction to the implementation of Binder drive

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

2.Binder is a special character device, the device node is dev/binder.

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

　　①kernel/drivers/staging/binder.h

②kernel/drivers/staging/binder.c

4. The following functions play a key role in the implementation of the binder drive:

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

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

③ uses the Binder_thread_write () function to send the request or return the result, in the Binder_thread_write () function, by calling Binder_transaction () function to forward the request and return the result. When a request is received, the binder_transaction () function finds the process where the object is located through the object's handle, and if the handle result is null, the object is Context_mgr, and then the request is sent to the context _mgr the process in which it is located and puts all the binder objects in the request into the RB tree, and finally puts the request in the queue of the target process to wait for the target process to read. ；

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

⑤ in function Binder_parse () to implement data parsing work.

V. Data structures in the binder driver

1.binder_work. Binder_work represents the work items that the process will handle in the binder drive.

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

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 soon as a process subscribes to a binder reference to the corresponding entity, the binder driver creates a BINDER_REF_DEATH notification structure for the binder reference, which is saved in the binder domain of the corresponding death reference structure of the current process. That is, the binder reference object registers the death notice in the binder driver. This involves binder's death notification mechanism, Binder's death notification mechanism specifically: if Binder entity objects die unexpectedly, the reference to the Binder entity object will become invalid, Therefore, it is necessary to inform all the proxy objects that refer to it when the binder entity object dies, so as 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 transmits data between processes;

6.binder_proc. Binder_proc represents a process that is using the binder process communication mechanism to hold information about the processes or threads that invoke binder, such as thread IDs, process IDs, Binder state information, and so on;

7.binder_thread. 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 process information received and to be sent;

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

10.BinderDriverCommandProtocol. The binder_write_read contained in the structure body is defined in the Binderdrivercommandprotocol;

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

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

13.binder_transaction_data. Binder_transaction_data represents the data passed in the course of communication;

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

Vi. detailed implementation of binder

1. Initialization of the equipment. the device initialization function of the binder mechanism is binder_init in inder.c, and the device-driven interface function Device_initcall is invoked when the device is initialized binder_init;

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

3. Realize memory mapping. after opening the binder device file/dev/binder, you need to call the function mmap () to map the device memory to the user process address space, so that you can manipulate the device memory as if you were operating the user's memory. In the binder device, the mapping operation of memory is limited, such as binder can not map the memory area with write permission, the maximum can map 4MB memory region, etc.

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

5. Processing kernel buffers :

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

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

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

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

⑤binder_delete_free_buffer () is used to delete structural binder_buffer;

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

Seven, Binder Packaging library

The Android source code, all levels have binder related implementation, which mainly by native native codes, other levels of binder implementation is called the native Binder library to achieve.

The binder is implemented at various levels:

1.Binder Drive Section . Implementation features are as follows:

① Organization Binder service and EH to where;

② calls the binder-related processing thread;

③ completes the actual binder transmission.

2.Binder Adapter Layer . The Binder adapter layer is a Binder-driven encapsulation, with the main function being the operation of the Binder driver, so the application does not need to be associated directly with the Binder driver. The associated file includes some content in IPCThreadState.cpp, ProcessState.cpp, and Parcel.cpp. Binder Core Library is the core implementation of Binder framework, which mainly includes IBinder, Binder (server) and Bpbinder (client).

3. Top floor . Top-level binder framework and specific clients.

This is all about the Android binder mechanism, and hopefully it will help you learn about Android software programming.