Android 中处理POWER/HOME流程

转载请注明出处： http://blog.csdn.net/peng_cao

目录(?)[+]

Android按键消息处理

在Android系统中，键盘按键事件是由SystemServer服务来管理的；然后在以消息的形式分发给应用程序处理。产生键盘按键事件则是有Linux kernel的相关驱动来实现。
键盘消息有别于其他类型的消息；需要从Linux kernel drivers产生由上层app来处理。同时按键有着不同的映射值，因此从模块独立性角度各个独立的模块应该拥有不同的键盘映射。这样以来，kernel产生的按键事件必然回经过不同的映射才到app。

1、kernel中同按键相关代码

Android 使用标准的 linux 输入事件设备(/dev/input/)和驱动按键定义在 linux 内核include/linux/input.h 中,按键的定义形式如下（仅以BACK HOME MENU POWER为例）:

有了按键的定义，就需要产生相应的按键事件了。在kernel/arch/arm/mach-msm/xxx/xxx/xxx.c会对BACK HOME和MENU进行注册。这里使用在屏幕上的坐标来对按键进行区分。这部分代码会在系统启动的时候，将相应的数据存储，以供framework查询。
(这里以xxx代替，是因为针对不同的硬件，需要的Linux kernel不同)

当然从核心板原理图到kernel是属于驱动范畴，不讨论。

2、framework针对键盘事件的处理

上层对输入事件的侦听和分发是在InputManagerService 中实现,首先来看看InputManagerService的创建，

Step1 启动服务

SystemServer.Java

class ServerThread extends Thread {
    //省略。。
    public void run() {
        // Create a handler thread just for the window manager to enjoy.
        HandlerThread wmHandlerThread = new HandlerThread("WindowManager");
        wmHandlerThread.start();
        Handler wmHandler = new Handler(wmHandlerThread.getLooper());
        //此处省略5k字。。
        Slog.i(TAG, "Input Manager");
        inputManager = new InputManagerService(context, wmHandler);
    }
}
 
 
1
2
3
4
5
6
7
8
9
10
11
12
 
 
1
2
3
4
5
6
7
8
9
10
11
12

可以看到，在系统启动的时候，会首先创建一个系统级别的Handler线程wmHandlerThread用于处理键盘消息(仅说明键盘消息)。然后在创建输入管理服务 inputManager，InputManagerService 的第二个参数就是用于处理按键消息的Handler。

Step2 InputManagerService创建

在往下走到 InputManagerService.java的构造函数。

public InputManagerService(Context context, Handler handler) {
    this.mContext = context;
    this.mHandler = new InputManagerHandler(handler.getLooper());
    mUseDevInputEventForAudioJack =
context.getResources().getBoolean(R.bool.config_useDevInputEventForAudioJack);
    Slog.i(TAG, "Initializing input manager, mUseDevInputEventForAudioJack="
                    + mUseDevInputEventForAudioJack);
    mPtr = nativeInit(this, mContext, mHandler.getLooper().getQueue());
}
 
 
1
2
3
4
5
6
7
8
9
 
 
1
2
3
4
5
6
7
8
9

这里做了重要的两件事情

• 第一：将SystemServer级别的Handler赋值给 InputManagerService自己的消息处理Handler；
• 第二：调用nativeInit继续进行初始化。

Step3 com_android_server_InputManagerService.cpp

static jint nativeInit(JNIEnv* env, jclass clazz,
    jobject serviceObj, jobject contextObj, jobject messageQueueObj) {
    sp<MessageQueue> messageQueue = android_os_MessageQueue_getMessageQueue(env, messageQueueObj);
    NativeInputManager* im = new NativeInputManager(contextObj, serviceObj,
    messageQueue->getLooper());
    im->incStrong(serviceObj);
    return reinterpret_cast<jint>(im);
}
 
 
1
2
3
4
5
6
7
8
 
 
1
2
3
4
5
6
7
8

这里nativeInit直接调用了 NativeInputManager的构造函数

Step4 NativeInputManager

NativeInputManager::NativeInputManager(jobject contextObj,
    jobject serviceObj, const sp<Looper>& looper) :
    mLooper(looper) {
    JNIEnv* env = jniEnv();

    mContextObj = env->NewGlobalRef(contextObj);
    mServiceObj = env->NewGlobalRef(serviceObj);

    {
        AutoMutex _l(mLock);
        mLocked.systemUiVisibility = ASYSTEM_UI_VISIBILITY_STATUS_BAR_VISIBLE;
        mLocked.pointerSpeed = 0;
        mLocked.pointerGesturesEnabled = true;
        mLocked.showTouches = false;
    }
    sp<EventHub> eventHub = new EventHub();
    mInputManager = new InputManager(eventHub, this, this);
}
 
 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
 
 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

这里需要特别注意最后两行代码。第一：创建了 EventHub；第二：创建 InputManager并将 EventHub作为参数传入InputManager。

Step5 InputManager构造函数

InputManager::InputManager(
    const sp<EventHubInterface>& eventHub,
    const sp<InputReaderPolicyInterface>& readerPolicy,
    const sp<InputDispatcherPolicyInterface>& dispatcherPolicy) {
        mDispatcher = new InputDispatcher(dispatcherPolicy);
        mReader = new InputReader(eventHub, readerPolicy, mDispatcher);
        initialize();
}

void InputManager::initialize() {
    mReaderThread = new InputReaderThread(mReader);
    mDispatcherThread = new InputDispatcherThread(mDispatcher);
}
 
 
1
2
3
4
5
6
7
8
9
10
11
12
13
 
 
1
2
3
4
5
6
7
8
9
10
11
12
13

创建了InputDispatcher 和InputReader,并调用了initialize函数创建了InputReaderThread和InputDispatcherThread。InputDispatcher类是负责把键盘消息分发给当前激活的Activity窗口的，而InputReader类则是通过 EventHub类来实现读取键盘事件的，InputReader实列mReader就是通过这里的 InputReaderThread线程实列mReaderThread来读取键盘事件的，而InputDispatcher实例mDispatcher 则是通过这里的InputDispatcherThread线程实例mDisptacherThread来分发键盘消息的。
到这里，相关的组件都已经被创建了；

Step6 将服务运行起来

接下来看看他们是如何运行起来的。
在systemServer.java中创建inputManager之后。将InputManagerServer进行注册，并运行start()

ServiceManager.addService(Context.INPUT_SERVICE, inputManager);
    inputManager.start();
    //InputManager的start函数：
    public void start() {
    Slog.i(TAG, "Starting input manager");
    nativeStart(mPtr);
    //省略。。
}
 
 
1
2
3
4
5
6
7
8
 
 
1
2
3
4
5
6
7
8

调用nativeStart继续往下走。顺带说一下，这里的参数mPtr是指向nativeinputmanager service对象的，在InputManagerService构造函数中由nativeInit赋值。

Step7 InputManagerService.cpp–>batuveStart

接下来又到了com_android_server_InputManagerService.cpp中。

static void nativeStart(JNIEnv* env, jclass clazz, jint ptr) {
    NativeInputManager* im = reinterpret_cast<NativeInputManager*>(ptr);

    status_t result = im->getInputManager()->start();
    if (result) {
        jniThrowRuntimeException(env, "Input manager could not be started.");
    }
}
 
 
1
2
3
4
5
6
7
8
 
 
1
2
3
4
5
6
7
8

这里的im就是inputManager并且用到了上面传下来的mPtr来重新构建。

Step8 InputManager.cpp start

继续往下则会调用到InputManager.cpp 的start函数

status_t InputManager::start() {
    status_t result = mDispatcherThread->run("InputDispatcher", PRIORITY_URGENT_DISPLAY);
    if (result) {
    ALOGE("Could not start InputDispatcher thread due to error %d.", result);
    return result;
    }

    result = mReaderThread->run("InputReader", PRIORITY_URGENT_DISPLAY);
    if (result) {
        ALOGE("Could not start InputReader thread due to error %d.", result);
        mDispatcherThread->requestExit();
        return result;
    }

    return OK;
}
 
 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
 
 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

这个函数主要就是分别启动一个InputDispatcherThread线程和一个InputReaderThread线程来读取和分发键 盘消息的了。这里的InputDispatcherThread线程对象mDispatcherThread和InputReaderThread线程对 象是在前面的Step9中创建的，调用了它们的run函数后，就会进入到它们的threadLoop函数中去，只要threadLoop函数返回true，函数 threadLoop就会一直被循环调用，于是这两个线程就起到了不断地读取和分发键盘消息的作用。

Step9 InputReader::loopOnce()

在下来继续看loopOnce()这个函数。

void InputReader::loopOnce() {
    //......
    size_t count = mEventHub->getEvents(timeoutMillis, mEventBuffer, EVENT_BUFFER_SIZE);
    //......
    if (count) {
        processEventsLocked(mEventBuffer, count);
    }
    //......
    // Flush queued events out to the listener.
    // This must happen outside of the lock because the listener could potentially call
    // back into the InputReader's methods, such as getScanCodeState, or become blocked
    // on another thread similarly waiting to acquire the InputReader lock thereby
    // resulting in a deadlock. This situation is actually quite plausible because the
    // listener is actually the input dispatcher, which calls into the window manager,
    // which occasionally calls into the input reader.
    mQueuedListener->flush();
}
 
 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
 
 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

这里面需要注意像神一样的函数 mEventHub->getEvents()。其实现原理，还有点不是很清楚；但是其功能就是负责键盘消息的读取工作，如果当前有键盘事件发生或者有键盘事件等待处理，通过mEventHub的 getEvent函数就可以得到这个事件，然后交给processEventsLocked 函数进行处理。同样需要特别注意最后一行；后面回解释。我们还会回来的～～～

/*
     * Wait for events to become available and returns them.
     * After returning, the EventHub holds onto a wake lock until the next call to getEvent.
     * This ensures that the device will not go to sleep while the event is being processed.
     * If the device needs to remain awake longer than that, then the caller is responsible
     * for taking care of it (say, by poking the power manager user activity timer).
     *
     * The timeout is advisory only. If the device is asleep, it will not wake just to
     * service the timeout.
     *
     * Returns the number of events obtained, or 0 if the timeout expired.
     */
    virtual size_t getEvents(int timeoutMillis, RawEvent* buffer, size_t bufferSize)
 
 
1
2
3
4
5
6
7
8
9
10
11
12
13
 
 
1
2
3
4
5
6
7
8
9
10
11
12
13

函数原型！
在成功获取input Event之后，就会用到 processEventsLocked函数来处理Event
然后在调用到 processEventsForDeviceLocked(deviceId,rawEvent, batchSize);
最后在void InputDevice::process(constRawEvent* rawEvents, size_t count)
我就在想：问什么不直接到process函数呢？其实我觉得这里体现了设计模式中的单一职责原则；这种设计可以有效的控制函数粒度(有个类粒度，这里自创函数粒度)的大小，函数承担的职责越多其复用的可能性就越小，并且当期中某一个职责发生变化，可能会影响其他职责的运作！

Step 10 InputDevice::process

接下来继续看InputDevice::process函数

void InputDevice::process(const RawEvent* rawEvents, size_t count) {
    //。。。。
    InputMapper* mapper = mMappers[i];
    mapper->process(rawEvent); 
}
 
 
1
2
3
4
5
 
 
1
2
3
4
5

走到这里才算是真真正正的知道了有按键发生了，调用 KeyboardInputMapper::process(const RawEvent*)处理input event； KeyboardInputMapper 继承自 InputMapper。那为什么调用的是 KeyboardInputMapper而不是SwitchInputMapper等等。。
请留意

InputDevice* InputReader::createDeviceLocked(int32_t deviceId,
                                                const InputDeviceIdentifier& identifier, uint32_t classes)
 
 
1
2
 
 
1
2

函数中的片段：

if (keyboardSource != 0) {device->addMapper(new KeyboardInputMapper(device, keyboardSource, keyboardType));}
 
 
1
 
 
1

这里Event Type有必要提一下，以下是一些常用的Event。在kernel/Documentation/input/event-codes.txt中有详细的描述。

• EV_SYN:
  
  • Used as markers to separate events. Eventsmay be separated in time or in space, such as with the multitouch protocol.
• EV_KEY:
  
  • Used to describe state changes ofkeyboards, buttons, or other key-like devices.
• EV_REL:
  
  • Used to describe relative axis value changes,e.g. moving the mouse 5 units to the left.
• EV_ABS:
  
  • Used to describe absolute axis valuechanges, e.g. describing the coordinates of a touch on a touchscreen.
• EV_MSC:
  
  • Used to describe miscellaneous input datathat do not fit into other types.
• EV_SW:
• Used to describe binary stateinput switches.

Step 11 KeyboardInputMapper::process

void KeyboardInputMapper::process(const RawEvent* rawEvent) {
    switch (rawEvent->type) {
    case EV_KEY: {
        int32_t scanCode = rawEvent->code;
        int32_t usageCode = mCurrentHidUsage;
        mCurrentHidUsage = 0;

        if (isKeyboardOrGamepadKey(scanCode)) {
            int32_t keyCode;
            uint32_t flags;
            if (getEventHub()->mapKey(getDeviceId(), scanCode, usageCode, &keyCode, &flags)) {
                keyCode = AKEYCODE_UNKNOWN;
                flags = 0;
            }
            processKey(rawEvent->when, rawEvent->value != 0, keyCode, scanCode, flags);
        }
        break;
    }
    }
}
 
 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
 
 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

在这里，先判断isKeyboardOrGamepadKey(scanCode)，然后在用getEventHub()->mapKey()检测 提供的key是否正确，在然后就开始处理了processKey

Step 12 KeyboardInputMapper::processKe

void KeyboardInputMapper::processKey(nsecs_t when, bool down, int32_t keyCode,
        int32_t scanCode, uint32_t policyFlags) {
    //忽略到所有的。。只看最后两行。。
    NotifyKeyArgs args(when, getDeviceId(), mSource, policyFlags,
        down ? AKEY_EVENT_ACTION_DOWN : AKEY_EVENT_ACTION_UP,
         AKEY_EVENT_FLAG_FROM_SYSTEM, keyCode, scanCode, newMetaState, downTime);

     getListener()->notifyKey(&args);
}
 
 
1
2
3
4
5
6
7
8
9
 
 
1
2
3
4
5
6
7
8
9

不用多解释了，直接notifyKey了。。但需要注意，这里的notifyKey 仅仅是 NotifyKeyArgs push到消息队列中去；并没有通知上层！那到底在那儿通知的呢？

还记不记得在void InputReader::loopOnce()这个函数的最后一行代码，其实质是在这个函数中通知上层有按键事件发生。

这个flush()很明显，notify了之后，就delete，不存在了。问什么不是在getListener()->notifyKey(&args);的时候就真正的notify？我觉得可以做如下角度予以考虑：

• 第一：线程是最小的执行单位；因此每当inputThread.start()的时候，如果不flush，回造成数据混乱。
• 第二：flush操作是必须的，同时在loopOnce的最后操作也是最恰当的。其实这里的Listener也就是充当了一个事件分发者的角色。

这说明，到这里已经完全识别了按键了，并按照自己的键盘映射映射了一个值保存在args中，notifyKey给上层应用了。。

Step 13 consumeRawTouche

其实针对BACK HOME MENU这三个按键来说，其实质就是TouchScreen；因此在inputReader.cpp中获取Touch映射是在函数boolTouchInputMapper::consumeRawTouche**s(nsecs_t when, uint32_t policyFlags) 中。这里同上面的**Step 12相同。

首先检测不是多点Touch。然后使用const TouchInputMapper::VirtualKey*TouchInputMapper::findVirtualKeyHit( int32_t x, int32_t y)依据坐标值查找出Touch的映射值。
到最后了啊。。。
呵呵，看看是怎么实现的。。

Android中针对按键处理的流程图

这里使用针对power按键为例进行说明

Power短按

power长按

reboot and shutdown