Understanding Android ActivityThread: Initialization, ContentProvider, Rendering, and ANR Causes

In the previous article we examined the rarely seen but important ViewRootImpl class; this article turns the focus to another core Android framework class, ActivityThread , which serves as the entry point for the application process.

By reading this article you will learn:

The bridge between the system process ( system_server ) and the app process.

Why ContentProvider can be leveraged for automatic SDK initialization.

When an Activity actually starts rendering.

How to monitor component lifecycle events via the main thread handler.

The root cause of ANR related to SharedPreference writes.

A concise summary of the insights gained.

1. ActivityThread as the bridge – When an app process starts, the Android Runtime (ART) immediately invokes ActivityThread.main() . The method prepares the main looper, creates an ActivityThread instance, attaches it to the system service, and starts the message loop. This establishes communication with system_server via the binder objects IActivityManager and ApplicationThread .

public static void main(String[] args) {
    Looper.prepareMainLooper();
    ActivityThread thread = new ActivityThread();
    thread.attach(false, startSeq);
    sMainThreadHandler = thread.getHandler();
    Looper.loop();
    throw new RuntimeException("Main thread loop unexpectedly exited");
}

The attach method obtains the system binder through ActivityManager.getService() and passes the ApplicationThread binder to the system process.

private void attach(boolean system, long startSeq) {
    final IActivityManager mgr = ActivityManager.getService();
    mgr.attachApplication(mAppThread, startSeq); // remote binder call
}

Through this binder the system can later deliver ApplicationThread callbacks such as bindApplication , which creates the Application object and initializes the ContentProvider s.

2. Why ContentProvider can perform initialization – After the Application is created, the framework calls attachBaseContext() and onCreate() . During this phase it also invokes each registered ContentProvider 's onCreate() . Many third‑party SDKs hook into this method to run their own initialization code without requiring explicit calls from the app.

3. When an Activity starts rendering – The rendering entry point is the handleResumeActivity() method inside ActivityThread . It obtains the decor view from the window, adds it to the WindowManager , and thus the UI begins to be drawn.

public void handleResumeActivity() {
    performResumeActivity(r, finalStateRequest, reason);
    Activity a = r.activity;
    View decor = r.window.getDecorView();
    ViewManager wm = a.getWindowManager();
    a.mWindowAdded = true;
    wm.addView(decor, l);
}

4. Monitoring component lifecycle – The main thread handler (class H ) receives messages such as BIND_APPLICATION , RECEIVER , CREATE_SERVICE , and RELAUNCH_ACTIVITY . By reflecting on this handler you can observe when the system schedules lifecycle events, which is useful for diagnosing ANR problems.

class H extends Handler {
    public static final int RECEIVER = 113; // broadcast receiver
    public static final int CREATE_SERVICE = 114; // Service creation
    public static final int INSTALL_PROVIDER = 145; // ContentProvider
    public static final int RELAUNCH_ACTIVITY = 160; // Activity launch

    public void handleMessage(Message msg) {
        switch (msg.what) {
            case BIND_APPLICATION:
                Trace.traceBegin(..., "bindApplication");
                AppBindData data = (AppBindData) msg.obj;
                handleBindApplication(data);
                Trace.traceEnd(...);
                break;
            // other cases omitted for brevity
        }
    }
}

5. SharedPreference as an ANR source – Several lifecycle methods in ActivityThread (e.g., handleStopService , handlePauseActivity , handleStopActivity ) call QueuedWork.waitToFinish() . This method blocks the main thread until pending SharedPreference write operations (commit/apply) finish, which can lead to ANR if the queue is long.

public static void waitToFinish() {
    while (true) {
        Runnable finisher;
        synchronized (sLock) {
            finisher = sFinishers.poll();
        }
        if (finisher == null) {
            break;
        }
        finisher.run();
    }
}

ByteDance’s team demonstrated that by hooking the poll() method to always return null, the ANR caused by SharedPreference writes can be eliminated.

6. Summary – By dissecting the ActivityThread source you gain insight into the communication bridge between system and app processes, the exact moment an Activity begins to render, how ContentProvider enables automatic SDK initialization, and why SharedPreference writes may block the main thread. These details are valuable for performance tuning and ANR troubleshooting.