How to Inspect Activity Launch Sequences and Intent Decisions on Android Using ADB dumpsys activity starter

Activity Launch Orchestration in the Android Framework

In the Android operating system, launching an application component is far more complex than spawning an executable binary. Whenever an application calls startActivity(), the request passes into ActivityTaskManagerService (ATMS) and is processed by an internal engine known as ActivityStarter. This component is responsible for translating the caller’s intent into a physical window on screen.

During the launch sequence, ActivityStarter evaluates a complex matrix of conditions: it checks caller permissions, verifies package visibility, inspects intent flags (such as FLAG_ACTIVITY_NEW_TASK, FLAG_ACTIVITY_CLEAR_TOP, or FLAG_ACTIVITY_SINGLE_TOP), checks activity launch modes (standard, singleTop, singleTask, singleInstance), and calculates task affinity to decide whether the activity should be placed into an existing task stack, spawned in a new task container, or launched into a multi-window display area.

When unexpected application behavior occurs—such as duplicate activity instances, unexpected task clearing, black screen launch stalls, or intent rejections—developers and QA engineers often struggle to understand why ATMS made a specific routing decision. Through the Android Debug Bridge (ADB), the command dumpsys activity starter exposes the internal decision log of ActivityStarter, capturing the exact parameters, intent flags, and placement results of recent activity launches.

Establishing an ADB Session and Checking ATMS Readiness

To inspect activity launch sequences, connect your Android device via USB or Wireless ADB, and verify that USB debugging is active:

# Verify connected Android device
adb devices -l

# Check that Activity Manager service is active
adb shell service check activity

If the service is responsive, the shell confirms Service activity: found. You can now execute diagnostics against the activity starter subsystem.

Dumping ActivityStarter Decision Logs via ADB

The dumpsys activity starter command outputs a circular ring buffer containing detailed diagnostic records of recent activity launches evaluated by the framework:

# Dump recent ActivityStarter decision records
adb shell dumpsys activity starter

The output records each launch attempt in chronological order:

ACT START:
  caller=com.google.android.apps.nexuslauncher (pid=2150, uid=10185)
  intent=Intent { act=android.intent.action.MAIN cat=[android.intent.category.LAUNCHER] flg=0x10200000 cmp=com.example.app/.MainActivity }
  result=0 (START_SUCCESS)
  targetStack=Task{... id=452 rootAffinity=com.example.app}
  realCallingPid=2150 realCallingUid=10185
  reason=startActivityMayWait
  ActivityStarter:
    mLaunchMode=0
    mLaunchFlags=0x10200000
    mDoResume=true
    mAddingToTask=false
    mReuseTask=Task{id=452}

Understanding ActivityStarter Diagnostic Fields

Each recorded launch block details key operational fields:

• caller: The package name, PID, and Linux UID of the entity initiating the launch request (such as the home screen launcher or a notification service).
• intent: The complete intent payload, including action (act), category (cat), target component class (cmp), and intent bitmask flags (flg).
• result: The integer launch result code returned by ATMS (e.g. 0 = START_SUCCESS, -1 = START_INTENT_NOT_RESOLVED, -2 = START_CLASS_NOT_FOUND, -4 = START_PERMISSION_DENIED).
• mLaunchFlags: The resolved bitmask of intent flags governing task placement (such as 0x10000000 representing FLAG_ACTIVITY_NEW_TASK).
• mReuseTask: Indicates whether an existing background task container was brought to the foreground instead of allocating a new task stack.
• reason: Internal framework method that triggered the launch (e.g. startActivityMayWait or startActivityInner).

Diagnosing Launch Flag Conflicts and Intent Rejections

A frequent bug in Android application architecture is the improper use of intent flags when launching activities from non-activity contexts (such as background broadcast receivers or services). If an app attempts to launch an activity from a background service without passing FLAG_ACTIVITY_NEW_TASK, the launch fails on modern Android releases.

Filter the dump output for a specific application to inspect its launch history and identify failed attempts:

# Filter launch starter records for target application
adb shell dumpsys activity starter | grep -A 20 "com.example.app"

If result reports a negative integer, examine the specific error code:

• START_PERMISSION_DENIED (-4): The calling UID lacked required permissions to access an unexported activity.
• START_FORWARD_AND_REQUEST_CONFLICT (-3): The intent incorrectly combined FLAG_ACTIVITY_FORWARD_RESULT with startActivityForResult().
• START_TASK_TO_FRONT (2): The activity was already running at the top of an existing task stack, so the framework brought the task forward without creating a new instance.

Testing Activity Launches and Flag Combinations via ADB

Once you identify the intent structure via dumpsys activity starter, you can simulate different launch flag combinations directly from the command line using the am start tool:

# Launch activity with explicit NEW_TASK and CLEAR_TOP flags
adb shell am start -n com.example.app/.MainActivity \
    -f 0x14000000 \
    --es source "adb_diagnostics"

Immediately execute dumpsys activity starter following the command to verify how ActivityStarter evaluated your flags and allocated the task container.

Using dumpsys activity starter gives developers and engineers definitive clarity into the Android window management pipeline, eliminating guesswork when debugging navigation stacks, deep links, and multi-window task placement.