Input系统学习笔记

平台：android2.2

场景：全键盘电子书项目需要为系统新增需要按键，同时对于一些touch事件需要做特殊的处理，所以需要对整个input进行一些了解。

时间：2011.12~2012.3

1.为系统添加新的硬件按键。（http://www.eefocus.com/chongzi865458/blog/11-06/225120_23131.html）

物理键盘的按键响应，能够被上层应用所接收到，主要涉及到以下几个文件：

(1).system/usr/keylayout/xxx-keypad.kl(qwerty.kl)——与扫描码(kernel上报)相关的按键映射文件(将kernel上报的扫描码转换成字符串，同时带有flag信息)，通过KeyLayoutMap.cpp进行解析，然后在EventHub.cpp调用(KeyLayoutMap的map()方法)，按照映射文件转换成相应的键值并将扫描码和键码返回给KeyInputQueue。

(2).frameworks/base/include/ui/KeycodeLabels.h——在EventHub.cpp中使用。将qwerty.kl被转换出来的字符串，再次进行转换成int，与KeyEvent.java中的按键码一致。

KeycodeLabels.h中还对qwerty.kl中的flag信息进行了转换。Flag信息如下：

{ “WAKE”, 0x00000001 }, // 可以唤醒睡眠，并通知应用层

{ “WAKE_DROPPED”, 0x00000002 }, // 可以唤醒睡眠，不通知应用层

{ “SHIFT”, 0x00000004 }, // 自动附加SHIFT

{ “CAPS_LOCK”, 0x00000008 }, // 自动附加CAPS_LOCK

{ “ALT”, 0x00000010 }, // 自动附加ALT

(3).frameworks/base/core/Java/android/view/KeyEvent.Java——Java框架的API。

(4).frameworks/base/core/res/res/values/attrs.xml——属性的资源文件，需要修改其中的name=”keycode”的attr。



如图所示，从kernel的扫描码，到上层的KeyEvent.java，一共经历了两次转换：kl文件—将扫描码转换成字符串；KeycodeLabels.h—将字符串转换成与KeyEvent一致的int按键码。

添加好4个文件后，就可以在应用中响应到相关的KeyCode。但是，如果在一个EditText中，想通过按下一个物理键盘按键“A”，直接将“A”显示到EditText中，这就还需要另外一个家伙的支持——kcm文件。

关于kcm文件，起作用就是用于将按键的码映射为文本可识别的字符串（例如，显示的标签等）。当然，kcm需要被解析，起对应的解析文件就是KeyCharacterMap.cpp。kcm文件在system/usr/keychars/xxxx-keypad.kcm.bin，因为其本身较大，因此使用makekcharmap工具转化成二进制的格式。其源文件的内容部分如下：

[type=QWERTY]

keycode display number base caps fn caps_fn

A ‘A’ ‘2’ ‘a’ ‘A’ ‘#’ 0x00

B ‘B’ ‘2’ ‘b’ ‘B’ ‘<’ 0x00

C ‘C’ ‘2’ ‘c’ ‘C’ ‘9’ 0x00E7

display 键盘上显示的字符(丝印)

number 一般不需要

base 不使用组合键默认 显示的字符

caps Shift + 按键 显示的字符

fn Alt + 按键 显示的字符

caps_fn Shift +Alt+按键 显示的字符

第一列是转换之前的按键码，第二列之后分别表示转换成为的显示内容（display），数字（number）等内容。这些转化的内容和KeyCharacterMap.h中定义的getDisplayLabel()，getNumber()等函数相对应。所以，当你新添加的按键，或者是系统原来的按键，需要有相关的字符显示的时候，可以修改kcm文件。

KeyCharacterMap是一个辅助的功能：由于按键码只是一个与UI无关整数，通常用程序对其进行捕获处理，然而如果将按键事件转换为用户可见的内容，就需要经过这个层次的转换了。

KeyCharacterMap需要从本地层传送到Java层，JNI的代码路径如下所示：

frameworks/base/core/jni/android_text_KeyCharacterMap.cpp

KeyCharacterMap.Java框架层次的代码如下所示：

frameworks/base/core/Java/android/view/KeyCharacterMap.Java

android.view.KeyCharacterMap类是Android平台的API可以在应用程序中使用这个类。

android.text.method中有各种Linstener，可以之间监听KeyCharacterMap相关的信息。

DigitsKeyListener NumberKeyListener TextKeyListener。

2.输入事件响应到上层的流程。

从下往上，依次为：

(1).frameworks/base/libs/ui/EventHub.cpp::getEvent()

该函数中有一个while(1)的循环，通过poll的方式进行处理。

(2).frameworks/base/services/jnicom_android_server_KeyInputQueue.cpp::readEvent()

Jni函数，封装了getEven()，被java框架中的KeyInputQueue.java中的InputDeviceReader线程调用。

(3).frameworks/base/services/java/com/android/server/KeyInputQueue.java

此类中有一个关键的线程InputDeviceReader，其run()方法中亦是通过while(true)的方式调用readEvent()，进行监听input事件，当然，其最终调用到getEvent()中poll()。此处通过InputDevice.java描述了input对象，同时监听处理了input设备的变化。并将调用其子类WMS中的KeyQ实现的preprocessEvent()方法进行预处理。

同时，在KeyInputQueue.java中存在一个getEvent()方法，将被WMS中的InputDispatcherThread线程调用，在其中通过mFirst.wait(end-now)进行了超时等待，在KeyInputQueue.java中的addLocked()中进行了mFirst.notify()。而addLocked()函数，正是在InputDeviceReader线程的preprocessEvent()方法后，有机会被进行调用。(即先监听event事件并处理，再确认是否需要dispatcher)

(4).frameworks/base/services/java/com/android/server/WindowManagerService.java

有三个重要的相关对象或线程，分别是：

1#.mQueue，其为KeyQ的对象，KeyQ继承于InputDeviceReader，其实现了关键的preprocessEvent()方法。在其中根据input事件的不同，继续了相关的处理，与mPolicy(PhoneWindowManager对象)进行了交互。

比如说，在case RawInputEvent.EV_KEY的情况下，调用了

mPolicy.interceptKeyTq(event, !screenIsOff)，

即为对按键消息抛入到消息队列前的过滤处理。

2#.mInputThread，其为InputDispatcherThread线程的对象，被用来dispatcher输入事件。其run()方法中也是在while(true)的情况下，调用了KeyInputQueue.java中的getEvent()函数，等待着可以dispatcher的输入事件，然后根据输入事件的种类，分别调用dispatchKey()，dispatchPointer()，dispatchTrackball()等方法

。在这些方法中，将再次与PhoneWindowManager交互，调用其interceptKeyTi()函数，即为dispatcher前的过滤函数。

3#.PolicyThread线程，其即为PhoneWindowManager对象mPolicy所在的线程，拥有自己的消息队列和消息循环。

(5).EventHub.cpp中的getEvent()进入死循环，执行pollres = poll(mFDs, mFDCount, -1)等待设备结点处有数据写入（也就是有键按下），当有数据写入时执行下面的for循环，找出是哪个fd中有内容写入，并读出写入的数据res = read(mFDs[i].fd, &iev, sizeof(iev))。

这里只读出了TYPE和Scancode()，而不会有Keycode，硬件层只能向设备文件写入Scancode，而Keycode是上层要用的，由map得到。接下来执行err = mDevices[i]->layoutMap->map(iev.code, outKeycode, outFlags)map出Scancode对应的Keycode和Flags。

3.关于TouchEvent的上报到应用层的过程，以及实例演示解析。

当touch事件上报后，将调用dispatchTouchEvent()分发事件。先看ViewGroup类中的dispatchTouchEvent()函数，其大致过程，是将事件按照View的树形结构一直往里层传递，直到最里层的view获取到事件。查看View类中的dispatchTouchEvent()函数发现，若此时View上存在ouTouch的监听器，则调用它，否则调用view的onTouchEvent()方法。

从这个过程可以知道，默认情况下，View上面的最里层的子View处理touch事件的优先级最高，而activity最低。

同时，根据返回值来确定父view是否可以继续处理这个事件(onTouchEvent()函数返回true则表示此事件已经被处理掉)。

需要注意的是，在ViewGroup类中的dispatchTouchEvent()函数中，在往子View分发事件的时候，有一个关于onInterceptTouchEvent()函数判断。此处，即为打断事件分发函数！在同一个view上，先调用onInterceptTouchEvent()，若返回true，则表示此View接管了这次的事件，而不再将事件往子view上分发。

存在一个这个的问题：

有一个LinearLayout，里面有很多的child view，他问如何监听这个LinearLayout的Click事件？他的做法是：

setClickable(true);

setOnClickListener(listener);

最后他发现listener中的回调函数根本不会被调用。

因为存在一些Event，如：Click、LongPress、DoubleClick等。这些Event通常是人为的将“硬件触发的Event”封装得来的。例如Click Event就是使用了TouchEvent 中的MotionEvent.ACTION_UP和MotionEvent.ACTION_DOWN封装而来的。默认情况下，它们使得onTouchEvent()处理函数返回了true。因此，Linearlayout的孩子们一旦设置了自己的Click事件监听器，Linearlayout本身就拿不到事件了，因为它的孩子已经进行了处理。

4.关于KeyEvent的上报以及处理流程。

(1).interface—->KeyEvent.Callback::onKeyDown()。一般通过KeyEvent对象event.dispatch()进行调用；

(2).interface—->Window.Callback::dispatchKeyEvent()；

(3).View::dispatchKeyEvent()。一般是其子类重载此函数。注意区分与Window.Callback::dispatchKeyEvent()的区别！

同时View实现了KeyEvent.Callback。

(4).PhoneWindow中的DecorView继承View，重载了View的dispatchKeyEvent()方法；

(5).Activity实现了Window.Callback和KeyEvent.Callback。因此，其子类亦可以重载onKeyDown()和dispatchKeyEvent()方法。

请看图：



在MyAcitivy中重载了dispatchKeyEvent()和OnKeyDown()方法，return调用super.xxx()。

为什么LOG显示先从DecorView开始dispatch？—ViewRoot的调用！WMS跨进程调用ViewRoot中的W类的相关方法，然后在ViewRoot::deliverKeyEvent通过mView.dispatchKeyEventPreIme(event)调用到DecorView里面！



在MyAcitivy的dispatchKeyEvent()函数中直接return true。



在MyAcitivy的OnKeyDown()函数中return true。

5.其他零碎知识点

(1).Event设备在用户空间大多使用read、ioctl、poll等文件系统的接口进行操作，read用于读取输入信息，ioctl用于获得和设置信息，poll调用可以进行用户空间的阻塞，当内核有按键等中断时，通过在中断中唤醒poll的内核实现，这样在用户空间的poll调用也可以返回。

(2).可以使用getevent对Event设备进行调试。

(3).在处理过程中，将搜索路径下面的所有Input驱动的设备节点，这在openPlatformInput()中通过调用scan_dir()来实现，scan_dir()将会从目录中查找设备，找到后调用open_device()将其打开。open_device()函数还将打开system/usr/keylayout/中的kl文件来处理。

(4).在手机系统中经常使用的键盘（keyboard）和小键盘（kaypad）属于按键设备EV_KEY，轨迹球属于相对设备EV_REL，触摸屏属于绝对设备EV_ABS。