From tap to first frame: how an Android app starts

A cold start finishes in well under a second on a decent phone, yet it touches five processes, one fork(), a few dozen Binder calls and a full trip through the GPU. Knowing the order of events is what makes startup problems easy to reason about: at every moment you know who is working, and whether that work is the system's or yours.

The map

Read this first when short on time. Every branch is a section below.

The whole trip in one picture

Five actors take part. The Launcher is just another app. system_server is the process that hosts almost every system service. Zygote is a pre-warmed process that gets cloned to make yours. Your app process runs your code. SurfaceFlinger turns everybody's pixels into one image on the display.

Everything below is these five actors passing messages in a fixed order. The rest of the article follows one cold start from top to bottom.

Cold, warm, hot: three kinds of start

The kind of start is decided by what already exists in memory when the tap lands. Two questions settle it: is the process alive, and is the Activity object alive?

flowchart TD
  A([Tap the icon]) --> B{Process alive?}
  B -- No --> C[Cold start]
  B -- Yes --> D{Activity object alive?}
  D -- No --> E[Warm start]
  D -- Yes --> F[Hot start]
  C --> C1["fork from Zygote, Application.onCreate, Activity.onCreate, first frame"]
  E --> E1["Activity.onCreate, first frame"]
  F --> F1["onRestart, onStart, onResume, redraw"]

The thresholds in the last column are what the Play Console counts as excessive startup time. A warm start is a strict subset of a cold one, and a hot start is a subset of both, so understanding the cold path covers all three.

The tap: how a touch becomes a click

A tap is a kernel event that system_server turns into a MotionEvent and hands to whichever window owns the touched pixels. The app never talks to the touchscreen directly.

sequenceDiagram
  autonumber
  participant K as Kernel (evdev)
  box transparent system_server
    participant R as InputReader
    participant D as InputDispatcher
  end
  participant L as Launcher (ViewRootImpl)
  K->>R: raw events from /dev/input/eventN
  R->>D: MotionEvent ACTION_DOWN, later ACTION_UP
  D->>D: pick the window under the finger
  D->>L: MotionEvent over the window's InputChannel
  L->>L: dispatch down the View tree
  L->>L: icon View: performClick()
  L-->>D: finished (dispatch timeout cleared)

1. The touch controller raises an interrupt; the kernel input driver publishes raw events on an evdev device node.
2. The InputReader thread reads those events and cooks them into a MotionEvent with screen coordinates and pointer ids.
3. The InputDispatcher thread asks WindowManager's window list which touchable window is under the finger and pushes the event down that window's InputChannel, a socket pair created when the window was added.
4. In the Launcher process, ViewRootImpl receives the event on the main thread and runs the normal dispatchTouchEvent chain. The icon's view gets ACTION_DOWN, then ACTION_UP, and calls performClick().
5. The Launcher's click handler now calls startActivity. It also signals the dispatcher that the event was consumed; if an app does not do that within five seconds the system shows an ANR.

InputChannel

A pair of Unix domain sockets. One end lives in InputDispatcher, the other in the app's ViewRootImpl. Every window gets its own when it is added to WindowManager.

MotionEvent

The framework object for a pointer event: action, coordinates, pressure, timestamps, one entry per pointer.

Launcher asks the system to start your activity

startActivity is a request, not an action. The Launcher hands an Intent to system_server, and system_server decides everything else: which class, which task, whether a new process is needed, and what shows on screen meanwhile.

sequenceDiagram
  autonumber
  participant L as Launcher
  participant ATMS as ActivityTaskManager
  participant WMS as WindowManager
  participant AMS as ActivityManager
  L->>ATMS: startActivity(intent, options) over Binder
  ATMS->>ATMS: resolve the intent with PackageManager
  ATMS->>ATMS: checks, ActivityRecord, Task
  ATMS->>WMS: add a starting window (splash screen) for the record
  ATMS-->>L: START_SUCCESS
  ATMS->>L: PauseActivityItem
  ATMS->>AMS: startProcess(processName, uid) when no process is attached yet
  L-->>ATMS: activityPaused()
  Note over ATMS: waits for both: the Launcher paused and the app process attached

Inside the Launcher process

The Launcher builds an explicit Intent with ACTION_MAIN, CATEGORY_LAUNCHER and your activity's ComponentName, usually with ActivityOptions that describe the icon's position for the launch animation. Activity.startActivity goes through Instrumentation.execStartActivity, which makes a Binder call into ActivityTaskManagerService. The Launcher's main thread blocks for the few milliseconds that call takes and gets back a result code.

Inside system_server

ActivityStarter owns the launch logic:

1. Resolve. PackageManager turns the intent into an ActivityInfo: class name, theme, launchMode, taskAffinity, and the process name from the manifest.
2. Check. Is the activity exported, does the caller hold the required permission, is the user allowed to start it?
3. Record. A new ActivityRecord is created and placed on top of an existing Task or a fresh one, according to the launch mode and intent flags.
4. Starting window. WindowManager adds a starting window for the record right away. Since Android 12 this is the splash screen: your icon on your theme's windowSplashScreenBackground, drawn by the system, not by your process. This is why the screen reacts instantly even though nothing of yours has run.
5. Pause the previous activity. The Launcher is the resumed activity, so it receives a PauseActivityItem and runs onPause. The system waits for activityPaused (or a 500 ms timeout) before it will resume the new one. A slow onPause in any app delays whatever launches next.
6. Process check. If a process with the target process name and uid is already attached, the launch proceeds straight to the activity (the warm path). If not, ActivityManagerService is told to start one, and the record waits for it to attach.

ActivityRecord

system_server's bookkeeping object for one activity instance: its state, its task, its window token, its process. Your Activity object is the client-side counterpart.

Task

The back stack. An ordered list of ActivityRecords that the user sees as one thing in Recents.

WindowProcessController

How ActivityTaskManagerService refers to an app process: its pid, its activities, and the Binder handle for calling into it.

Starting window

A placeholder window the system shows for an activity that has not drawn yet. On Android 12 and later it is the splash screen; earlier it was a plain window painted with the theme's windowBackground.

A new process is born from Zygote

Zygote is a process that started at boot, loaded the ART runtime plus thousands of framework classes and common resources, and then went to sleep listening on a socket. Every app process is a fork() of it. Starting an app is a copy, not a boot, and the copied pages are shared with every other app until someone writes to them.

sequenceDiagram
  autonumber
  participant AMS as ActivityManager
  participant Z as Zygote
  participant P as New app process
  AMS->>AMS: decide uid, gids, ABI, SELinux label, runtime flags
  AMS->>Z: local socket: fork request, entry point android.app.ActivityThread
  Z->>Z: forkAndSpecialize()
  Z-->>P: child process, copy-on-write
  Z-->>AMS: pid
  P->>P: set uid, seccomp, Binder thread pool
  P->>P: ActivityThread.main, main Looper
  P->>AMS: attachApplication(IApplicationThread) over Binder
  P->>P: Looper.loop() forever

What system_server sends

ProcessList.startProcessLocked computes what the new process needs to be: the uid assigned at install, supplementary gids for storage and network, the ABI to run (32 or 64 bit, which decides between the zygote and zygote64 sockets), the SELinux label, the nice name, and runtime flags such as debuggable. The request is written to Zygote's socket by ZygoteProcess, and the reply is the child's pid. A ProcessRecord in AMS and a WindowProcessController in ATMS now represent the process, and a ten second timer starts: if the process has not attached by then, the launch is abandoned.

What Zygote does

ZygoteConnection parses the arguments and calls forkAndSpecialize. In the child, native code sets the uid and gids, drops capabilities, applies the seccomp filter and the SELinux context, and closes the Zygote socket. The child then runs ZygoteInit.zygoteInit, which starts the Binder thread pool for this process and finds the requested entry point by reflection. That entry point is always android.app.ActivityThread.main, invoked with a clean stack.

ActivityThread.main: where the main thread comes from

The thread that Zygote forked becomes the main thread by calling Looper.prepareMainLooper() and, at the very end, Looper.loop(). Between those two lines it creates one ActivityThread and calls attach, which makes the Binder call attachApplication(mAppThread, startSeq) into ActivityManagerService. mAppThread is an ApplicationThread, a Binder object that lives in your process; from now on system_server uses it to call back into you. Every callback it receives is posted as a message to the main Looper through the handler named H. That is the whole mechanism behind "everything happens on the main thread".

ActivityThread

One per process. Owns the main Looper, the Application, every Activity, Service and ContentProvider instance, and the H handler that turns system callbacks into main-thread messages.

ApplicationThread

The Binder stub inside ActivityThread. system_server holds its proxy and calls methods like bindApplication and scheduleTransaction on it.

Your Application object comes to life

attachApplication is where system_server tells the new process who it is. The reply is a one-way Binder call, bindApplication, that carries the ApplicationInfo, the list of content providers to install, the instrumentation to use and the current configuration. The process then builds your Application and calls onCreate.

flowchart TD
  A["bindApplication arrives on the main thread"] --> B["LoadedApk: class loader, resources, native lib dir"]
  B --> C["Application instantiated by reflection"]
  C --> D["attachBaseContext()"]
  D --> E["every ContentProvider: constructor, onCreate()"]
  E --> F["Application.onCreate()"]
  F --> G["main thread free: next message is the activity launch"]

In system_server, attachApplicationLocked matches the pid to its ProcessRecord, calls bindApplication on the process, and then asks ActivityTaskManagerService whether any activity is waiting for this process. Yours is, so the launch transaction is sent immediately after. Both arrive as messages on the main Looper, in that order.

Back in your process, handleBindApplication does the following, all on the main thread:

1. Sets the process name, time zone, locale and configuration; enables StrictMode for debuggable builds.
2. Creates the LoadedApk: the in-memory representation of your APK. This is where the PathClassLoader over your base and split APKs is created, together with the Resources object.
3. Creates the Instrumentation and the app-level ContextImpl.
4. Instantiates your Application subclass (the class named by android:name in the manifest, or plain android.app.Application) through AppComponentFactory, then calls attach, which is what runs attachBaseContext.
5. Instantiates every ContentProvider declared in the merged manifest, calls onCreate on each, and publishes them to ActivityManagerService.
6. Calls Application.onCreate.

class ClioApp : Application() {

    private val appScope = CoroutineScope(SupervisorJob() + Dispatchers.Default)

    override fun attachBaseContext(base: Context) {
        super.attachBaseContext(base)
        // Earliest hook in the process, before any ContentProvider and before onCreate().
        // Only things that must exist that early belong here.
    }

    override fun onCreate() {
        super.onCreate()
        // Runs once per process, on the main thread, before any Activity.
        // Keep it cheap: build the dependency graph lazily, defer anything that is not
        // needed for the first screen, and never touch disk or network synchronously.
        appScope.launch { warmUpCaches() }
    }

    private suspend fun warmUpCaches() { /* ... */ }
}

LoadedApk

The runtime view of an installed package inside a process: its class loader, resources, application info and the Application instance once created. One per package loaded in the process.

Context

The handle to the app environment: resources, assets, package name, system services, file directories. The Application and each Activity wrap their own ContextImpl.

The activity is launched

The system sends one transaction that says: create this activity, then bring it to the resumed state. The app's main thread walks the lifecycle to get there, and at the end of that walk it attaches the activity's window to WindowManager.

sequenceDiagram
  autonumber
  participant ATMS as ActivityTaskManager
  participant L as Launcher
  participant A as App main thread
  ATMS->>L: PauseActivityItem
  L->>L: onPause()
  L-->>ATMS: activityPaused()
  ATMS->>A: ClientTransaction: LaunchActivityItem + ResumeActivityItem
  A->>A: new MainActivity(), attach(): PhoneWindow
  A->>A: onCreate() with setContent
  A->>A: onStart(), onPostCreate()
  A->>A: onResume()
  A->>A: addView(decorView): ViewRootImpl
  A->>ATMS: addWindow() over Binder
  A->>A: first traversal, first frame
  A-->>ATMS: activityIdle, window drawn
  ATMS->>ATMS: remove starting window
  ATMS->>L: StopActivityItem
  L->>L: onStop()

What the transaction contains

realStartActivityLocked in system_server builds a ClientTransaction addressed to your ApplicationThread. It carries a LaunchActivityItem (intent, ActivityInfo, configuration, the activity token, saved state if any) and a target lifecycle state, normally ResumeActivityItem. In your process TransactionExecutor runs the launch item, then walks from the current lifecycle state to the requested one, calling each intermediate callback. That walk is where onStart comes from: nobody sends a "start" message, it is simply the state between created and resumed.

Creating the activity

performLaunchActivity creates an activity-scoped ContextImpl with its own Resources and display, instantiates your class by reflection through AppComponentFactory (which is why an Activity needs a public no-argument constructor), and calls Activity.attach. attach is where the Window comes from: it creates a PhoneWindow, sets the activity as its callback, and gives the activity a WindowManager bound to that window's token. Then onCreate runs.

class MainActivity : ComponentActivity() {

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)   // ComponentActivity restores saved state, wires the lifecycle
        setContent {                          // installs a ComposeView as the window's content
            ClioTheme {
                HomeScreen()
            }
        }
    }
}

After onCreate, TransactionExecutor moves the activity through onStart (and onRestoreInstanceState when there is saved state) to onResume. The DecorView is still not attached to anything at this point; the activity is resumed but invisible.

Attaching the window

At the end of handleResumeActivity, and only then, the framework takes the window's DecorView and calls WindowManager.addView(decor, params). This does two things: it creates a ViewRootImpl, the object that connects a View tree to a window, and it makes the Binder call that registers the window with WindowManager, which creates a WindowState and the input channel for it. ViewRootImpl.setView also calls requestLayout, which schedules the first traversal.

When the main Looper next goes idle, ActivityThread reports activityIdle to system_server. Once your window has drawn and the launch transition has finished, system_server stops the activities that are no longer visible, so the Launcher gets its onStop after your first frame, not before.

Window / PhoneWindow

The framework's abstraction of a top-level surface with a View tree in it. PhoneWindow is the only implementation. It owns the DecorView.

DecorView

The root FrameLayout of every window. It holds the system chrome (insets, action bar if any) and a content frame with id android.R.id.content where your view goes.

ViewRootImpl

Not a View. It is the bridge between a View tree and WindowManager: it receives input, drives measure, layout and draw on VSYNC, and talks to the surface. One per window.

ClientTransaction

A batch of activity commands sent from system_server to an app process in one Binder call. Introduced so that lifecycle changes arrive in order and can be executed together.

What setContent actually does

setContent swaps the classic View content for a single ComposeView and arranges for a Recomposer tied to the window. The composition itself does not run inside onCreate; it runs the first time that view is attached to the window, which happens during the first traversal.

flowchart TD
  S["setContent in onCreate"] --> CV["ComposeView becomes the window content"]
  CV --> AT["first traversal: view attached to the window"]
  AT --> RC["Recomposer created for this window"]
  RC --> C1["Composition: run composables, build the LayoutNode tree"]
  C1 --> C2["Layout: measure and place every LayoutNode"]
  C2 --> C3["Draw: LayoutNodes draw into the Canvas"]
  C3 --> F["First frame"]
  F -. later state change .-> R["Recomposition on a following frame"]
  R --> C2

1. ComponentActivity.setContent creates a ComposeView, hands it your lambda, and calls setContentView. It also tags the DecorView with the activity as LifecycleOwner, ViewModelStoreOwner and SavedStateRegistryOwner, which is how viewModel() and rememberSaveable find their owners later.
2. setContentView goes to PhoneWindow, which installs the DecorView on first use and places the ComposeView inside the content frame.
3. Nothing else happens until the DecorView is attached. On the first traversal, ViewRootImpl dispatches onAttachedToWindow down the tree, and ComposeView responds by creating its composition.
4. Creating the composition means finding or creating a Recomposer for the window. It runs on the main thread, on a dispatcher that is driven by the Choreographer, and it is paused while the lifecycle is below STARTED.
5. An AndroidComposeView is created as the only child of the ComposeView. It is a real View that owns the root LayoutNode and translates View callbacks (measure, layout, draw, input) into Compose ones.
6. The initial composition runs synchronously: your composable lambdas execute, the slot table is filled, and a LayoutNode is emitted for every layout in the tree. All of this is still inside the first traversal, before measure.

The three phases

Compose builds a frame in three phases, and they map onto the View traversal that follows:

• Composition answers "what UI?". It runs your composables and produces the LayoutNode tree. On launch it runs at attach time; later it reruns only for scopes whose state changed.
• Layout answers "where and how big?". Each node measures its children and places them. This runs inside AndroidComposeView.onMeasure and onLayout, that is, during performMeasure and performLayout of the traversal.
• Drawing answers "what pixels?". Each node draws into the Canvas. This runs inside AndroidComposeView.dispatchDraw during performDraw.

@Composable
fun HomeScreen(viewModel: HomeViewModel = viewModel()) {
    // Composition: this body runs on the main thread, inside the first traversal,
    // before anything is drawn. Anything slow here delays the first frame.
    val state by viewModel.state.collectAsStateWithLifecycle()

    Column(Modifier.fillMaxSize()) {          // Layout: measured and placed with the View tree
        Text(state.title)                     // Draw: painted into the window's canvas
    }
}

Recomposer

The scheduler that watches snapshot state, decides which composition scopes are invalid, and reruns them on the next frame. One per window.

Composition

The result of running composables: the slot table (remembered values, groups) plus the node tree it emitted. setContent creates one for the ComposeView.

LayoutNode

Compose's equivalent of a View, but much lighter. Holds modifiers, a measure policy, children and draw commands. Managed by AndroidComposeView, never by the View system.

The first frame: Choreographer, RenderThread, SurfaceFlinger

Nothing reaches the screen until a VSYNC pulse. The frame is built on the main thread, painted on the RenderThread, and combined with every other visible window by SurfaceFlinger. Each of those is a separate step with its own deadline.

sequenceDiagram
  autonumber
  participant M as Main thread
  participant W as WindowManager
  participant R as RenderThread
  participant SF as SurfaceFlinger
  M->>M: scheduleTraversals(): post to the Choreographer
  SF-->>M: VSYNC
  M->>M: doFrame(): run the traversal
  M->>W: relayout() over Binder
  W-->>M: a Surface for the window
  M->>M: attach to window: composition runs
  M->>M: measure, layout
  M->>M: draw: record display list
  M->>R: syncAndDrawFrame(display list)
  R->>R: render on the GPU
  R->>SF: queueBuffer
  SF->>SF: composite all layers
  SF->>SF: scanout
  M-->>W: first frame drawn
  W->>W: remove starting window, log Displayed

1. Scheduling. requestLayout calls scheduleTraversals, which puts a sync barrier on the main Looper (so only asynchronous messages run until the frame is done) and asks the Choreographer to run the traversal on the next VSYNC. The Choreographer gets VSYNC from SurfaceFlinger through a DisplayEventReceiver.
2. VSYNC. Choreographer.doFrame runs its callback queues in order: input, animation, insets animation, traversal, commit. The traversal callback calls ViewRootImpl.performTraversals.
3. Relayout. On the first traversal ViewRootImpl asks WindowManager for its surface. WindowManager creates a SurfaceControl, which is a layer in SurfaceFlinger, and hands back a Surface. The ThreadedRenderer is initialised against it on the RenderThread.
4. Attach. dispatchAttachedToWindow walks the tree. This is the moment the ComposeView creates its composition, so your composables run here.
5. Measure and layout. performMeasure and performLayout run through the DecorView into AndroidComposeView, which runs Compose's layout phase.
6. Draw. performDraw does not paint pixels. It records drawing commands into RenderNode display lists; Compose's draw phase happens here. The display list is then handed to the RenderThread with syncAndDrawFrame, and the main thread is free again.
7. Render. The RenderThread dequeues a buffer from the window's BufferQueue, replays the display list through Skia on the GPU (OpenGL ES or Vulkan), and queues the finished buffer back. That buffer now belongs to SurfaceFlinger.
8. Composite. On its own next VSYNC, SurfaceFlinger takes the newest buffer of every visible layer (status bar, navigation bar, the starting window, your window) and combines them, using Hardware Composer overlays where it can and the GPU where it cannot. The result is scanned out to the panel on the VSYNC after that.
9. Reporting. After the first draw, ViewRootImpl tells WindowManager the window has drawn. WindowManager removes the starting window with the splash exit animation, and ActivityTaskManager logs the Displayed line with the time since startActivity entered system_server.

VSYNC

The display's refresh pulse, 60 to 120 times a second. Every stage of the pipeline aligns its work to it so that frames are produced at a steady rate.

Choreographer

The main thread's frame scheduler. Apps post callbacks (animations, traversals) and it runs them when VSYNC arrives. One per Looper.

RenderThread

A second thread in every app process that talks to the GPU. The main thread records what to draw; the RenderThread draws it. That is why animations that run on the RenderThread, such as ripples, keep going even while the main thread is busy.

SurfaceFlinger

The system compositor. Every window is a layer with its own buffer queue; SurfaceFlinger merges them into the final image once per VSYNC.

BufferQueue

A small ring of graphics buffers shared between a producer (the app's RenderThread) and a consumer (SurfaceFlinger). Two or three buffers deep, so the app can draw the next frame while the last one is displayed.

Where the time goes and what you control

The first stretch of a cold start belongs to the system and costs about the same for every app. Everything after bindApplication is your code. That split is what decides which optimisations are worth doing.

The levers, in order of payoff

1. Make Application.onCreate boring. No synchronous disk or network, no reflection-heavy dependency graph built eagerly, no SDK init that the first screen does not need. Build singletons lazily and move the rest to a background coroutine or to first use.
2. Audit content providers. Open the merged manifest and count the <provider> entries. Remove the ones you do not need with tools:node="remove" and initialise those libraries yourself, later. Use App Startup for the ones that must run early so they share one provider.
3. Keep the first composition light. The first screen should render a cheap loading state immediately and fill in behind a state flag. No runBlocking, no large lists built synchronously, no image decoding in a composable body.
4. Ship a Baseline Profile. ART interprets and JIT-compiles fresh code on the first runs after install. A Baseline Profile tells the installer which methods to compile ahead of time, so the startup path runs as native code from the first launch. Generated with a Macrobenchmark BaselineProfileRule, installed through androidx.profileinstaller, and often worth 20 to 30 percent of cold start time.
5. Use the splash screen correctly. Call installSplashScreen() before super.onCreate() and keep it on screen only while you genuinely have nothing to show. Never add a second custom splash Activity: that is a whole extra activity launch on the critical path.
6. Reduce what gets loaded. Fewer and lighter dependencies, R8 in release builds, and no work in static initialisers of classes touched during startup.

class MainActivity : ComponentActivity() {

    private val viewModel: HomeViewModel by viewModels()

    override fun onCreate(savedInstanceState: Bundle?) {
        val splash = installSplashScreen()          // must be called before super.onCreate()
        super.onCreate(savedInstanceState)
        splash.setKeepOnScreenCondition { viewModel.state.value.isLoading }

        setContent {
            val state by viewModel.state.collectAsStateWithLifecycle()
            ReportDrawnWhen { !state.isLoading }    // logs "Fully drawn" once real content is up
            ClioTheme { HomeScreen(state) }
        }
    }
}

<!-- AndroidManifest.xml: drop a library's auto-init provider you do not want -->
<provider
    android:name="com.example.somelib.InitProvider"
    android:authorities="${applicationId}.somelib-init"
    tools:node="remove" />

Measuring it

Never optimise from a guess. The cheapest measurement is one shell command; the most precise one is a trace.

# Force a cold start and print the timing. Kill the process first.
adb shell am force-stop com.example.clio
adb shell am start -W -n com.example.clio/.MainActivity
# Status: ok
# LaunchState: COLD
# TotalTime: 486      time until the first frame of the launched activity
# WaitTime: 493       TotalTime plus the time spent inside the am command itself

# The same numbers, as the system logs them
adb logcat -s ActivityTaskManager | grep -E "Displayed|Fully drawn"

• am start -W gives TotalTime, which matches the Displayed line. Run it several times and take the median; the first run after install includes one-off dex work.
• Macrobenchmark with StartupTimingMetric and StartupMode.COLD measures timeToInitialDisplayMs and timeToFullDisplayMs over many iterations on a real device, with and without a Baseline Profile.
• Perfetto shows where the time went: the bindApplication, activityStart and Choreographer#doFrame slices on the main thread, and every content provider and class load in between.

Recap