From integrated EMR sensors to USB- and Bluetooth-connected tablets, Wacom hardware is used with an ever-increasing number of Android devices. While Android was limited to only reporting basic stylus data in the past, there has been significant work in recent releases to improve the richness of the pen experience.

This document provides an overview of framework that exists in Android to support pen input, and is intended to serve as a guide for manufacturers and modders of Android devices.

Kernel Devices

The Linux kernel provides the foundation upon which the Android OS is built. Specialized Wacom drivers provide support for the digitizers themselves, setting them up and exporting their properties to sysfs for use by the Android framework.

As with other Linux systems, a userspace daemon is responsible for managing devfs. In Android’s case, this daemon is ueventd. As hardware comes and goes, device nodes are created under the /dev/input directory. This directory is home to input devices of all types: touchscreens, accelerometers, etc.

Android Input Service

The raw kernel evdev devices are managed by Android’s input service. This service acts as the userspace input driver, transforming events to a form consistent with what is defined in the Android API. The service is powered by an instance of the InputManager class, which starts two pipelined event pumps. The first pump cooks raw kernel events and packages each input packet into a snapshot. The second batches multiple snapshots into a single event for efficient delivery to apps.

InputReader Pump

The first pump is an InputReader, which makes use of the EventHub to stay updated on the current state of all known input devices. The event hub is self-described as "grand central station for events." It keeps track of devices as they come and go, and can be polled for the latest list of input events that have appeared from all devices.

Each loop through, the input reader requests a list of all new events from the event hub. For each event, it locates the associated InputDevice source and has it perform additional processing. These in turn rely on a set of "input mappers" for further processing of the events in a form specific to the device type (e.g. a touchscreen may have its positional data processed by a TouchInputMapper, while a mouse would would process the same data with a CursorInputMapper).

Generally speaking, the data recieved from the kernel is left in its raw state. The input mappers usually store the value directly, or may provide it to an "accumulator" (e.g. for relative-to-absolute conversion). Sometimes, however, more extensive cooking is necessary — for example, adjusting for the parameters specified in an input device configuration file.

When an input mapper notices that it has recieved a complete event packet from the kernel, it appends its public state to the end of a queue for the InputDispatcher pump to deal with.

InputDispatcher Pump

The InputDispatcher pump is run periodically to flush accumulated events from the InputReader out to applications. Because of the overhead involved with notifying apps on every kernel packet, the dispatcher may batch several rapidly-successive events together for delivery. This preserves intermediate states without needing to make multiple notifications per screen refresh.

The InputDispatcher is responsible for more than just relaying events from hardware: it also handles event injection, ANR warnings, etc.

Framework Features


Android provides "Input Device Configuration" files to adjust how the kernel device events are interpreted. For instance, it is possible to tell Android that it should adjust the reported touch size by a given scale factor. It is also possible to use these files to adjust how Android treats the device as a whole: e.g. changing the "deviceType" to a specific type if Android mis-detects it. A complete list of IDC file properties is available for reference.

It should be noted that IDC files cannot be used to specify a calibration for the toushcreen or EMR sensor. No facility is yet available in Android to achieve this, though the use of third-party tools such as tslib and patches to the InputReader to apply calibration parameters has been used as a workaround in the past.


Android provides a few different programs that allow you to debug what is going on with input devices at the framework level.


The dmesg command can be used to determine if the kernel is aware of the digitizer or not. Log lines prefixed with "input" should contain both the name of the input device and a sysfs path. Wacom drivers may produce their own messages, prefixed with "Wacom".


Android provides the getevent tool for debugging kernel devices. This tool can be used to get a list of all known kernel input devices, view their properties, and even watch the event stream in realtime.

Documentation for the kernel’s input event interface can be found online. See especially the docs for event codes and the multi-touch protocol.


The dumpsys tool (see here) is able to dump information about Android services. In particular, the input and window services contain a wealth of information about the state of Android’s own input driver.