前言：
最近团队收到一个产品需求，需要监听安卓设备上用户是否有输入行为，以免定制推荐的时候打搅到用户。这里指的是设备上所有应用的输入行为，而不是单指某一个应用。
这个需求还是蛮有挑战性的，需要涉及到很多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方案
事件分发流程中，大体流程如下图所示：
如图所示，InputDispatcher收到了输入信号之后，负责找到对应的window，然后再把输入事件分发给对应的window。所以，如果我们能在InputDispatcher中做一个钩子，每当有信号过来的时候，通过这个钩子向外界分发，我们就可以知道用户是否有输入的行为了。
这样做的优势就是不需要任何APP的修改，对接团队的数量大幅的降低了，而且纯看代码，好像要写的代码也不是很多，只需要在dispatchMotionLocked方法被调用的时候，向外界发出一个通知就可以了。
但是经过考虑，还是放弃了这个方案，原因有以下几个：
需要对FW层进行修改，而且是主流程的代码，一旦写的有问题，造成的后果将不可想象，甚至会导致用户所有的输入事件全部失效。
涉及到了多个团队，因为我们不同的设备的系统是不同的团队来负责的。需要他们配合才能修改，又涉及到了外部沟通。一旦沟通，那么排期，上线就是变的遥不可及，甚至于人家处于第一个原因根本不愿意配合去做。
方案3：监听底层输入源
如下图所示，整个事件分发流程中，最底层的来源是EventHub。
那么EventHub监听的是什么呢？既然EventHub可以监听，那么我们是否可以做一个同样的监听呢？
EventHub监听的其实是dev/input文件夹下的几个文件，比如event0，event1，event2这样，分别代表不同的输入来源。其实event0也不能称之为文件，他们其实属于驱动文件，并不能直接读的。
这样做的优势有如下几个：
不依赖外部团队。完全不依赖任何的外部团队，只要装了APP就可以生效。
安全性。因为不涉及到FW层修改，所以对系统的危险性大大降低。
可回退性。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信号，那么我们理论上也是可以的。
所以，我们就需要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对象。
那么就会有两个问题：
mINotifyFd绑定的是哪个文件？
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文件描述符会可读。我猜测这也就是为什么之前我们直接监听文件失败的原因（很遗憾，猜错了）。
实施方案
所以，参考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 JNICALLJava_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(listenerInput);} readLastInputTime方法相关的实现代码如下：
long ListenerInput::readLastInputTime() { LOGI("%s%ld", "readLastInputTime",mLastInputTime); return mLastInputTime;}JNIEXPORT jlong JNICALLJava_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(ptr); ListenerInput *listenerInput = reinterpret_cast(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可以，我的应用不行，这块的原因还未找到，还处于排查中。
声明
本技术方案仅供参考，严禁用于任何非法目的商业活动。
本方案只是一个方向性的探索，并没有真正的去实现，最终是否能够实现也是一个未知数。这篇文章只是做一个初步的分享，当然欢迎有类似方向或者需求的人一起讨论或者给予指引。
来源地址：https://blog.csdn.net/AA5279AA/article/details/131770972
