Touch Input Pipeline

The Touch Input Pipeline

The Android input subsystem is a high-performance, low-latency pipeline responsible for routing raw kernel events to the correct application UI components. The pipeline spans the Linux kernel, system server, and the application process.

Kernel to InputReader

When a user touches the screen, the hardware touch controller generates a hardware interrupt. The Linux kernel's input driver (such as evdev) reads the hardware registers and translates these interrupts into standard Linux input events, exposed via /dev/input/eventX character devices.

The system server process runs the InputManagerService (IMS), which instantiates two critical C++ threads:

1. InputReader
2. InputDispatcher

The InputReader thread uses epoll to monitor the /dev/input/ directory. When an event arrives, EventHub reads the raw input_event struct. The InputReader processes this raw data, applies device-specific configuration (like touch calibration and virtual keys), and translates it into an Android NotifyMotionArgs structure.

// frameworks/native/services/inputflinger/reader/InputReader.cpp
void InputReader::loopOnce() {
    size_t count = mEventHub->getEvents(timeoutMillis, mEventBuffer, EVENT_BUFFER_SIZE);
    if (count) {
        processEventsLocked(mEventBuffer, count);
    }
    mQueuedListener->flush();
}

InputDispatcher and Focus Window Selection

The InputReader pushes events to the InputDispatcher thread queue. The InputDispatcher is responsible for routing the event to the correct application window.

To do this, it relies on the WindowManagerService (WMS). The WMS maintains the exact z-order, geometry, and input state of every window on the screen. It periodically syncs this window list to the InputDispatcher via InputWindowHandle structures.

When a touch down (ACTION_DOWN) occurs, the InputDispatcher performs a hit-test:

1. It iterates through all visible windows from top to bottom (highest Z-order first).
2. It checks if the touch coordinates fall within the window's bounds.
3. It verifies that the window is touchable (e.g., doesn't have FLAG_NOT_TOUCHABLE).

Once a target window is found, the dispatcher sends the event over a Unix Domain Socket (specifically an InputChannel) to the application process.

Event Processing in the Application

In the application process, the ViewRootImpl listens to the other end of the InputChannel. When the event arrives, it traverses the view hierarchy:

1. DecorView
2. ViewGroup (handling onInterceptTouchEvent)
3. View (handling onTouchEvent)

Touch Pointer Capture

Android supports "Pointer Capture" for scenarios where an app needs raw mouse or touch data without window bounds restrictions (e.g., first-person games). When pointer capture is requested via View.requestPointerCapture(), the WMS notifies the InputDispatcher to route all motion events directly to that specific window, bypassing the standard hit-testing logic and hiding the system cursor.

To inspect the input pipeline state:

adb shell dumpsys input

This command outputs the state of the InputReader, connected devices, the InputDispatcher queue, and all registered input windows.