AOSP Expert & Production Engineering
3 min read

Activity Launch Flow

Launching an Activity is one of the most complex, heavily orchestrated operations in the Android framework. It requires deep coordination between the application process, the Activity Manager Service (AMS), WindowManager Service (WMS), and Zygote.

startActivity() to Activity.onCreate

When an app calls startActivity(Intent), the following sequence unfolds:

  1. IPC to AMS: The calling app uses Binder to send the Intent to ActivityManagerService (or ActivityTaskManagerService in newer Android versions).
  2. Resolution: AMS queries PackageManagerService to resolve the Intent to a specific ActivityInfo. It checks permissions and intent filters.
  3. Process Check: AMS checks if the target application's process is already running.
    • If no: AMS connects to the Zygote socket and requests a new process fork.
    • If yes: AMS skips to step 6.
  4. Zygote Fork: Zygote forks itself, creating a new Dalvik/ART VM instance.
  5. Initialization: The new process calls ActivityThread.main(), attaches to AMS, and executes Application.onCreate().
  6. Schedule Launch: AMS sends an IPC back to the target process (ActivityThread), instructing it to schedule the Activity launch.
  7. Execution: ActivityThread uses reflection to instantiate the Activity class, attaches its Context, and invokes Activity.onCreate(), onStart(), and onResume().
// Simplified view of AMS requesting an app launch via ActivityThread
private void handleLaunchActivity(ActivityClientRecord r, Intent customIntent) {
    Activity a = performLaunchActivity(r, customIntent);
    if (a != null) {
        handleResumeActivity(r.token, false, r.isForward, ...);
    }
}

Warm Start vs Cold Start

  • Cold Start: The application process does not exist. The system must fork a new process from Zygote, initialize the application class, and then create the Activity. This is the slowest path and the primary target for performance optimization.
  • Warm Start: The application process is already running, but the specific Activity has been destroyed or needs to be recreated. The overhead of Zygote forking and Application.onCreate() is bypassed.
  • Hot Start: The application process is running, and the Activity is already in memory (e.g., suspended in the background). The system simply brings it to the foreground, calling onStart() and onResume().

WindowManager Involvement in Launch

Simultaneously with AMS managing the component lifecycle, WindowManagerService (WMS) prepares the visual representation.

When AMS begins the launch, WMS creates an AppWindowToken. Before the app's process even finishes drawing its first frame, WMS displays a Starting Window (often a splash screen based on the app's theme). This masks the latency of the cold start.

Once Activity.onResume() finishes, the app's ViewRootImpl performs layout, measurement, and draws the first frame to a Surface. WMS then orchestrates the removal of the Starting Window and the presentation of the app's UI.

Transition Animations

Transition animations provide visual continuity. WMS coordinates these animations.

  1. Snapshotting: The system takes a snapshot of the outgoing Activity.
  2. Animation Spec: Depending on the Intent flags or custom XML animations specified by overridePendingTransition(), WMS loads the animation specifications.
  3. Execution: SurfaceFlinger executes the animations, manipulating the layer properties (alpha, scale, translation) of both the outgoing and incoming application surfaces simultaneously.

To trace activity launch performance:

adb shell am start -W com.example.app/.MainActivity
# Outputs TotalTime and WaitTime for the launch