安卓设备监听全部输入信号-Toy模板网

这篇具有很好参考价值的文章主要介绍了安卓设备监听全部输入信号。希望对大家有所帮助。如果存在错误或未考虑完全的地方，请大家不吝赐教，您也可以点击"举报违法"按钮提交疑问。

前言：

最近团队收到一个产品需求，需要监听安卓设备上用户是否有输入行为，以免定制推荐的时候打搅到用户。这里指的是设备上所有应用的输入行为，而不是单指某一个应用。

这个需求还是蛮有挑战性的，需要涉及到很多FW层的知识，所以围绕着这个需求，定制了多个方案，并且也找了许多人进行讨论，总算有了一个相对可行的方案，因此，通过本文记录一下，也分享给有同样需求的后来者。

这里先介绍一下大背景，我们是定制的设备，设备上有很多的APP，每个APP都是不同的团队来负责的。甚至于系统侧的代码和整体集成，也是不同的来团队负责的。

该需求高度依赖事件分发流程的原理，所以算是对事件分发流程的一个实践。

方案选择

方案1：APP集成SDK的方案

我们可以出一个SDK，让每个APP去集成。因为SDK是作用于APP中的，所以可以在SDK中，去注册相应的输入监听。

举个例子，事件分发流程中，Activity的事件分发都会走到Activity.onTouchEvent方法，方法如下：

public boolean onTouchEvent(MotionEvent event) {
    if (mWindow.shouldCloseOnTouch(this, event)) {
        finish();
        return true;
    }

    return false;
}

这里涉及到一个成员变量mWindow，而这个我们可以在监听到Activity启动后，通过hook的方式构建一个代理类hookWindow，替换调原有的mWindow，从而实现输入事件的监听。

这个方案技术来讲，实现难度比较低，可行性较高。但是从业务角度上，就需要上百个APP都接入这个SDK，就是近百个APP的接入成本，并且需要个十几个团队打交道去沟通，甚至有的团队还是外部的，所以这个方案从业务角度上，可行性是极低的，提出来后甚至没有和产品商量，直接被我们技术内部否决了。

方案2：改framework方案

事件分发流程中，大体流程如下图所示：

安卓设备监听全部输入信号,安卓,android,inputflinger,原力计划

如图所示，InputDispatcher收到了输入信号之后，负责找到对应的window，然后再把输入事件分发给对应的window。所以，如果我们能在InputDispatcher中做一个钩子，每当有信号过来的时候，通过这个钩子向外界分发，我们就可以知道用户是否有输入的行为了。

这样做的优势就是不需要任何APP的修改，对接团队的数量大幅的降低了，而且纯看代码，好像要写的代码也不是很多，只需要在dispatchMotionLocked方法被调用的时候，向外界发出一个通知就可以了。

但是经过考虑，还是放弃了这个方案，原因有以下几个：

1.需要对FW层进行修改，而且是主流程的代码，一旦写的有问题，造成的后果将不可想象，甚至会导致用户所有的输入事件全部失效。

2.涉及到了多个团队，因为我们不同的设备的系统是不同的团队来负责的。需要他们配合才能修改，又涉及到了外部沟通。一旦沟通，那么排期，上线就是变的遥不可及，甚至于人家处于第一个原因根本不愿意配合去做。

方案3：监听底层输入源

如下图所示，整个事件分发流程中，最底层的来源是EventHub。

安卓设备监听全部输入信号,安卓,android,inputflinger,原力计划

那么EventHub监听的是什么呢？既然EventHub可以监听，那么我们是否可以做一个同样的监听呢？

EventHub监听的其实是dev/input文件夹下的几个文件，比如event0，event1，event2这样，分别代表不同的输入来源。其实event0也不能称之为文件，他们其实属于驱动文件，并不能直接读的。

这样做的优势有如下几个：

1.不依赖外部团队。完全不依赖任何的外部团队，只要装了APP就可以生效。

2.安全性。因为不涉及到FW层修改，所以对系统的危险性大大降低。

3.可回退性。APP是可发版可热更新的，不像是FW层，一旦改坏了，就得重新刷ROM了。

所以总结了一下几个实现方案，3无疑是效果最好的，所以把实现方向，主要定位到第三个上。

可行性分析

如果我们直接通过adb命令获取event文件，发现是不可行的，说明这不是一个具体的文件。

adb pull dev/input/event0

如果我们通过FileObserver的方式添加监听，发现也是不可行的，会提示错误：

  I  type=1400 audit(0.0:2293): avc: denied { read } for name="event0" dev="tmpfs" ino=540 scontext=u:r:system_app:s0 tcontext=u:object_r:input_device:s0 tclass=chr_file permissive=1

所以，最简单的两个监听方案，很自然是走不通的。

接下来，我们通过ps看一下system_server进程，发现其只是一个system级别的应用，而我们也是一个system级别的应用，所以既然system_server可以读取event信号，那么我们理论上也是可以的。

安卓设备监听全部输入信号,安卓,android,inputflinger,原力计划

所以，我们就需要EventHub中的代码，来看看EventHub是怎么取值的，我们可以参考着其中的实现而实现我们的需求。

EventHub实现原理

我们首先看一下EventHub创建时的代码：

EventHub::EventHub(void){
    mEpollFd = epoll_create1(EPOLL_CLOEXEC);
    mINotifyFd = inotify_init1(IN_CLOEXEC);
    struct epoll_event eventItem = {};
    eventItem.events = EPOLLIN | EPOLLWAKEUP;
    eventItem.data.fd = mINotifyFd;
    int result = epoll_ctl(mEpollFd, EPOLL_CTL_ADD, mINotifyFd, &eventItem);
    ...
}

构造函数中，注册了一个mINotifyFd，然后通过epoll_ctl绑定添加事件，也就是说如果mINotifyFd如果新的添加事件时，会通过mEpollFd向其注册者发送信号，并且携带eventItem对象。

那么就会有两个问题：

1.mINotifyFd绑定的是哪个文件？

2.epoll被唤醒后，通知的是谁？

第一个问题，答案在addDeviceInputInotify方法中，这个方法中，绑定了DEVICE_INPUT_PATH目录，也就是说，DEVICE_INPUT_PATH目录中，如果有文件添加或者删除，则会发出通知。

而这里的DEVICE_INPUT_PATH="/dev/input"。

void EventHub::addDeviceInputInotify() {
    mDeviceInputWd = inotify_add_watch(mINotifyFd, DEVICE_INPUT_PATH, IN_DELETE | IN_CREATE);
}

第二个问题，答案在getEvents方法中

size_t EventHub::getEvents(int timeoutMillis, RawEvent* buffer, size_t bufferSize) {
    ...
    int pollResult = epoll_wait(mEpollFd, mPendingEventItems, EPOLL_MAX_EVENTS, timeoutMillis);
    ...
}

epoll_wait被唤醒后，传递过来的epoll_event对象将会被添加到mPendingEventItems集合中。接下来，我们就可以遍历mPendingEventItems集合进行依次处理了。

搜寻资料，得知inotify是用来监视文件系统事件的机制，当有事件发生时，inotify文件描述符会可读。我猜测这也就是为什么之前我们直接监听文件失败的原因（很遗憾，猜错了）。

安卓设备监听全部输入信号,安卓,android,inputflinger,原力计划

实施方案

所以，参考EventHub中的实现，我们就可以完成我们的需求了。

我们可以也注册一个inotify，然后通过inotify_add_watch添加观察文件目录，也观察"/dev/input"文件夹。然后通过epoll_ctl绑定监听，当有事件输入时进行唤醒，唤醒后读取mINotifyFd描述符中的文件内容。

其实，因为我们的需求只是观察用户是否有输入行为，而不是观察用户输入了什么，所以我们深知都不需要解析mINotifyFd描述符中的内容，只需要发生了，就认为有输入。

分为两个方法，方法createListenerInput主要用于创建native层对象，并且初始化相关的成员变量，以及开启监听。

方法readLastInputTime则负责读取native对象中的最近输入时间这个属性值。

createListenerInput方法相关的实现代码如下：

void ListenerInput::registerWatchInputTime() {
    LOGI("%s%d", "registerWatchInputTime,mINotifyFd:", mINotifyFd);
    int mDeviceInputWd = inotify_add_watch(mINotifyFd, DEVICE_INPUT_PATH, IN_DELETE | IN_CREATE);
    LOGI("%s%d", "registerWatchInputTime,mDeviceInputWd:", mDeviceInputWd);

    struct epoll_event eventItem = {};
    eventItem.events = EPOLLIN | EPOLLWAKEUP;
    eventItem.data.fd = mINotifyFd;
    int result = epoll_ctl(mEpollFd, EPOLL_CTL_ADD, mINotifyFd, &eventItem);
    LOGI("%s%d", "epoll_ctl.result:", result);
    startThread();
}

void ListenerInput::listenerInput() {
    for (;;) {
        int pollResult = epoll_wait(mEpollFd, mPendingEventItems, 16, 10000L);
        LOGI("%s%d", "epoll_wait.pollResult:", pollResult);
        if (pollResult == 0) {
            // Timed out.
            break;
        }
    }
}

void ListenerInput::startThread() {
    std::thread myThread(&ListenerInput::listenerInput, this);
    myThread.detach();
}

JNIEXPORT jlong JNICALL
Java_com_beantechs_watchinput_WatchInput_createListenerInput(JNIEnv *env, jobject instance) {
    LOGI("%s", "Java_com_beantechs_watchinput_WatchInput_createListenerInput start");
    ListenerInput *listenerInput = new ListenerInput();
    listenerInput->registerWatchInputTime();
    LOGI("%s", "Java_com_beantechs_watchinput_WatchInput_createListenerInput end");
    return reinterpret_cast<long>(listenerInput);
}

readLastInputTime方法相关的实现代码如下：

long ListenerInput::readLastInputTime() {
    LOGI("%s%ld", "readLastInputTime",mLastInputTime);
    return mLastInputTime;
}

JNIEXPORT jlong JNICALL
Java_com_beantechs_watchinput_WatchInput_readLastInputTime(JNIEnv *env, jobject instance,
                                                           jlong ptr) {
    LOGI("%s", "Java_com_beantechs_watchinput_WatchInput_readLastInputTime start");
    LOGI("%s%lld", "ptr:", ptr);
    long nativeLongValue = static_cast<long>(ptr);
    ListenerInput *listenerInput = reinterpret_cast<ListenerInput *>(nativeLongValue);
    long inputTime = listenerInput->readLastInputTime();
    LOGI("%s%ld", "Java_com_beantechs_watchinput_WatchInput_readLastInputTime end,inputTime:",
         inputTime);
    return 1l;
}

但是实际运行的时候，发现又被权限管理给限制掉了，提示错误：

type=1400 audit(0.0:7273): avc: denied { read } for name="input" dev="tmpfs" ino=10275 scontext=u:r:system_app:s0 tcontext=u:object_r:input_device:s0 tclass=dir permissive=1

哪怕关掉了SElinux，仍然提示同样的错误。

inputflinger归属system_server进程，而system_server进程属于system级别的应用。而我的应用也是system级别的，所以为什么system_server可以，我的应用不行，这块的原因还未找到，还处于排查中。