Android4.2.2 SurfaceFlinger Startup Process (1)

 

 

This week, I continued my Blog. The previous Blog briefly introduced the basic knowledge required to read the source code of Android FW, mainly related to C ++. From this blog post, we will learn and summarize the content of the SurfaceFlinger module in Android. This article mainly describes the detailed Startup Process of SurfaceFlinger.

 

1. Where can SurfaceFlinger be started?

In the android system, a core Service has ServiceManager management. The core Service is generally started on SystemServer, but the important Service will be started before Zygote starts, the init process is responsible for direct start. As a core Service, SurfaceFlinger generally has the following two startup methods.

A. How to start systemserver.

Source code directory/android/frameworks/base/cmds/system_server/library/system_init.cpp.

extern C status_t system_init(){    ALOGI(Entered system_init());    sp
 
   proc(ProcessState::self());    sp
  
    sm = defaultServiceManager();    ALOGI(ServiceManager: %p, sm.get());    sp
   
     grim = new GrimReaper();    sm->asBinder()->linkToDeath(grim, grim.get(), 0);    char propBuf[PROPERTY_VALUE_MAX];    property_get(system_init.startsurfaceflinger, propBuf, 1);    if (strcmp(propBuf, 1) == 0) {        // Start the SurfaceFlinger        SurfaceFlinger::instantiate();    }    property_get(system_init.startsensorservice, propBuf, 1);    if (strcmp(propBuf, 1) == 0) {        // Start the sensor service        SensorService::instantiate();    }......}
   
  
 

We can see that during the systemserver startup process, property_get obtains the attribute value of system_init.startsurfaceflinger by obtaining the value of system_init.startsurfaceflinger, which is generally in init. in rc, if this value is 0, it is assigned propBuf = 1, so it will use system_init to start SF.

 

B. Compared with the above startup, another kind of startup is to start directly as a Service in the init process like ServiceManager.

Add the following configuration code to init. rc:

# Set this property so surfaceflinger is not started by system_init
Setprop system_init.startsurfaceflinger 0

Start SurfaceFlinger:

469 service surfaceflinger /system/bin/surfaceflinger470     class main471     user system472     group graphics drmrpc473     onrestart restart zygote474 

For how to start the Service, you can view the init and init. rc analysis content in Blog: Startup Process of android system.

 

2. Start with the second method to further analyze SF and look at the main function source code of SurfaceFlinger.

Path: android/frameworks/native/cmds/surfaceflinger/main_surfaceflinger.cpp

int main(int argc, char** argv) {    SurfaceFlinger::publishAndJoinThreadPool(true);    // When SF is launched in its own process, limit the number of    // binder threads to 4.    ProcessState::self()->setThreadPoolMaxThreadCount(4);    return 0;}

To begin the SurfaceFlinger function processing process, it is necessary to propose the basic UML diagram of the SF as follows:

 

Step 1: Call the publishAndJoinThreadPool function:

This function is a function with default parameters in C ++. The input parameter is true.

    static void publishAndJoinThreadPool(bool allowIsolated = false) {        sp
 
   sm(defaultServiceManager());        sm->addService(String16(SERVICE::getServiceName()), new SERVICE(), allowIsolated);        ProcessState::self()->startThreadPool();        IPCThreadState::self()->joinThreadPool();    }
 

The interaction with ServerManger is involved here. The variable sm is a proxy of SM in the current process, used for interaction with the Binder driver, addService registers SurfaceFlinger as a core system service to SM. Then, the current process is called by ProcessState in sequence and a thread is run as follows. Poolthread inherits from the Thread class, so the run function of the thread will be run once run, so the thread classes described above will execute readyToRun and threadLoop of the PoolThread class in sequence;

void ProcessState::spawnPooledThread(bool isMain){    if (mThreadPoolStarted) {        int32_t s = android_atomic_add(1, &mThreadPoolSeq);        char buf[16];        snprintf(buf, sizeof(buf), Binder_%X, s);        ALOGV(Spawning new pooled thread, name=%s, buf);        sp
 
   t = new PoolThread(isMain);        t->run(buf);    }}
 

In the corresponding threadLoop, you can find IPCThreadState: self ()-> joinThreadPool (mIsMain); that is, create a thread state class for inter-process communication between IPCThreadState. The joinThreadPool function of this class is used.
This is the interface for interacting with the Binder driver. The core is to perform talkWithDriver () and executeCommand () with the kernel Binder driver, because the current SurfaceFlinger has entered a normal running state.

Of course, the main thread will also call IPCThreadState: self ()-> joinThreadPool (); for communication between Binder to ensure the stability of communication.

 

Step 2: Return to SurfaceFlinger object Creation
It inherits the public BinderService The template class SF is created in the publishAndJoinThreadPool function mentioned above.

       sm->addService(String16(SERVICE::getServiceName()), new SERVICE(), allowIsolated);

New SERVICE () = new SurfaceFlinger (). From here, the SF creation and related initialization are started.

SF class definition and file directory for initializing member functions:

Source File/android/frameworks/native/services/surfaceflinger/SurfaceFlinger. cpp; header file/android/frameworks/native/services/surfaceflinger/SurfaceFlinger. h;

The following is a dog constructor of SF. First, initialize the base class BnSurfaceComposer and Thread.

SurfaceFlinger::SurfaceFlinger()    :   BnSurfaceComposer(), Thread(false),        mTransactionFlags(0),        mTransactionPending(false),        mAnimTransactionPending(false),        mLayersRemoved(false),        mRepaintEverything(0),        mBootTime(systemTime()),        mVisibleRegionsDirty(false),        mHwWorkListDirty(false),        mDebugRegion(0),        mDebugDDMS(0),        mDebugDisableHWC(0),        mDebugDisableTransformHint(0),        mDebugInSwapBuffers(0),        mLastSwapBufferTime(0),        mDebugInTransaction(0),        mLastTransactionTime(0),        mBootFinished(false)

Here, let's take a look at the thread class by hot tie. It is easy to know that there must be a place where the thread class will be run. Let's take a look at this:

Void SurfaceFlinger: onFirstRef () {mEventQueue. init (this); run (SurfaceFlinger, PRIORITY_URGENT_DISPLAY); // start a new thread, call the run function of the thread class // Wait for the main thread to be done with its initialization mReadyToRunBarrier. wait (); // wait for the thread to complete initialization}

OK, this onFirstRef seems very familiar. It is true that the SP, RefBase, weakref_impl and Thread classes in the Android FrameWork describe their origins in detail, that is, the relationship with RefBase is particularly close. Generally, the template class of a new SP will eventually call the onFirstRef () of the Class Object To Refase (). Here we can see the initialization of mEventQueue (in-depth analysis when introducing the SF message mechanism) and the start of a run function. Therefore, the readyToRun and threadLoop of SF are finally called.