still under construction, but feel free to explore :)
HOME / Articles/Tutorials / Android Articles/Tutorials / Android Internals / Android Input Event Handling

Android Input Event Handling

Detailed description of the internal input event handling process from the Linux kernel to the Android userspace and foreground apps.

For details about input event injection, hacking, rooting, insecure boot, pack/repack images, rom customization and many others check:


Input events can be passed from different places for different purposes but mosly these are done from the hardware, internal services and instrumentation. In this article I will describe the process of passing/injecting and dispatching input events. I will focus on the larest Android release (4.3_r2), but will also include notes for older versions.

main framework users of injectinputevent as for android 4.3_r2: sendKeySync(android.view.KeyEvent) sendPointerSync(android.view.MotionEvent) sendTrackballEventSync(android.view.MotionEvent) injectInputEvent(android.view.InputEvent,boolean) for 4.1/4.2 injectEventSync(android.view.InputEvent) injectKeyEvent(android.view.KeyEvent) injectMotionEvent(int,int,long,float,float,float) sendDownAndUpKeyEvents(int) sendEvent(int,int,long) main used files and classes as for android 4.3_r2


Before 2.3

Main classes
/ services/ java/ com/ android/ server/ / services/ java/ com/ android/ server/ / services/ jni/ com_android_server_KeyInputQueue.cpp / libs/ ui/ EventHub.cpp / include/ ui/ EventHub.h / cmds/ input/ input (shell script) / cmds/ input/ src/ com/ android/ commands/ input/
KeyQ is in KeyQ extends KeyInpuQueue KeyQ implements preprocessEvent KeyQ mQueue; KeyInpuQueue defines and start new Thread("InputDeviceReader"), which calls readEvent() from the native implementation of KeyInpuQueue, which calls getEvent in EventHub, which polls the devices for new events when a RawEvent is returned in the InputDeviceReader thread preprocessEvent() is called which is implemented in WindowManagerService.KeyQ after that we call addLocked() puts in in (QueuedEvent)mFirst->next, where is got from mQueue.getEvent() meanwhile in the run() implementation of InputDispatcherThread InputDispatcherThread.process()->mQueue.getEvent() Both InputDeviceReader and InputDispatcherThread threads are strated in the constructor of WindowManagerService. after that in process() depending of the event dispatchKey, dispatchPointer, dispatchTrackball are called, which call theirs respective method in the current IWindow implementation ex: focus.mClient.dispatchKey(event);, where focus/target is an intance of WindowManagerPolicy.WindowState returned by the mKeyWaiter.waitForNextEventTarget after that starting from the current implementation of IWindow like ViewRoot.W it propagtes to the whole view tree. 2.2.3< -- <3.2.4 keyQ.preprocess = parsebbefore... NO: KeyInputQueue, KeyQ core/ java/ android/ hardware/ input/ >= 4.1.1 core/ java/ android/ hardware/ input/ >= 4.1.1 services/ java/ com/ android/ server/ input/ >= 4.1.1 services/ java/ com/ android/ server/ <= 2.3.7 services/ java/ com/ android/ server/ <= 2.3.7 services/ java/ com/ android/ server/ wm/ >= 3.2.4 services/ java/ com/ android/ server/ wm/ >= 3.2.4, <=4.1.1

Basic Interactions

Author: DjoDjo