Android Binder Mechanism (1): Binder Architecture Analysis

Starting from this blog, will go into the Binder Mechanism Analysis series, the order is to explain the framework of the binder mechanism, after understanding the overall idea, then deep analysis of the details of the implementation of each layer, and finally to achieve a local service.

The history of 1.Binder
BeOS is an operating system run on BeBox hardware developed by be company in 1991, unlike other operating systems in the same period, which is a GUI-based design operating system.

george Hoffman (can find this guy on LinkedIn, it's a living legend) was an engineer at the time, and he started a project called Openbinder, The aim of the project is to study an efficient signal-transfer tool that allows each constituent element of the software to communicate signals to each other, thus enabling multiple software to work together to form a software system. After being was acquired by Parmsource Company, Openbinder was developed by Dinnie Hackborn and later became the basis of the process of managing ParmOS6 Cobalt OS. After Hackborn joined Google, he developed Android Binders (hereinafter referred to as Binder) based on Openbinder to complete Android process communication.

Binder was originally an IPC (Inter Process Communication) tool, but it was primarily used in Android to support RPC (remote Procedure call, remotely called), Making the current process invoke the function of another process is as easy and simple as calling its own function.

2.Linux memory space with binder Driver

Android is a Linux kernel-based operating platform, and the Android process, like the Linux process, only runs in the virtual address space inherent in the process. A 4GB virtual address space, where 3GB is the user space, and the remaining 1G is the kernel space (which can be modified by the kernel settings). User code and related libraries run in the code area, data region, and stack area of the user space, and the code running in kernel space runs in each area of the kernel space. Also, the process has its own separate address space, which runs separately.

So how does a process with independent space pass data to another process? It is clear that you want to share kernel space through two processes. Although each process has its own separate user space, the kernel space is shared. From the kernel point of view, the process is just a unit of work, although the user space of each process is independent of each other, but the task data and code running in the kernel space are shared with each other.

In fact, the structure of the binder mechanism is as follows:

The following is a description of each abstraction layer:

• Service layer: This layer contains a series of service functions that provide specific functionality. The service client actually calls the service function of the Proxy service object, and the actual call is made by service server, which is the services server that actually invokes the service client request.
• RPC Layer: The service client generates RPC code and RPC data for calling service functions at that layer. Service server looks for the appropriate function based on the RPC code passed in and passes the RPC data to the found function.
• IPC Layer: The layer encapsulates RPC code generated by the RPC layer with RPC data into binder IPC data so that they are passed to binder Driver;
• Binder driver Layer: Receives binder IPC data from the IPC layer, locates the service server that contains the specified services, and passes the data to the service server found.

3. Why the IPC is implemented using the binder mechanism

Students who have learned Linux know that, in Linux, there are already pipelines, message queues, shared memory, semaphores, sockets and other IPC communication mechanisms, why Google chose Binder, instead of using the original IPC mechanism?

The main reasons are as follows:

1) Binder transfer efficiency and operability is very good
The socket is excluded due to its low transmission efficiency. Message queues and pipelines are also stored-forwarded, using them for IPC communication, which requires 2 memory copies, which is inefficient.

Why do Message Queuing and pipeline data transfer take 2 memory copies? First, the data is copied from the sender's cache (that is, the user's storage space in Linux) to the memory-opened buffer (i.e., the Linux kernel storage space), which is the 1th time. Next, copy from the kernel buffer to the receiver's cache (which is also the user's storage space in Linux), which is the 2nd time copy.

In the case of a binder mechanism, only 1 copies are required, since the buffer from the sender is copied to the kernel's buffer, and the receiver's buffer is mapped to the same physical address as the kernel's buffer, so it requires only 1 copies.

While the shared memory mode, although using it for IPC communication, the number of memory copies is 0, but because of complex operation, it is not used.

2) The binder mechanism is able to implement the Client-server architecture well
For Android, Google wants to provide a set of client-server-based communications.
For example, different services, such as the MediaPlayer service, the Camera service, are provided by different servers, and when the client needs to obtain a server's service, only the client is required to send the appropriate request to the server. After the server receives the request, it processes, and then sends the feedback content to the client.

However, the current Linux supported pipeline, Message Queuing, shared memory, semaphores, sockets and other IPC means, only the socket is the client-server mode of communication. But the socket is mainly used for inter-network communication and low-speed communication between processes in this machine, its transmission efficiency is too low, not suitable for high-speed IPC communication.

3) High security of binder mechanism

The traditional Linux IPC mechanism does not have any security measures and relies entirely on the upper layer protocol to ensure it. The receiver of the traditional IPC is unable to obtain the reliable uid/pid of the opponent's process, so that the identity of the other party cannot be identified. The binder mechanism assigns uid/pid to each process as an identification identifier, and the binder communicates the validity of the uid/pid.

4.UML figure

The binder mechanism involves the proxy class, the stub class, and the Ipcthreadstate class that talks to binder driver, and the overall UML diagram looks like this:

• ibinder, Bbinder, Bpbinder:ibinder class is an abstraction of Android binder, it has bbinder, bpbinder two children. Where the Bbinder class is responsible for receiving RPC code and data and generating binder nodes inside Binder driver. The Bpbinder class holds the handle information for the target service for binder driver in the process of finding a binder node for service server;

• iinterface, Bninterface, bpinterface:iinterface classes provide type transformation capabilities to convert a service or service proxy class to a IBinder type. The actual type conversion is done by the Bninterface, bpinterface two classes, Bninterface converts the service class to the IBinder type, and Bpinterface converts the service proxy class to the IBinder type. When passing binder objects through binder driver, type conversions must be performed, such as when registering a service with the system, you need to convert the service class to ibinder before transmitting it to the context Manager.

• processstate, ipcthreadstate:processstate classes are used to manage binder Driver,ipcthreadstate classes to support service clients, The binder IPC communication between Service server and binder driver;

• parcel: The Parcel class is responsible for preserving binder IPC data when BINDERIPC between service and service agents. The parcel class can handle data with the basic data structure of C language, an array of basic data structures, binder objects, file descriptors, and so on.

• Service Manager and Context Manager

There are a variety of services in the Android system, such as the audio Flinger service that manages the AV device, the Surface Flinger service that manages the frame buffer device, and the camera service that manages the cameras ' devices. The information and directories for these services are managed by the context manager.

Service Manager, however, is the equivalent of the Services agent for context manager. It is important to note that Service Manager is divided into service manager that manages the Java System Services and service Manager that manages the local system services. It's a good indication of their relationship:

• java system service is registered through the service manager of the Java layer, and the local system service is registered with the service Manager of the C + + layer;
• java layer is connected through JNI to service Manager in the C + + layer, and service Manager Driver with the context manager for Binder RPC;

6. Key structure of kernel space

The binder design of the kernel space has 3 very important structures: Binder_proc, Binder_node and Binder_ref. In the back there will be a blog devoted to analyzing them, here is just a brief talk about their role. Their role is as follows:

• Binder_proc is a description of the process context information, and each user-space process corresponds to a binder_proc struct
• Binder_node is the structure of binder entity, it is the embodiment of server in Binder drive.
• Binder_ref is the corresponding structure of binder reference, which is the embodiment of client in Binder drive.

1) Binder entity The red-black tree is the binder entity that holds the binder_proc corresponding to the process, and the binder entity corresponds to the server's service. The binder entity red-black tree can be understood as a red-black tree of server services included in the server process;
2) There are two binders referencing the red and black trees, and the two trees contain the same binder references. The difference is that the red-black tree has a different sort datum, one is sorted by binder entity, and the other is sorted by binder reference description (the binder reference description is actually a 32-bit integer number). The red and black trees described in binder references are designed to facilitate quick lookups.

is the binder_node structure of the body:

Android Binder Mechanism (1): Binder Architecture Analysis