Android Binder interprocess communication mechanism 3-binder object life and death

The following is an overview of the four objects involved in binder communication: Binder local object, Binder entity object, Binder Reference object, Binder proxy object life and death.

1. Binder Communication Interaction Process

The 1.Client process issues inter-process communication requests, which are made by the binder driver in the Client process to the binder local object in the server process.

The 2.Binder driver finds the Binder reference object within the binder driver based on the handle value of the Binder proxy object passed over by the client process.

3. Find Binder entity objects based on binder reference objects. At the same time, a binder_transaction structure (transaction) is created for this request to describe the process of communication between the two processes.

The 4.Binder driver locates the binder local object running in the server process based on the found Binder entity object and sends the data sent by the client process to him.

After the 5.Server process finishes processing, the processing results are returned to the binder driver, and the driver writes the results to the binder_transaction created earlier

The 6.Binder driver finds the client process by saving the client information in the Binder_transaction, and returns the communication results to the corresponding Binder proxy object processing.

2, from the above process is known: Binder proxy object depends on Binder Reference object, Binder Reference object depends on Binder entity object, Binder entity object depends on binder local object. Describe how these dependent objects are guaranteed to be menial:

Binder reference objects and binder entity objects are maintained inside the kernel space binder driver. In fact, they are binder_ref and binder_node structures respectively.

Binder proxy objects are maintained within the user space client process. is a Bpbinder object.

Binder local objects are maintained within the user space server process. is a Bbinder object.

The life cycle of a 1.Binder local object.

When referenced by the driver entity object, you should ensure that the reference count for the local object is not 0. When the server process registers a binder local object to Servermanager, the binder driver creates the corresponding entity object (Binder_node) for him. When a cient process queries the proxy object interface of a binder local object, the value of the reference count in Binder_node changes. Binder Driver through functions:

Binder_thread_read

Use protocol Br_increfs,br_acquire,br_decrefs,br_release to communicate with the server process. The communication data is written to a user-space buffer in the server process.

The Ipcthreadstate member function of the server process ExecuteCommand from removing the protocol command and executing it, adding or subtracting the local object's strength reference count to achieve lifecycle management.

Another: Bbinder inherits from the Refbase, the reference in the user space can be managed automatically.

The life cycle of a 2.Binder solid object.

When binders reference objects are created or destroyed, the reference count for the Binder entity object is required because the referencing object references the entity object. Because of the same in kernel space, call Binder_inc_node and Binder_dec_node operation entity object reference, the specific rule reference source code BINDER.C These two functions implementation.

The life cycle of the 3.Binder reference object.

Similar to the life cycle of a local object, use the function binder_thread_write within the binder driver to read the bc_acquire,bc_increfs,bc_release,bc_ of the user-space buffer written by the client Decrefs four protocols increase or decrease the strength reference count of the binder reference object.

The process is to find the corresponding reference object by the handle value passed in by the client process.

The life cycle of the 4.Binder proxy object.

3.Binder object Death notification mechanism:

Process one:

1. Definition of death receive notification, deathrecipient

2. Invoke the Linktodeath registration of the proxy object Bpbinder. The Registered death notification agreement will be notified to the binder driver as soon as the registration is finally called Ipcthreadstate::flushcommands ()

The 3.Binder driver processes the registration request in Binder_thread_write.

Process two:

1. Send death Notification: Local object death will start off the/dev/binder device, Binder_release will be called, where the binder driver checks if the binder local object is dead, the procedure calls Binder_deferred_ Release execution. If death detects a Binder_work_dead_binder work item in Binder_thread_read. A death notice will be issued.

2. Receive death notification: The client process will process the Br_dead_binder protocol in the Ipcthreadstate::executecommand function.

Process three:

1. Logoff Receive death notification: The proxy object calls Bpbinder::unlinktodeath.

　　

Android Binder interprocess communication mechanism 3-binder object life and death