安卓设备监听全部输入信号

  • Post author:
  • Post category:其他


前言:

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

这个需求还是蛮有挑战性的,需要涉及到很多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方法被调用的时候,向外界发出一个通知就可以了。

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

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

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

方案3:监听底层输入源

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

那么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信号,那么我们理论上也是可以的。

所以,我们就需要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文件描述符会可读。我猜测这也就是为什么之前我们直接监听文件失败的原因(很遗憾,猜错了)。


实施方案

所以,参考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可以,我的应用不行,这块的原因还未找到,还处于排查中。

声明

本技术方案仅供参考,严禁用于任何非法目的商业活动。

本方案只是一个方向性的探索,并没有真正的去实现,最终是否能够实现也是一个未知数。这篇文章只是做一个初步的分享,当然欢迎有类似方向或者需求的人一起讨论或者给予指引。



版权声明:本文为AA5279AA原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接和本声明。