Analysis of the connection process between Android application and Surfaceflinger service

Transferred from: http://blog.csdn.net/luoshengyang/article/details/7857163

In describing the relationship between Android applications and Surfaceflinger Services, it is mentioned that every android application with a UI needs to The Surfaceflinger service establishes a connection so that the Surfaceflinger service can be requested to Create and render Surface for it through this connection .

In this article, we'll take an example of the Android system's start-up animation application, detailing how the Android application connects to the Surfaceflinger service.

Android system boot animation is implemented by the application bootanimation, it is located in the/system/bin directory, its specific implementation can refer to the Android system display process analysis of the screen.

Why choose the boot animation of the Android system to analyze the connection process between Android apps and the Surfaceflinger service?

First, the application that is responsible for the boot animation Bootanimation is also an Android application, but it is developed using the C + + language;

Second, the application bootanimation is UI-related, which, like a standard Android application developed using the Java language, needs to use the Surfaceflinger service to create and render its own surface, which is the boot animation;

Thirdly, since the application bootanimation does not involve user input, that is, it does not need to interact with the user (touch screen, keyboard, etc.), so it can be in the most concise way to reflect the relationship between Android application and Surfaceflinger services.

From the front of the Android system screen display process analysis of the article can be known that the Android system boot animation is mainly a Bootanimation object to achieve, this Bootanimation object in the construction of the time, A Surfacecomposerclient object is created internally to be responsible for creating a connection to the Surfaceflinger service.

The constructor of the Bootanimation class is implemented in file Frameworks/base/cmds/bootanimation/bootanimation.cpp, as follows:

Bootanimation::bootanimation (): Thread (false) {    new  surfacecomposerclient ();}

Msession is a member variable of the Bootanimation class, which is a strong pointer of type surfacecomposerclient, that is, sp<surfacecomposerclient>. Knowledge of smart pointers for Android systems can be found in the implementation principles of smart pointers (lightweight pointers, strong pointers, and weak pointers) on Android.

Inside the Surfacecomposerclient class, there is a member variable of type sp<isurfacecomposerclient> mclient,1, as shown in:

Figure 1 Structure of the Surfacecomposerclient

The member variable of the Surfacecomposerclient class mclient is actually a binder proxy object of type Bpsurfacecomposerclient. The binder proxy object of this type, bpsurfacecomposerclient, refers to a binder local object of type client. As mentioned in the previous relationship overview and learning Plan for Android applications with the Surfaceflinger service, binder local objects of type client are created by the Surfaceflinger service, and runs in the Surfaceflinger service to represent a client that uses the Surfaceflinger service, a UI-related Android application.

Since the client class and the Bpsurfacecomposerclient class are a binder local object class and a Binder proxy object class, they are all implemented according to the Binder interprocess communication Library provided by the Android system at the application framework level. Their implementation structure is shown in Figure 2 and Figure 3, respectively:

Figure 2 Implementation structure diagram of the client class

Figure 3 Implementation structure diagram of the Bpsurfacecomposerclient class

In Figure 2 and Figure 3, it is related to the many classes of binder inter-process communication library, which requires the reader to have a certain understanding and understanding of the binder interprocess communication mechanism of the Android system.         In front of the Android interprocess communication (IPC) Mechanism Binder Brief introduction and Learning Plan a series of articles, we have learned the binder interprocess communication mechanism of the Android system, which is no longer detailed here. The most important information given to us in Figure 2 and Figure 3 is that both the client class and the Bpsurfacecomposerclient class implement the Binder interface of type isurfacecomposerclient. The Isurfacecomposerclient interface has two important member functions Getcontrolblock and Createsurface, which are defined in the file frameworks/base/include/surfaceflinger/ ISurfaceComposerClient.h, as shown in the following:

classIsurfacecomposerclient: Publiciinterface{ Public:    ......    VirtualSp<imemoryheap> Getcontrolblock ()Const=0; ......    /** Requires Access_surface_flinger permission*/    VirtualSp<isurface> Createsurface (surface_data_t*data,intPID,Conststring8&name, Displayid display, uint32_t W,                                        uint32_t h, PixelFormat format, uint32_t flags)=0; ......};

Where the member function Getcontrolblock is used to obtain an anonymous shared memory created by the Surfaceflinger service to pass the UI metadata. The member function, Createsurface, is used to request the Surfaceflinger service to create a surface. From the previous relationship overview and Learning Plan of the Android app with the Surfaceflinger service, the anonymous shared memory used to pass the UI metadata will eventually be structured as a Sharedclient object. This Sharedclient object exists at most one in each application process. In the next two articles, we analyze the implementation of member functions Getcontrolblock and Createsurface of the Isurfacecomposerclient interface in detail.

        Understanding the relationships of the three classes of surfacecomposerclient, client, and Bpsurfacecomposerclient, Next we can analyze how the Android system's boot animation application bootanimation is connected to the Surfaceflinger service.         As you can see from Figure 1, the Surfacecomposerclient class inherits the Refbase class, so When the Bootanimation class creates a Surfacecomposerclient object in the constructor and assigns the object to a smart pointer of type sp<surfacecomposerclient> msession, Causes the member function Onfirstref of the Surfacecomposerclient class to be called, and the member function of the Surfacecomposerclient class Onfirstref in the process of the call, A connection to the Surfaceflinger service is established in the application Bootanimation, as shown in the procedure 4:  Figure 4 The connection process between the Android application and the Surfaceflinger service          Next, we'll analyze each step in detail.          step 1. surfacecomposerclient::onfirstref 

void Surfacecomposerclient::onfirstref () {    sp<ISurfaceComposer> SM (Getcomposerservice ());     if 0 ) {        SP<ISurfaceComposerClient> conn = sm->createconnection ();         if 0 ) {            = conn;            ......             = no_error;}}    }

The member function of the Surfacecomposerclient class Onfirstref implemented in the file frameworks/base/libs/surfaceflinger_client/ The SurfaceComposerClient.cpp file.

The member function of the Surfacecomposerclient class Getcomposerservice is used to obtain a proxy interface for the Surfaceflinger service, which is implemented as follows:

Sp<isurfacecomposer> Composerservice::getcomposerservice () {    return  Composerservice::getinstance (). Mcomposerservice;}

The Composerservice class is a singleton pattern, and when we first call its static function getinstance, it gets a proxy interface for the Surfaceflinger service in the constructor. and save it in its member variable Mcomposerservice, as follows:

 composerservice::composerservice (): Singleton  <composerservice>< Span style= "color: #000000;" > () { const  String16 name ( " surfaceflinger   );  while  (GetService (name, &mcomposerservice)!= No_error) {usleep ( 250000  );    } mservercblkmemory  = Mcomposerservice->getcblk (); Mservercblk  = static_cast<surface_flinger_cblk_t volatile  *>< Span style= "color: #000000;" > (mservercblkmemory ->getbase ());}  

In the constructor of the Composerservice class, in addition to the proxy interface that obtains the Surfaceflinger service, the . This anonymous shared memory is created by the Surfaceflinger service to describe the information on the system display, for example, The number, size, orientation, density, and so on of the display . Since this information can be described by a surface_flinger_cblk_t object, The constructor of the Composerservice class finally constructs an anonymous shared memory previously obtained from the Surfaceflinger service into a surface_flinger_cblk_t object. and is stored in the member variable mservercblk of the Composerservice class.

        Back to the member function Onfirstref of the Surfacecomposerclient class, because the Surfaceflinger service implements the Isurfacecomposer interface , so we can assign the proxy interface of the previously obtained Surfaceflinger service to a strong pointer sm of type Isurfacecomposer, and call its member function createconnection to request the Surfaceflinger service to create a connection that creates a binder object of type client, and returns a proxy interface for the Binder object Conn. After the Surfacecomposerclient class obtains the client Agent interface Conn returned by the Surfaceflinger service, it saves its own member variable mclient. This enables the Boot animation application bootanimation to request Surfaceflinger to create and render your surface later on.         Next, we will continue to analyze the implementation of the member function createconnection of the Surfaceflinger service, So you can see how it creates a connection for the Android app.         step 2. surfaceflinger::createconnection

Sp<isurfacecomposerclient> surfaceflinger::createconnection () {    SP<isurfacecomposerclient > bclient;    SP<Client> Client (new Client (this));     = client->Initcheck ();     if (Err = = No_error)        {= client    ;    } return bclient;}

The member function of the Surfaceflinger class CreateConnection implemented in the file frameworks/base/services/surfaceflinger/ SurfaceFlinger.cpp, it is very simple to implement, just create a Binder object client of type client, and get a isurfacecomposerclient interface of it, and finally connect this isurfacecomposerclient Port, which is a client proxy object, is returned to the Boot animation application bootanimation.

Next, we will continue to analyze the client object creation process, that is, the implementation of the client class constructor. Step 3. New Client

Client::client (const sp<surfaceflinger>& flinger)    : Mflinger (Flinger), Mnamegenerator (  1) {}

The client class has two member variables Mflinger and mnamegenerator, their types are sp<surfaceflinger> and int32_t respectively, which point to the Surfaceflinger service, The latter is used to generate the name of each surface that the Surfaceflinger service creates for Android applications. For example, suppose an Android application requests Surfaceflinger to create two surface, then the first surface name is described by a number, and the second surface is described by a number, and so on. Overview of the relationship with Surfaceflinger services from the front Android app and learning Plan This article knows that an Android app can create up to 31 surface.

          back to the member function CreateConnection of the Surfaceflinger class, It returns a isurfacecomposerclient interface that points to a client object after the boot animation application bootanimation, Boot animation application bootanimation can encapsulate it as a binder proxy object of type Bpsurfacecomposerclient.          step 4. Return bpsurfacecomposerclient          The encapsulation procedure for Binder proxy objects of type bpsurfacecomposerclient is implemented in member functions createconnection of the Binder proxy object class Bpsurfacecomposer the Surfaceflinger service , as shown below:

class  Public Bpinterface<isurfacecomposer>{public:    ...     virtual sp<isurfacecomposerclient> createconnection ()    {        uint32_t n;        Parcel data, reply;        Data.writeinterfacetoken (Isurfacecomposer::getinterfacedescriptor ());        Remote ()->transact (bnsurfacecomposer::create_connection, data, &reply);         return interface_cast<isurfacecomposerclient>(Reply.readstrongbinder ());    }    ......}

Interface_cast is a template function that is defined in the Framework/base/include/binder/iinterface.h file:

Template<typename interface>  inline sp<INTERFACE> interface_cast (const sp< ibinder>& obj)  {      return  interface::asinterface (obj);  }  

• }

Template<typename interface>  Inline sp<interface> interface_cast (const sp<ibinder>& obj)  {      return interface::asinterface (obj);  }  

As can be seen from here, when the template parameter is isurfacecomposerclient, the template function Interface_ Cast is actually a binder proxy object described by the parameter obj by calling the static member function Asinterface of the Isurfacecomposerclient class, which is a Bpbinder object, Encapsulated as a Bpsurfacecomposerclient object.

The static member function of the Isurfacecomposerclient class is asinterface by frameworks/base/libs/surfaceflinger_client/ The Implement_meta_interface macro in the ISurfaceComposerClient.cpp file is defined as follows:

" android.ui.ISurfaceComposerClient ");

After the Implement_meta_interface macro expands, the implementation of the static member function Asinterface for the Isurfacecomposerclient class is as follows:

Android::sp<isurfacecomposerclient> Isurfacecomposerclient::asinterface (Constandroid::sp<android::ibinder>&obj) {ANDROID::SP<ISurfaceComposerClient>Intr; if(obj! =NULL) {Intr= static_cast<isurfacecomposerclient*>(obj->querylocalinterface (isurfacecomposerclient::d escriptor).Get()); if(Intr = =NULL) {Intr=Newbpsurfacecomposerclient (obj); }}returnIntr; }     

The parameter obj is passed in from the member function of the Bpsurfacecomposer class CreateConnection, which is actually a Bpbinder object. When we call the member function Querylocalinterface of a Bpbinder object, we get a null pointer, so The static member function of the Isurfacecomposerclient class Asinterface finally encapsulates a Bpbinder object that the parameter obj points to as a Bpsurfacecomposerclient object and is returned to the caller.

A more specific encapsulation process for bpsurfacecomposerclient objects can refer to the previous talk about the Android system interprocess communication (IPC) mechanism in binder for server and Client Access service The package process for the Bpservicemanager object described in the path to the manager interface article.
At this point, the boot animation application bootanimation through the Surfacecomposerclient class to establish a connection with the Surfaceflinger service. As mentioned in the previous relationship overview and learning Plan for Android applications with the Surfaceflinger service, an Android application requires an anonymous shared memory to pass the UI metadata in addition to connecting to the Surfaceflinger service , which is a Sharedclient object, so in the next article, we will continue to analyze the creation of this anonymous shared memory, so please look forward to it!

Analysis of the connection process between Android application and Surfaceflinger service