How to Inspect Input Dispatcher State and Touch Queues on Android Using ADB dumpsys input

When developing touch-intensive mobile applications, responsive mobile games, or custom input methods on Android, diagnosing input latency, dropped tap gestures, or phantom touches can prove exceptionally challenging. The Android OS manages physical touch screens, hardware keyboards, mice, and game controllers through the native InputReader and InputDispatcher subsystems inside system_server. The Android Debug Bridge (ADB) dumpsys input command provides a comprehensive diagnostic window into these low-level C++ components, enabling engineers to inspect event queues, focused window channels, touch calibration transforms, and ANR (Application Not Responding) triggers.

Understanding the Android Input Pipeline

User interactions follow a strict hardware-to-software execution pipeline inside the Android operating system:

1. Linux Kernel Event Nodes: When a user touches the digitizer glass or presses a volume key, the hardware driver emits raw evdev Linux input events to /dev/input/event*.
2. InputReader: Running on a dedicated thread inside system_server, InputReader decodes raw hardware scans into structured Android RawEvent objects, applying display orientation matrices and touch screen calibration offsets.
3. InputDispatcher: The InputDispatcher thread evaluates the spatial coordinates against the active window manager hierarchy, determining which UI window and process owns the touch region. It routes the event over a non-blocking Unix domain socket channel directly to the application process’s ViewRootImpl.

If an application’s main UI thread hangs or takes longer than 5,000 milliseconds to acknowledge an input event sent over this socket, InputDispatcher detects the queue stall and flags the event as an ANR condition.

Generating an Input Subsystem Diagnostic Dump

Ensure your Android device has USB Debugging enabled and is connected to your development machine. Open a terminal and verify ADB connectivity:

adb devices

To inspect the entire runtime state of the input subsystem, execute:

adb shell dumpsys input

The resulting report is divided into several primary sections: Input Reader State, Input Dispatcher State, and Input Classifier State. Because the full dump can exceed several thousand lines, piping into text filters allows targeted inspection.

Auditing Connected Input Devices and Calibration Offsets

To view all physical touch screens, stylus digitizers, physical keys, and virtual sensors recognized by the operating system, search the dump for the InputReader device list:

adb shell dumpsys input | grep -A 25 "Device "

For the built-in touch screen (typically labeled touchscreen, sec_touchscreen, or synaptics), inspect the device properties:

Device: Touchscreen
  IsExternal: false
  Sources: 0x00001002 (touchscreen)
  KeyboardType: 0
  Motion Ranges:
    X: min=0, max=1079, flat=0, fuzz=0, resolution=0
    Y: min=0, max=2399, flat=0, fuzz=0, resolution=0
    Pressure: min=0, max=255

This confirms the native hardware coordinate resolution (e.g., 1080×2400) and pressure sensitivity scale. If touch coordinates appear offset or inaccurate after display scaling modifications, verify that the SurfaceOrientation and affine transformation matrix match the active screen orientation.

Inspecting the Focused Window and Dispatcher Channels

When taps fail to register inside an application, the cause is frequently a focus mismatch—an invisible system overlay, lingering dialog, or permission prompt intercepting touches. InputDispatcher maintains the authoritative record of which window currently owns input focus.

To query the currently focused window and application channel, execute:

adb shell dumpsys input | grep -E "(FocusedApplication|FocusedWindow)" -A 2

The terminal outputs the exact package name, activity token, and window handle receiving key and motion events:

FocusedApplication: name='AppWindowToken{... token=ActivityRecord{... com.example.app/.MainActivity}}', dispatchingTimeout=5000.000ms
FocusedWindow: name='Window{... com.example.app/com.example.app.MainActivity}'

If FocusedWindow displays an unexpected package (such as a system UI dialog or third-party accessibility overlay), that window is intercepting the user’s touch events before they reach your app.

Monitoring Inbound Queue (InboundQueue) and Outbound Queues

When an application suffers from severe UI thread jank, touch events queue up inside InputDispatcher. Each registered window channel has an associated outboundQueue and waitQueue.

Inspect the queue depths for active window connections:

adb shell dumpsys input | grep -A 8 "Connection:" | grep -E "(name|outboundQueue|waitQueue)"

Under smooth operation, outboundQueue (events waiting to be transmitted over the socket) and waitQueue (events received by the app but awaiting acknowledgment) should report lengths of 0 or 1. If waitQueue grows to tens or hundreds of items, the target application is blocking its main thread and is on the verge of throwing an ANR.

Auditing Global Key Interceptions and Navigation Policies

Certain physical buttons—such as Volume Up, Volume Down, Power, and Home—are intercepted by the system’s PhoneWindowManager policy before reaching applications. To inspect which keys are currently intercepted or consumed globally, search for policy states:

adb shell dumpsys input | grep -A 10 "Global Intercept Keys"

This reveals the system’s key intercept mapping, helping you determine why specific hardware keys (like custom gamepad triggers or barcode scanner keys) are not being passed through to your application’s onKeyDown handler.

By leveraging dumpsys input, Android developers and QA engineers can diagnose touch anomalies, pinpoint UI latency bottlenecks, and audit hardware input configurations with forensic precision.