Android Systrace Basics - SystemServer Explained

Word count: 1.1kReading time: 6 min

 2019/06/29

This is the fourth article in the Systrace series, primarily providing a brief introduction to SystemServer. It covers several important threads within SystemServer. Since Input and Binder are particularly critical, they are discussed separately and won’t be covered in detail here.

The purpose of this series is to view the overall operation of the Android system from a different perspective using Systrace, while also providing an alternative angle for learning the Framework. Perhaps you’ve read many articles about the Framework but can never remember the code, or you’re unclear about the execution flow. Maybe from Systrace’s graphical perspective, you can gain a deeper understanding.

Series Article Index
Main Content
Window Animations
ActivityManagerService
WindowManagerService
Input
Binder
HandlerThreads
About Me && Blog

Series Article Index

Main Content

Window Animations

A critical part of SystemServer in Systrace is window animations. Since SystemServer manages windows, it also handles window animations centrally. This involves two key threads: android.anim and android.anim.lf (further explained below).

Using App Startup as an example, we can see how animations switch between these threads. In Android P, an app’s startup animation consists of the Launcher’s part and the App’s first frame. Previously handled entirely in SystemServer, multitasking animations have partly moved to the Launcher for better performance.

When you click an icon, the Launcher first starts a StartingWindow while the App is still launching. Once the App’s first frame is ready, it switches to the App’s window animation.

Launcher Animation:
-w1019

Correspondingly, the App is starting:
-w1025

As shown above, after the App’s first frame is prepared, SystemServer switches to the App’s window animation.

-w1236

ActivityManagerService

AMS and WMS are the busiest services in SystemServer. Trace points related to AMS typically use the TRACE_TAG_ACTIVITY_MANAGER tag, appearing as ActivityManager in Systrace.

Below is the AMS output when launching a new process:
-w826

Various scenarios for processes and the four components have corresponding Trace points, such as ActivityStart, ActivityResume, and activityStop. Some reside in the application process and others in SystemServer, so analyzing Activity logic requires toggling between both processes to understand state changes and SystemServer‘s role.

-w660

WindowManagerService

WMS-related Trace points typically use the TRACE_TAG_WINDOW_MANAGER tag. WindowManagerService often appears within Binder threads in SystemServer. For example, here’s the relayoutWindow output during app startup:

-w957

Various Window scenarios have Trace points like relayoutWindow, performLayout, and prepareToDisplay.

-w659

Input

Input is a vital part of SystemServer, primarily consisting of the Native threads InputReader and InputDispatcher. This is detailed in Systrace Basics - Input Interpretation and won’t be repeated here.

-w725

Binder

Since SystemServer provides numerous base services, inter-process communication (IPC) is heavy, and most of it uses Binder. Its role is critical; with many background apps, SystemServer can suffer from Binder communication overhead and lock contention, leading to system or app jank. This is detailed in Binder and Lock Contention Explained.

-w1028

HandlerThread

BackgroundThread

com/android/internal/os/BackgroundThread.java

1
2
3

private BackgroundThread() {
    super("android.bg", android.os.Process.THREAD_PRIORITY_BACKGROUND);
}

BackgroundThread in Systrace:
-w1082

BackgroundThread is widely used for non-performance-critical tasks.

-w654

ServiceThread

ServiceThread inherits from HandlerThread. Several worker threads mentioned below inherit from ServiceThread, performing different functions with varying priorities: UiThread, IoThread, DisplayThread, AnimationThread, FgThread, and SurfaceAnimationThread.

Each thread has its own Looper, Thread, and MessageQueue to avoid interference. Android uses specific threads for specific functional tasks.

UiThread

com/android/server/UiThread.java

1
2
3

private UiThread() {
    super("android.ui", Process.THREAD_PRIORITY_FOREGROUND, false /*allowIo*/);
}

UiThread in Systrace:
-w1049

Common uses for UiThread can be found in the source by searching for UiThread.get().

-w650

IoThread

com/android/server/IoThread.java

1
2
3

private IoThread() {
    super("android.io", android.os.Process.THREAD_PRIORITY_DEFAULT, true /*allowIo*/);
}

Uses for IoThread can be found via IoThread.get().

-w654

DisplayThread

com/android/server/DisplayThread.java

private DisplayThread() {
    // DisplayThread runs important stuff, but these are not as important as things running in
    // AnimationThread. Thus, set the priority to one lower.
    super("android.display", Process.THREAD_PRIORITY_DISPLAY + 1, false /*allowIo*/);
}

DisplayThread in Systrace:
-w1108

-w656

AnimationThread

com/android/server/AnimationThread.java

1
2
3

private AnimationThread() {
    super("android.anim", THREAD_PRIORITY_DISPLAY, false /*allowIo*/);
}

AnimationThread in Systrace:
-w902

Uses in source show that WindowAnimator executions happen here. Android P added SurfaceAnimationThread to offload work and improve WindowAnimation performance.

-w657

FgThread

com/android/server/FgThread.java

1
2
3

private FgThread() {
    super("android.fg", android.os.Process.THREAD_PRIORITY_DEFAULT, true /*allowIo*/);
}

FgThread in Systrace:
-w1018

Example of FgThread usage:

FgThread.getHandler().post(() -> {
    synchronized (mLock) {
        if (mStartedUsers.get(userIdToLockF) != null) {
            Slog.w(TAG, "User was restarted, skipping key eviction");
            return;
        }
    }
    try {
        mInjector.getStorageManager().lockUserKey(userIdToLockF);
    } catch (RemoteException re) {
        throw re.rethrowAsRuntimeException();
    }
    if (userIdToLockF == userId) {
        for (final KeyEvictedCallback callback : keyEvictedCallbacks) {
            callback.keyEvicted(userId);
        }
    }
});

SurfaceAnimationThread

com/android/server/wm/SurfaceAnimationThread.java
private SurfaceAnimationThread() {
    super("android.anim.lf", THREAD_PRIORITY_DISPLAY, false /*allowIo*/);
}

SurfaceAnimationThread in Systrace (named android.anim.lf):
-w1148

This thread primarily executes window animations to offload android.anim, reducing jank caused by locks. See: Android P——LockFreeAnimation.

SurfaceAnimationRunner(@Nullable AnimationFrameCallbackProvider callbackProvider,
        AnimatorFactory animatorFactory, Transaction frameTransaction,
        PowerManagerInternal powerManagerInternal) {
    SurfaceAnimationThread.getHandler().runWithScissors(() -> mChoreographer = getSfInstance(),
            0 /* timeout */);
    mFrameTransaction = frameTransaction;
    mAnimationHandler = new AnimationHandler();
    mAnimationHandler.setProvider(callbackProvider != null
            ? callbackProvider
            : new SfVsyncFrameCallbackProvider(mChoreographer));
    mAnimatorFactory = animatorFactory != null
            ? animatorFactory
            : SfValueAnimator::new;
    mPowerManagerInternal = powerManagerInternal;
}

About Me && Blog

Below is my personal intro and related links. I look forward to exchanging ideas with fellow professionals. “When three walk together, one can always be my teacher!”