1.开始肯定先说的是驱动这块,硬件是软件服务的,在Android这块C和java交互,有两种方式:
- static jboolean
- android_server_KeyInputQueue_readEvent(JNIEnv* env,jobject clazz,
-
jobject event) - {
-
gLock.lock(); -
sp hub = gHub; -
if(hub == NULL) { -
hub = new EventHub; -
gHub = hub; -
} -
gLock.unlock(); -
-
int32_t deviceId; -
int32_t type; -
int32_t scancode, keycode; -
uint32_t flags; -
int32_t value; -
nsecs_t when; -
boolres = hub->getEvent(&deviceId,&type, &scancode,&keycode, -
&flags, &value,&when); -
-
env->SetIntField(event, gInputOffsets.mDeviceId,(jint)deviceId); -
env->SetIntField(event, gInputOffsets.mType,(jint)type); -
env->SetIntField(event, gInputOffsets.mScancode,(jint)scancode); -
env->SetIntField(event, gInputOffsets.mKeycode,(jint)keycode); -
env->SetIntField(event, gInputOffsets.mFlags,(jint)flags); -
env->SetIntField(event, gInputOffsets.mValue,value); -
env->SetLongField(event, gInputOffsets.mWhen, -
(jlong)(nanoseconds_to_milliseconds(when))); -
-
returnres; - }
-->windowManagerService.process{
4.KeyEvent事件的传递主要可以划分为三步:过滤器、View树、Activity.
过滤器部分对应的是(frameworks/base/policy/base/phone/com/Android/internal/policy/impl/PhoneWindowManager.java)PhoneWindowManager.java中的interceptKeyTq和interceptKeyTi这两个方法。它们的代码可以在中看到。
这两个过滤器最大的不同就是interceptKeyTq用于RawEvent,而interceptKeyTi用于KeyEvent。
在一个没有实体键盘的机器上,Power键会被interceptKeyTq这个过滤器吃掉用来调用关机对话框或者使机器休眠。而Home键会被interceptKeyTi这个过滤器吃掉,用来把当前Activity切换到后台并把桌面程序切换到前台。所以,应用程序在View和Activity的onKeyDown/Up中是监听不到这两个按键的。除了这两个键以外的按键,都有机会继续前进。接下来,KeyEvent会先经过interceptKeyTi过滤器,如果这个过滤器不吃掉的话,就会继续前进,进入View树,如果没有被哪个View吃掉的话,最后进入到Activity的onKeyDown/Up方法中。
当一个KeyEvent经过上面的过程还没有被吃掉的话,系统就会利用它做一些定制的功能。比如音量键被系统用来调整声音,多媒体按键用来控制媒体播放,搜索键用来快速打开搜索功能,返回键用来退出当前Activity等
---------------------------------------
Android 4.0中按键的处理流程
按键在Android系统中,有着不同的代表意义。以前的全键盘的手机代码没有阅读过,所以也不是很了解。本人介绍的是在触摸屏的手机上的按键消息的处理流程。
在现在触摸屏成为主流的输入设备的情况下,很多厂商都在努力的做到取消物理按键的工作,但是目前就本人的学习情况来看,完全取消在目前看来还是不是那么现实。
有如下几点原因:
首先,本人说明的是目前原生的Android系统上。
其次,Android系统为了节省电量,在电源管理的过程中设置了休眠的方式。而休眠的时候触摸屏同样进入休眠状态。因此,不能够接收到用户的输入消息。
再次,目前的物理按键(主要指power,volume。home)是通过电源管理芯片进行控制的。触摸屏不是。
因此,如果没有现在的物理按键的情况下,如果想把设备从休眠的状态下唤醒基本上来讲是不可能的。
下面来正式的记录下本人在学习的过程中记录的点点滴滴。
首先,简要的介绍一下按键的处理流程。先简单的分为两大类:一类是虚拟按键。另一类是物理按键。
无论是虚拟按键还是物理按键都是要经过驱动层注册为输入设备,然后上报到kernel/drivers/input/input.c中。这里有相关函数的定义。然后通过、sys上报到frameworks/services/input/EventHub.cpp中,在这里会对设备进行扫描并且判断是哪种设备,然后在InputReader.cpp中对原始数据进行读取。在framewoks/services/input/InputDispatcher.cpp中实现数据的派发。在framework/base/core/jni/android_view_KeyEvent.cpp中实现通过JNI机制向上层的KeyEvent.java提供数据。并且在frameworks/base/core/java/android/view/KeyEvent.java中向上层的APP开发人员提供接口。
当然,虚拟键盘中有一个映射关系,键盘的按键值也会上报给上面的应用层,而对于物理按键往往是在frameworks层就被截取并且加以处理了。
普通的按键事件在Android系统中的调用流程(本人不太会处理visio绘图的保存问题)大致如下:
下图是人家goole的图 是比俺画的好啊……
但是对于物理按键的处理流程,目前主要查阅的代码的结果是在PhoneWindowManager.java中进行截获并处理的。
1.基本流程
1)内核处理按键,通过设备文件的方式提供给framework层
2)framework层的KeyInputQueue.java启动线程从设备文件中读出键码,然后把读出的键码按kl文件转成相应键值(JNI调用EventHub.cpp),最后写入事件队列
ps:读取键盘具体应该是eventHub类处理
3)framework层的WindowManagerService.java启动线程从事件队列中读出键值,然后根据当前focus分发给相应窗口
ps:刚才是 读 键码,现在是键值。
4)UI通过KeyCharacterMap.java处理kcm规则将用户基本按键与功能键(Shift, Alt等)组合,得出最终按键
2.两个配置文件
通常更换一种新的硬件,可能其键盘布局及键码与标准版本不同,不用更改代码,只要修改以下配置文件即可(如果增加新的未定义功能的按键,则需要修改代码)
1)xxx.kl
a)代码位置
sdk/emulator/keymaps/ kl结尾文件(2.2版本模拟器使用)。
b)功能
硬件全键盘的键码与键值的对应规则文件(如0x21对应A)
2)xxx.kcm
a)代码位置
sdk/emulator/keymaps/kcm结尾文件(2.2版本模拟器使用)
b)功能
硬件全键盘的键值对应表(如按下Alt, Shift时按键对应的键值)
PS:又提到kl..kcm前面来自驱动层,kcm这里有组合键,还有home..
3.整个流程相关代码
1)frameworks/base/core/java/android/view/KeyEvent.java(按键事件定义)
2)frameworks/base/services/java/com/android/server/KeyInputQueue.java(事件读取线程)
//PS:相当于getMessage,待定。
3)frameworks/base/services/java/com/android/server/WindowManagerService.java(事件分发线程)
//PS:相当于postMessage,sendMessage ,待定。
4)frameworks/base/core/java/android/view/KeyCharacterMap.java(功能键转换kcm)
5 ) frameworks / base / libs / ui / EventHub . cpp ( 键码与键值转换 )