Understanding the Android Input Event Flow: From Hardware to Application

This article explains how Android handles input events—from the physical device to the final View that receives the touch.

1. Input event forwarding process

The system receives callbacks such as onKeyEvent , onTouchEvent , etc., and forwards them through a layered pipeline.

2. How the physical device sends data to the kernel

In Linux, input devices appear under /dev/input/ as event0 , event1 , … . When a touch screen is pressed, the driver detects a voltage change on a GPIO pin, triggers an interrupt, and the driver reads the binary data (e.g., 01011010 ) from the device.

3. Kernel to Android framework

The kernel passes the raw events to the Android framework via the InputManagerService . The service is created in SystemServer.java :

SystemServer.java -->
    startOtherServices() -->
    /* construct InputManagerService */
    inputManager = new InputManagerService(context);
    /* pass to WindowManagerService */
    wm = WindowManagerService.main(context, inputManager, ...);
    inputManager.setWindowManagerCallbacks(wm.getInputMonitor());
    /* start the two threads */
    inputManager.start();

During construction, a native NativeInputManager creates an EventHub , which: Creates an epoll object and registers the file descriptors of all /dev/input devices. Uses inotify to watch for device addition/removal. Creates a pipe for internal communication.

The InputManager then creates an InputDispatcher , an InputReader , and their respective threads.

4. Dispatching events inside the framework

The InputReaderThread calls eventHub.getEvents() , which opens devices under /dev/input , creates RawEvent objects (DEVICE_ADDED, FINISH_DEVICE_SCAN, touch events) and feeds them to the InputDispatcher .

For a touch event, the corresponding InputDevice invokes its InputMapper (e.g., MultiTouchInputMapper ) which processes slot, x, y, pressure, etc., and finally calls InputDispatcher.notifyMotion() . The dispatcher may apply an inputFilter , then creates a MotionEntry and pushes it onto mInboundQueue for the dispatcher thread.

The dispatcher thread selects the focused window, builds an inputTargets array (including any registered monitors), and delivers the motion to each target.

5. From the framework to the app process

The framework creates an InputChannel pair for each window. The server side is kept by WindowManagerService , the client side is handed to the app’s ViewRootImpl :

InputChannel[] inputChannels = InputChannel.openInputChannelPair(name);
// server side
win.setInputChannel(inputChannels[0]);
// client side
inputChannels[1].transferTo(outInputChannel);
// register with InputManagerService
mInputManager.registerInputChannel(win.mInputChannel, win.mInputWindowHandle);

6. From the app process to the Activity and its Views

ViewRootImpl creates an InputChannel and a WindowInputEventReceiver . When a motion reaches the app, the InputDispatcher delivers it to the appropriate WindowState , which forwards it to the ViewRootImpl . ViewRootImpl then walks the view hierarchy, delivering the event to the specific View that contains the touch coordinates.

7. Summary

The Android touch‑event pipeline involves hardware interrupt handling, kernel event devices, native EventHub , Java‑level InputManagerService , InputDispatcher , WindowManagerService , ViewRootImpl , and finally the target View . Understanding each step helps developers debug unresponsive touch issues and design custom input handling.