Android Binder Design and Implementation 2

4 Binder Protocol

The basic format of the Binder protocol is (command + data). The ioctl (fd, cmd, arg) function is used for interaction. The command is carried by the cmd parameter, and the data is carried by the arg parameter, which varies with the cmd parameter. The following table lists all commands and their corresponding data:

Table 2 Binder communication command words

Command	Description	Arg
BINDER_WRITE_READ	This command writes or reads data to the Binder. The parameters are divided into two sections: write and read. If write_size is not 0, write the data in write_buffer to the Binder first. If read_size is not 0, read the data from the Binder and store the data in read_buffer. Write_consumed and read_consumed indicate the number of data written or read by the Binder driver when the operation is completed.	Struct binder_write_read { Signed long write_size; Signed long write_consumed; Unsigned long write_buffer; Signed long read_size; Signed long read_consumed; Unsigned long read_buffer; };
BINDER_SET_MAX_THREADS	This command tells the Binder driver receiver (usually the Server side) the maximum number of threads in the thread pool. Because the Client sends requests to the Server concurrently, the Server must open a thread pool to provide services for these concurrent requests. The maximum value of the driver thread pool is used to prevent the receiver from starting a new thread when the driver thread reaches this value.	Int max_threads;
BINDER_SET_CONTEXT_MGR	Register the current process as SMgr. Only one SMgr can exist in the system. As long as the current SMgr does not call close () to close the Binder driver, no other process can become SMgr.	-
BINDER_THREAD_EXIT	Notifies the Binder driver that the current thread has exited. The Binder establishes a data structure for all threads involved in the Binder communication, including the threads in the Server thread pool and the threads in which the Client sends requests. When these threads exit, they must notify the driver to release the corresponding data structure.	-
BINDER_VERSION	Obtain the version number of the Binder driver.	-

 

The most common command is BINDER_WRITE_READ. The parameters of this command include two parts: one is the data written to the Binder, and the other is the data to be read from the Binder. The driver first processes the write part and then the read part. The advantage of this arrangement is that the application can flexibly process synchronous or asynchronous commands. For example, if you want to send an asynchronous command, you can enter the write part and set read_size to 0. If you want to obtain data only from the Binder, you can set the write part to null, that is, write_size to 0; if you want to send a request and wait for the returned data to be synchronized, you can set both parts.

4.1 BINDER_WRITE_READ write operation

The format of data written by the Binder is the same as that of command + data ). At this time, commands and data are stored in the memory space pointed to by the write_buffer field of the binder_write_read structure. Multiple commands can be stored continuously. The data is stored after the command, and the format varies with the command. The following table lists the commands supported by the Binder write operation:

Table 3 Binder write command words

Cmd	Description	Arg
BC_TRANSACTION BC_REPLY	BC_TRANSACTION is used to write request data; BC_REPLY is used to write reply data. Followed by a binder_transaction_data struct, it indicates the data to be written.	Struct binder_transaction_data
BC_ACQUIRE_RESULT BC_ATTEMPT_ACQUIRE	Not implemented yet	-
BC_FREE_BUFFER	Releases a mapped memory. The Binder receiver maps a large memory space through mmap (). The Binder driver uses the best matching algorithm to dynamically allocate and release the received data cache, this satisfies the requirements of concurrent requests for receiving cache areas. After processing this piece of data, the application must use this command to release the cache area as soon as possible. Otherwise, new data cannot be received because the cache area is exhausted.	Pointer to the cache to be released; the pointer is located in the received Binder Packet
BC_INCREFS BC_ACQUIRE BC_RELEASE BC_DECREFS	This set of commands increase or decrease the reference count of the Binder to implement the function of strong or weak pointers.	32-bit Binder reference number
BC_INCREFS_DONE BC_ACQUIRE_DONE	When the Binder entity reference count is added for the first time, the driver sends the BR_INCREFS and BR_ACQUIRE messages to the process where the Binder entity is located. After the processing of the process where the Binder entity is located, the feedback BC_INCREFS_DONE and bc_acqu	Void * ptr: pointer of the Binder object in the user space Void * cookie: additional data related to the object
BC_REGISTER_LOOPER BC_ENTER_LOOPER BC_EXIT_LOOPER	This group of commands, together with BINDER_SET_MAX_THREADS, enables the Binder driver to manage the thread pool of the receiver. Bc_register_loternotifies the driver that a thread in the thread pool has been created. BC_ENTER_LOOPER notifies the driver that the thread has entered the main loop and can receive data. BC_EXIT_LOOPER notifies the thread to exit the main loop and no longer receive data.	-
BC_REQUEST_DEATH_NOTIFICATION	The process that obtains the Binder reference requires the driver to be notified when the Binder object is destroyed. Although a strong pointer can ensure that objects are not destroyed as long as there is a reference, it is a cross-process reference, no one can guarantee that the entity disappears because the Server where it is located closes the Binder driver or exits abnormally. What the quotor can do is to ask the Server to give a notification at the moment.	Uint32 * ptr; Binder reference to be notified of death Void ** cookie: the message related to the death notification. The driver returns the message to the requesting process when a death notification is sent.
BC_DEAD_BINDER_DONE	The process that receives the entity death notice will use this command to notify the driver after deleting the reference.	Void ** cookie

 

Among these commands, the most common is the BC_TRANSACTION/BC_REPLY command pair, through which the Binder data is sent to the receiver. The packet carried by the command is defined by the struct binder_transaction_data. Binder interaction can be divided into synchronous and asynchronous operations, which are distinguished by the flag domain in binder_transaction_data. If the TF_ONE_WAY bit of the flag domain is 1, it is Asynchronous interaction. That is, after the Client sends the request interaction, the Server no longer returns the BC_REPLY packet; otherwise, the Server returns the BC_REPLY packet, the Client must wait for the received data packet to complete the interaction.

4.2 BINDER_WRITE_READ: reads data from the Binder.

The data format read from the Binder is the same as the data format written to the Binder. It adopts the (Message ID + Data) format and multiple messages can be stored continuously. The following table lists the command words read from the Binder and their corresponding parameters:

Table 4 Binder read operation Message ID

Message	Description	Parameters
BR_ERROR	Internal error (for example, memory allocation failure)	-
BR_ OK BR_NOOP	Operation completed	-
Br_spawn_low.	This message is used to manage the thread pool of the receiver. When the driver finds that all the threads in the receiver are busy and the total number of threads in the thread pool does not exceed the maximum number of threads set by BINDER_SET_MAX_THREADS, the driver sends this command to the receiver to create more threads for receiving data.	-
BR_TRANSACTION BR_REPLY	The two messages correspond to the sender's BC_TRANSACTION and BC_REPLY respectively, indicating that the currently received data is a request or a reply.	Binder_transaction_data
BR_ACQUIRE_RESULT BR_ATTEMPT_ACQUIRE BR_FINISHED	Not Implemented	-
BR_DEAD_REPLY	This message is returned if the other process or thread is dead during interaction.	-
BR_TRANSACTION_COMPLETE	After a packet is sent through BC_TRANSACTION or BC_REPLY, the sender can receive the message as a feedback for successful sending. This is different from BR_REPLY. The driver tells the sender that the message has been sent successfully, rather than the receiver returning the request data. Therefore, both the synchronous and asynchronous interaction receivers can obtain the message.	-
BR_INCREFS BR_ACQUIRE BR_RELEASE BR_DECREFS	This group of messages is used to manage reference counts of strong/weak pointers. Only processes that provide the Binder entity can receive this group of messages.	Void * ptr: pointer of the Binder object in the user space Void * cookie: additional data related to the object
BR_DEAD_BINDER BR_CLEAR_DEATH_NOTIFICATION_DONE	Send a notification of the death of the Binder entity to the process referenced by the Binder. The process receiving the notification will return BC_DEAD_BINDER_DONE for confirmation.	Void ** cookie: additional parameter used to register a death notification using BC_REQUEST_DEATH_NOTIFICATION.
BR_FAILED_REPLY	If an invalid reference number is sent, the message is returned.	-

 
Like writing data, the most important message is BR_TRANSACTION or BR_REPLY, indicating that a request packet (BR_TRANSACTION) or returned packet (BR_REPLY) in the format of binder_transaction_data is received ).

From LuoXianXiong, your partner