Binder Summary 1-Binder principle
Basic usage and principles of Binder should be learned, including:
-
The concept of Linux processes and Spaces
-
Virtual Address concept
-
Commonly used IPC, their basic process and Binder difference
-
The basic idea of C/S architecture is Binder driver, ServerManager, Client and Server.
-
AIDL and supported data types, including Parcelable, as well as writing
-
Service(one of the four components of Android), Binder, and several specific Java classes.
The following is a summary of my Binder learning. If there is infringement, please contact to delete it.
Linux process and space concepts
In Linux, a process is the minimum description assigned to an application to run. That is, there is at least one process in an application, and at least one thread between processes, and the process allocates memory space to the application.
Space: To maintain system stability, Linux is divided into the kernel space and user space. The kernel space has the highest permissions, and the user space has the lowest permissions. Such as reading and writing files, network requests are made in kernel space.
In Linux, there is process isolation, where process A cannot directly access process B’s data and they have separate memory. If they need to communicate, they must do so through IPC, mainly through two methods :copy_from_user and copy_to_user.
A virtual address
When allocating memory to an application, it is a contiguous piece of memory for the application, but in reality, the memory space mapped to the physical memory is fragmented and discontiguous. This contiguous space is realized through virtual addresses. Virtual addresses make the application appear to have contiguous memory space that maps to specific physical memory.
For example, on a 32-bit system, the addressable space is 2 to the power of 32, or 4GB.
Traditional IPC
Include:
-
The Shared memory
-
Sources in
-
Socket
-
A semaphore
These are common IPC methods, and in general, they will undergo two copies of data, excluding shared memory.
The first time is when the sender copies the data into kernel space via copy_FROm_user. This is the first time. The receiver then allocates a cache in its own memory space and copies the data from the kernel space to itself for reading using copy_to_user.
The diagram below:
For Android system, the above methods are not suitable. First, there are problems with two data copies:
-
Multiple copies take time
-
The receiver does not know how much memory it needs to allocate to receive data, or it needs to notify the receiver of the allocation in advance, which takes time.
For shared memory, although it does not need copy, it is difficult to control and has poor security.
What is Binder’s advantage in this regard?
-
Binder is only required to copy data once, just below shared memory.
-
It is based on C/S structure, with separate responsibilities and mutual independence, and better stability.
-
In terms of security, the traditional IPC receiver cannot obtain the reliable process PId of the other party, so it cannot identify the other party. On Android, however, it assigns its own UID to each installed App to authenticate it.
Binder is the Android system’s IPC method. So why does Binder only make one copy of data?
This is using virtual memory. Binder uses memory mapping to perform a layer of memory mapping between the kernel space and the data cache in the receiver’s user space. That is, when the sender copies the data to the memory space, the address of the kernel space is also mapped to the memory cache of the receiver, so that there is one less copy from the inner space to the user space.
The diagram below:
Communication principle of Binder
In Binder, there are four concepts: Binder driver, ServerManager, Client, and Server. These four components make up the BinderC/S architecture.
It is similar to a network request: a Client initiates a request using a domain name, resolves the specific IP address using the DNS domain name resolver, and forwards the request to a specific Server through a route. The Server then forwards the request to the Client through a route.
In Binder’s IPC, there are the following parts:
- Binder drive
The Binder driver is a virtual character device registered in /dev/bindr that defines a set of Binder communication protocols responsible for inter-process communication and provides low-level support for packet transfer between processes.
Its role is similar to that of routing, which provides low-level support for interprocess communication. Forwards requests from the Client to the Server and returns data from the Server to the Client.
2 ServerManager
It functions like a DNS Server, translating the Binder description of the Server requested by the Client into a specific Server address so that the Binder driver can forward the Client request to the Server. When a Server needs to provide a service, it must register with ServerManager. In this way, ServerManager has a copy of key-value data. Saves a mapping of Server’s Binder character names and Binder references for clients to find.
- Client
The Client sends a request to the ServerManager through Binder to obtain the Server address, which is then forwarded by the Binder driver.
- Server
If a Server needs to provide services externally, it needs to register itself with ServerManager so that it can be resolved. After the Server responds to the request, it passes the data to the Client again using the Binder driver.
This is a complete IPC call.
Another problem is the generation of ServerManager, because Client/Server need to communicate with ServerManager through Binder, so how is the generation of ServerManager?
-
After the Android system starts, a process named ServerManager is created. In the ZygoteInit file, the forkSystemServer of Zygote is called in the main method. It registers with the Binder driver to become ServerManager through a convention command, BINDERSERVER_MGR. The Binder driver automatically creates a Binder entity for ServerManager
-
The reference to the Binder entity is 0 in all clients, which means that each Client communicates with the ServerManager through a reference of 0.
Binder’s proxy mechanism
In this process, the Client needs to obtain A Binder reference from the Server side. Is this A real Server reference? How to achieve this? This is done with Binder’s proxy mechanism.
The Binder driver does not return the actual Server’s Bind reference to the Client. The Binder driver does not return the Server’s Bind reference to the Client. Instead, it returns a proxy Java object that has the same method signature as the Binder references on the Server side. This object is a ProxyObject that has the same methods as the Binder instances on the Server, except that they don’t have server-side capabilities. The ProxyObject is capable of being driven by Binder and is implementing calls to Server’s Binder to complete data transfer.
For example, when the Binder driver receives the request from the Client process, it queries the Server in ServerManager. After finding the specific Server in ServerManager, it creates a ProxyObject of the Binder object on the Server side. The ProxyObject is returned to the Client. The Client then calls its methods through ProxyObject, and the ProxyObject method calls Binder driver, which calls the Server process’s specific Binder object methods. The Binder driver then returns the data to the Client.
The following figure
AIDL
Above, we have roughly combed the overall process of Binder invocation and know the general principle of Binder. In Android, this is done through AIDL, a descriptive interface language.
What is AIDL:Android Interface Definition Language
Details on how to use AIDL will be covered in the next article.
Refer to the article
Binder: All you need to know about Binder as an application developer (and source of this article’s images)
Why did Android adopt Binder as an IPC mechanism
Binder series – The Beginning
Binder interprocess Communication with Android
Binder principle analysis for Android application engineers