Android Binder Summary

1. Mediapplayerservice start, how to register in ServiceManager, do not explain the detailed details

ServiceManager is the service manager of the entire system, and the rest of the system services are called ServiceManager through the Defaultservicemanager remote interface. After the service obtains the ServiceManager interface, it joins itself to the ServiceManager, then initiates itself and waits for the client to connect to the request.

The knowledge about how Systemmanager starts and becomes a director and binder can be tested:

http://blog.csdn.net/luoshengyang/article/details/6621566

First look at the Mediaplayerservice UML, there is a general understanding.

1) First Mediaplayerservice is instantiated from Main_mediaservice.cpp Main, so Mediaplayerservice is also executed in the System_service process.

int main (int argc, char** argv) {    processstate> proc (processstate::self ());    ... ...    Mediaplayerservice::instantiate ();    ... ...    Processstate::self ()->startthreadpool ();    Ipcthreadstate::self ()->jointhreadpool ();}

2) There are two main things in Mediaplayerservice::instantiate (), the first is to initialize a global variable gprocess by processstate::self (), The MDRIVERFD in Processstate will hold a pointer to the binder device. The second major task is to call ServiceManager and add yourself to the Servicemanger Explorer.

Sp<processstate> processstate::self () {    if (gprocess! = NULL) return gprocess;        Automutex _l (Gprocessmutex);    if (gprocess = = NULL) gprocess = new Processstate;    return gprocess;}

The process of addservice is very complex and interested people can read this article from Lao Luo:

http://blog.csdn.net/luoshengyang/article/details/6629298

void Mediaplayerservice::instantiate () {    Defaultservicemanager ()->addservice (            String16 ("Media.player" ), New Mediaplayerservice ());}

3) After adding itself to the ServiceManager, the following two functions are run, and are always used to interact with the binder driver by invoking the Talkwithdriver function. It is actually called Talkwithdriver to wait for the client's request, and then calls ExecuteCommand to process the request, and in the ExecuteCommand function, the Bbinder is finally called: Transact to really handle client requests.

    Processstate::self ()->startthreadpool ();    Ipcthreadstate::self ()->jointhreadpool ();

2. How to call Mediaplayerservice and communicate with service

Mediaplayerservice is now a service, waiting for the client to establish a connection. This client is MediaPlayer, it declares and is now Frameworks/base/include/media/mediaplayer.h and frameworks/base/media/libmedia/ In the Mediaplayer.cpp file. MediaPlayer inherits from the Imediadeathnotifier class, and this class declares and real today Frameworks/base/include/media/imediadeathnotifier.h and frameworks/ In the Base/media/libmedia//imediadeathnotifier.cpp file, there is a static member function Getmeidaplayerservice, which is iservicemanager by: GetService interface to obtain the Mediaplayerservice remote interface.

Before we introduce the Imediadeathnotifier::getmeidaplayerservice function, let's look at the goal of this function. is actually to get a imediaplayerservice interface called a Bpmediaplayerservice object.

As you can see from the previous class diagram, Bpmediaplayerservice inherits from the Bpinterface<imediaplayerservice> class, That is, Bpmediaplayerservice inherits the Imediaplayerservice class and the Bprefbase class, and these two classes continue with the Refbase class respectively. The Bprefbase class has a member variable mremote, which is of type ibinder and is actually a Bpbinder object. The Bpbinder class uses the Ipcthreadstate class to interact with the binder driver, whereas the Ipcthreadstate class has a member variable mprocess, which is of type processstate, The Ipcthreadstate class uses the Processstate class to open the Binder device file/dev/binder, so it can interact with the binder driver.

The Bpmediaplayerservice constructor has a parameter impl, which is of type Const Sp<ibinder>&, and from the descriptive narrative above, this is actually a Bpbinder object. In this way, to create a Bpmediaplayerservice object, you must first have a Bpbinder object. Then look at the constructor of the Bpbinder class, which has a parameter handle, type int32_t, The significance of this parameter is to request that the process of this remote interface Mediaplayerservice a reference to the binder entity of Mediaplayerservice. Therefore, getting the mediaplayerservice of this remote interface becomes a handle to getting Mediaplayerservice from service Manager.

Let's take the create process as a sample:

1) Mediaplayer.getmediaplayerservice ()

MediaPlayer inherits Imediadeathnotifier, so it is called imediadeathnotifier.getmediaplayerservice (), The main role of this function is to obtain the "Media.player" service IBinder from Systemmanager, that is, to obtain a bpmediaplayerservice, which communicates with the server through this ibinder.

2) Service->create (Getpid (), this, Maudiosessionid)

This service is actually bpmediaplayerservice, so it's called Bpmediaplayerservice's Create, which goes back to the remote ()->transact in this function.

3) remote ()->transact (CREATE, data, &reply)

This remote () returns a Bpbinder, which is actually bpbinder.transact, the Transact is not doing anything, mainly by calling Ipcthreadstate-> Transact to finish the data request work.

4) ipcthreadstate::self ()->transact

In this transact mainly through the waitForResponse and Talkwithdriver to complete with the binder equipment of the IOCTL operation. When Talkwithdriver is called, the ipcthreadstate in Mediaplayerservice hears the request and calls its own executecommand.

5) Bnmediaplayerservice.ontransact ()

The ExecuteCommand will invoke the callback function according to the command type, this is called Bbinder.transact, And Bbinder.transact will finally call Bnmediaplayer.ontransact to do the detailed processing, call create and return a MediaPlayer of a ibinder client.

3. Take AMs as a sample, look at the Java Layer Service Binder is assumed to use. How AMS gets client,client how to communicate with service

1) instrumentation.execstartactivity ()

The activity has a startactivity function that goes back to call Instrumentation.execstartactivity (), while in Execstartactivity () And will be removed by Activitymanagernative.getdefault () with startactivity

2) Activitymanagerproxy.transact ()

In Activitymanagernative.getdefault () The activitymanagerproxy is actually returned. The startactivity in Activitymanagerproxy calls Mremote.transact, and Mremote actually binderproxy the object, so it is equal to the Binderproxy function that calls Trasact directly.

3) Binder.exectransact ()

Binderproxy's trasact will go through the jni of the binder request, and finally by the service side of the binder exectranaction to do function response.

4) Activitymanagerservice.ontransact

Biner.exectranaction uses the Activitymanagerservice.ontransact most callback function to run, and puts the result in reply.

UML diagram:

Http://sdrv.ms/Q79iGk

Android Binder Summary