Explain in detail the implementation of cmprocess cross process communication Android kernel binder architecture analysis

Cmprocess is a cross process communication framework for Android. The overall code is relatively simple, with a total of more than 20 classes, which is very convenient for us to understand the principle of cross process implementation.

I guess that cmprocess also draws on the source code of virtualapp (which is very powerful and is a sandbox in which other apks can be installed) to sort out a set of communication scheme. Virtualapp has powerful functions and complex implementation. It needs deep knowledge of framework to understand.

According to the author, cmprocess is a more convenient and concise Android process communication scheme. There is no need to perform bindservice () operation, define service or define Aidl. Support IPC level callback and cross process event bus. Services can be obtained synchronously. The interface oriented method is adopted for service registration and invocation, and the service caller and consumer are completely decoupled.

The code variable is used to identify which function the client expects to call the server. Therefore, both parties need to agree on a set of int values. Different values represent different server functions. This value is consistent with the value of the first parameter code in the transact() function of the client.

Enforceinterface () is for some kind of verification. It corresponds to writeinterfacetoken () of the client. See the next section for details. Readstring() is used to fetch a string from the package. If the client of the IPC call expects to return some results, the relevant function supplied by Parcel can be written back to the corresponding result in the return package reply. Parcel.writeXXX();

Now we need to see how to get the parameters step by step through the binder.

Using parcel generally obtains a new parcel object from the object pool through parcel. Obtain(). If there is no new parcel in the object pool, a new parcel object will be created directly, and a parcel native object will be automatically created.

Writeinterfacetoken is used to write the ibinder interface flag with parameters of string type, such as iservicemanager.descriptor = "Android. OS. Iservicemanager".

The code mentioned earlier is used here. Code is a private variable bound with method.

There is a server. Transact (code, 0) in the middle; This method implements cross process call and will eventually go to the following ontransact method of binderprovider:

Startup process analysis of ContentProvider

Detailed explanation of parcel class