IPC motherboard mode design for Android development

First, understand the IPC motherboard mode of Android

The most critical task of system architecture design is the combination (or integration), and it is best to be unique and innovative. Android is good at using the motherboard mode to practice the IPC communication mechanism across the process in a generic interface. Since Android is open source system, the source code can be a model for everyone to observe. First, its motherboard mode provides a ibinder generic interface. The following figure:

Android defines a binder parent class to implement < versatility > IBinder interfaces. The following figure:

Then, write this implementation class in Java with Java code as follows:

 android's source code// binder.java// -------------------------------------------------------------
Public class binder implements ibinder {    //&nbsp ......
    private int mObject;
    public binder ()  {        init ();         //  other code     }    public  final boolean transact (int code, parcel data, parcel reply,   int flags)                  throws remoteexception {                 //  other Code                  boolean r = ontransact (Code, data, reply, flags);
                return r;    &NBSP} private boolean exectransact (Int code, int dataobj, int  replyobj, int flags)  {        parcel data
 = parcel.obtain (Dataobj);         parcel reply = parcel.obtain (REPLYOBJ); 
               boolean res;         res = ontransact (code, data, reply, 
Flags);         //  other Code         
return res;    &NBSP}    protected boolean ontransact (Int code, Parcel  data, parcel replY,  int flags)                         throws remoteexception {   
     }    private native final void init (); }// end

The main function of the binder abstract parent class:

Transact () function-the Transact () function interface used to implement the IBinder.

The Exectransact () function-its role is the same as the Transact () function, except that it is used to make a C + + local program call.

Ontransact () function-This is an abstract function that lets you apply subclasses to overwrite (Override). Both of the above Transact () and exectransact () invoke the Ontransact () function to implement the reverse invocation (IoC, inversion of control).

The init () function, which is a local (Native) function, allows the JNI module to implement this function. The Binder () constructor (constructor) invokes this init () local function.

This Binder.java is an abstract class that contains an abstract function: Ontransact (). As a result, the software board provides two interfaces: CI and interfaces. The following figure:

This is the standard motherboard mode. The binder abstract parent class and two interfaces in this diagram are integrated into a typical software motherboard. The following figure:

This binder software board is used to integrate software modules (such as classes) in two processes, so we call it:. The following figure:

Based on this motherboard, we can start to assemble. At this point, you can design a subclass and assemble it onto the motherboard's interface. The following figure:

Figure 1 Binder the interprocess communication model

Both client and server interact with the binder driver through function ioctl. IOCTL is a function of Linux to control I/O devices, providing a means of sending control parameters and data to the device at the same time. It is a function of a variable parameter, and the prototype is:

??? #65533; " http://www.2cto.com/kf/ware/vc/"target=" _blank "class=" Keylink ">vcd4kphbyzsbjbgfzcz0=" Brush:java; >int IOCTL (int fd, int cmd, ...);

FD is the file descriptor that is obtained after opening the/dev/binder device, and CMD is the control command for the device. The function performs a successful return of 0, otherwise returns-1.

3. Related data structure

When the second parameter of the function ioctl cmd is binder_write_read, it represents a command to send a read or write/dev/binder device to the binder driver, and the binder driver will read and write "translate" the device to the shared

Read and write in the memory area. This command is the most important and frequently used control command for client and server interprocess communication.

When the binder_write_read is passed in, a pointer to a BINDER_WRITE_READ structure is passed in as the third parameter of the IOCTL, Read_buffer and Write_ in the structure The buffer field points to the buffers that will be read or written. The data in both buffers is stored in the order of "data type + data content," and several different types of data are stored continuously, as shown in Figure 2. The data type in Write_buffer begins with "Bc_", and the data type in Read_buffer begins with "Br_," and in Figure 2, for example, the data in Write_buffer. In all data types, BC (r) _reply and BC (r) _transaction are most important: by bc_transaction/bc_reply this pair of commands, the sender sends the data to the receiving party; through Br_transaction/br_ REPLY, the receiving party reads the data sent by the sender.

The content of the data is a binder_transaction_data structure.

Fig. 2 The relationship between the data structures in Binder IPC

Binder_transaction_data structure is the encapsulation of interprocess communication data, which can be regarded as a packet in network communication. The SENDER_UID,SENDER_PID member variable indicates that the user ID and process id,buffer member variable of this data sender point to the most core payload data of interprocess communication, Data_size is the length of the payload data. In the binder mechanism, sender_uid and sender_pid are filled in the kernel by the binder drive, which can not be forged, which guarantees the reliability of the identity tag, thus the communication mechanism between binder process is safe.

Data behavior relationships between 4.Binder

When client and server use the binder mechanism for interprocess communication, the client's specific behavior can be identified by analyzing the client's data sent to the server or analyzing the client's request data read by the server.

For example, when the client wants to get the location information, the request Locationserver gets the location data, accesses the Locationserver Ilocationmanager interface, and sends the payload to the Locationserver

It contains the "Android.location.ILocationManager" string. So we analyze the request data from the client sent by Locationserver to determine whether it contains "Android.location.ILocationManager",

We can tell if the client is trying to access the user's geographic information.

Since each application in the Android system has its own unique UID, we can get the client-specific application based on the Sender_uid in Binder_transaction_data. Such

The specific behavior of the specific software is obtained.

Through the analysis of the Android system, we find that although the system provides up to dozens of services, in fact only three of the server processes are responsible for managing

Android system server process and management services

Services managed by the service process

Com.android.phone SMS and telephone service related to communication function

MediaServer video and audio services related to media features

System_server other services, such as geographical location, Bluetooth, network connectivity, program safety loading and unloading, etc.