How to Measure Android App Startup Latency and Cold Boot Time Using ADB

Application launch latency is one of the most visible indicators of software performance on Android. Users perceive slow app startup as unresponsiveness, often leading to uninstalls or poor store reviews. For mobile engineers, QA testers, and performance analysts, profiling app launch behaviour under controlled conditions is essential for detecting startup regressions and optimising initial activity rendering.

Android categorises application startup into three primary operational states: cold start, warm start, and hot start. While in-app profiling SDKs and Android Studio Profiler provide deep frame-by-frame timelines, the Android Debug Bridge (ADB) command-line interface provides the fastest, most scriptable method to capture raw launch metrics directly from the device’s Activity Manager (am). By passing the -W flag to am start-activity, you can measure cold, warm, and hot startup times in milliseconds with surgical precision.

Understanding Android Startup Launch States

To accurately interpret ADB launch measurements, it is necessary to understand how the Linux kernel and Android runtime (ART) initialise processes:

• Cold Start: Occurs when the application starts from scratch. The system process has not yet created the app process, requiring the kernel to fork a new process from Zygote, initialise the runtime, load class libraries, inflate XML layouts, and draw the initial frame. This represents the longest startup time.
• Warm Start: The application process is already resident in memory, but the target activity must be recreated from scratch (for example, after being evicted by the system due to low memory, or returning to the app after configuration changes).
• Hot Start: The application and activity are already resident in memory and simply brought to the foreground. The system only executes onRestart(), onStart(), and onResume(), requiring zero layout re-inflation.

Prerequisites for Measuring Latency via ADB

Before executing launch benchmarks, ensure the following requirements are met:

1. Enable Developer Options and USB Debugging on the target Android handset or emulator.
2. Connect the device via USB or Wi-Fi pairing and confirm device connectivity by running adb devices in your workstation terminal.
3. Identify the application package name and launcher activity component name. You can extract this using ADB package inspection tools or the manifest file.

Measuring App Launch Time with the -W Parameter

The core command for measuring launch latency is adb shell am start-activity -W. The -W switch instructs the Activity Manager to wait for the launch to complete and print timing statistics to standard output.

The standard syntax is:

adb shell am start-activity -W -n <package_name>/<activity_name>

For example, to benchmark Google Chrome’s main browser activity:

adb shell am start-activity -W -n com.android.chrome/com.google.android.apps.chrome.Main

The terminal returns detailed startup timing data similar to the following:

Starting: Intent { cmp=com.android.chrome/com.google.android.apps.chrome.Main }
Status: ok
LaunchState: COLD
Activity: com.android.chrome/com.google.android.apps.chrome.Main
TotalTime: 482
WaitTime: 498
Complete

Interpreting ADB Launch Metrics: TotalTime vs WaitTime

Modern Android operating systems (Android 10 and newer) report distinct timing parameters:

• ThisTime: The time in milliseconds spent drawing the final activity launched (relevant when multiple activities or trampolines are chained).
• TotalTime: The total time taken by the app to start the activity, initialise the window, and draw the first frame. This is the primary metric to benchmark application code performance.
• WaitTime: The total elapsed time recorded by the Activity Manager, including inter-process communication (IPC) overhead, scheduling delays, and the transition from the previous activity to the new one.

Benchmarking a True Cold Start

To record an authentic cold start, you must force-stop the application process completely before issuing the start command. This purges the process from memory and flushes cached runtime references:

adb shell am force-stop com.example.myapp
adb shell am start-activity -W -n com.example.myapp/.MainActivity

Inspect the output to confirm that LaunchState explicitly reads COLD.

Benchmarking Warm and Hot Starts

To measure warm and hot starts, simulate typical mobile multitasking gestures:

Hot Start Measurement

1. Launch the application initially and allow it to draw its interface.

2. Simulate pressing the physical Home button to background the app without killing its process:

adb shell input keyevent KEYCODE_HOME

3. Re-launch the activity using -W:

adb shell am start-activity -W -n com.example.myapp/.MainActivity

Notice that LaunchState indicates HOT and the TotalTime metric drops significantly (typically under 100 ms).

Automating Startup Tests with a Shell Script

Measuring a single run can produce misleading results due to transient background CPU spikes or thermal throttling. To capture reliable statistical averages (mean, standard deviation), execute automated test loops across 10 iterations:

#!/bin/bash
PACKAGE="com.example.myapp"
ACTIVITY=".MainActivity"
RUNS=10

echo "Starting $RUNS cold-launch benchmarks for $PACKAGE..."
for i in $(seq 1 $RUNS); do
    adb shell am force-stop $PACKAGE
    sleep 2
    OUTPUT=$(adb shell am start-activity -W -n $PACKAGE/$ACTIVITY)
    TOTAL_TIME=$(echo "$OUTPUT" | grep "TotalTime" | awk '{print $2}')
    echo "Iteration $i: ${TOTAL_TIME} ms"
done

Profiling Time to Full Display (TTFD)

By default, am start-activity -W measures Time to Initial Display (TTID)—the moment the first frame appears. If your app loads data asynchronously over the network or parses a database after launch, report completion explicitly inside your Android code by calling reportFullyDrawn().

When reportFullyDrawn() is called in code, ADB outputs the additional metric:

TotalTime: 482
WaitTime: 498
FullyDrawnTime: 1120

Leveraging ADB launch benchmarks enables teams to continuously monitor app responsiveness, integrate launch metrics into automated CI/CD pipelines, and prevent startup regressions from reaching end users.