最近在做系统定制时接到一个挺有意思的需求：要在系统运行过程中，随时把整块触摸屏“冻结”掉，既不能响应点击，也不能触发手势，但屏幕显示还得是亮的，系统其他功能也必须正常。说白了，就是做一个全局触摸开关——需要的时候一刀切掉所有触摸事件，不需要的时候再瞬间恢复。
一开始想着这不是很简单的活儿吗，直接上个黑屏或者搞个window遮挡不就完了。结果真做起来才发现，单靠上层方案根本做不到干净利落，信号键、状态栏、手势导航这些杂七杂八的路径都会漏掉事件。最后只能老老实实下到源码层，在InputReader里动手脚。这篇文章我就把不同AOSP版本下动态实现“冻结触摸”的完整思路、差异对比和踩坑记录做个总结，给同样被这个需求折磨的同学一个参考。
1. 全局输入开关的落点选型
1.1 为什么不是Window层拦截
很多人的第一反应都是用一个全屏Window罩在屏幕上，拦截所有触摸事件。这个思路在应用层确实能挡住绝大多数点按，但实际用起来问题非常明显。
首先是系统级窗口的优先级问题。状态栏、下拉通知栏、系统UI弹窗这些窗口的层级高于普通应用Window，如果触摸冻结功能要盖住它们，必须用TYPE_SYSTEM_ERROR这种级别的窗口，否则事件还是会从状态栏区域漏进去。其次，Android的触摸事件分发是异步的，拦截层的Window接管事件后，底层硬件的输入管道依然在跑，碰到一些边缘手势场景，比如从底部上滑回桌面，系统手势的响应线程照样能处理掉。再者，Window拦截方案对“冻结”的响应是滞后的，因为WindowManager要经过一轮跨进程的窗口排序、焦点切换，才能让新窗口真正生效，这中间少说有几十毫秒的时间差，对于老化测试这种高频操作场景来说，这点延迟完全不能接受。
同类的上层方案还有用InputManagerService的setInputFilter注入事件过滤器，在Java层把MotionEvent全吞掉。这个方案比Window层稍微好一点，毕竟过滤节点在InputDispatcher之后、窗口之前，覆盖面广了一些，但由于它仍然是在事件已经过InputReader、InputDispatcher之后才处理的，冻结状态切换的瞬间，输入管道里可能还在飞着几十个pending事件，恢复触摸的那一下，这些残留事件会一次性喷出来，形成非常诡异的“鬼手”现象。
1.2 输入链路的关键路径
要找到合适的落点，先得理清Android输入系统的主链路。触摸从硬件到应用层，大概要经过这么几个阶段：内核驱动产生原始中断 -> EventHub从/dev/input/节点读标准输入事件 -> InputReader把原始事件解析成RawEvent并分发给各个InputMapper进行语义转换 -> 转换成MotionEvent后经过QueuedInputListener送入InputDispatcher-> InputDispatcher根据窗口焦点和触摸命中规则，把事件派发给具体进程 -> Java层的InputManagerService再把事件包装成InputEvent交给ViewHierarchy处理。
这条链路上，EventHub是纯硬件接口，不适合做逻辑判断，InputDispatcher侧更贴近窗口管理，改起来风险大，而InputReader恰好是“原始数据已解析、语义事件刚生成”的中间节点。在这个节点做全局触摸开关，意味着所有要发给上层的事件都统一从源头被过滤掉，不残留、不偏心。最值得一提的一点是，InputReader跑在InputManagerService所在的binder线程里，冻结逻辑加在这里不会引入额外的跨进程通信延迟，而且它对系统UI和应用窗口一视同仁，不存在哪类窗口漏网的问题。
选InputReader层还有一层工程考虑：不管AOSP后续怎么改窗口策略、怎么重构InputDispatcher，触摸事件的第一站永远是InputReader。全局开关放这里，兼容性最好，跟系统版本迭代解耦。
2. 核心机制：InputReader如何产生触摸事件
2.1 EventHub到InputMapper的处理流水线
多数系统的输入交互都依赖一个常驻的InputReaderThread，它会循环调用EventHub::getEvents，从内核的输入节点把原始事件批量捞出来，封装成RawEvent结构体。在这之后，核心处理逻辑进入InputReader::processEventsLocked，当触摸设备上报了一个RawEvent类型为EV_ABS或EV_KEY（BTN_TOUCH）的事件时，InputReader会根据设备ID找到对应的TouchInputMapper，由它完成从RawEvent到内部坐标、压力、手势状态的解析。
这里有个关键的流程分支：TouchInputMapper::processRawEvent会先更新设备的按键状态和坐标值，然后调用sync系列函数，把累积的原始坐标数据转换为一个完整的MotionEvent。转换完成的MotionEvent并不是直接放进分发队列，而是先通过QueuedInputListener暂存在InputReader的mQueuedListener成员里，等整批事件处理完，才会统一投递给InputDispatcher。
正是这个“整批收集、统一投递”的机制，给了我们在InputReader内部插入全局开关的最优介入点：只要在TouchInputMapper完成解析但还没把事件压入mQueuedListener的中间位置，判断一次开关状态，就能做到既不影响底层设备事件读取，又能把所有触摸事件干净地挡在分发链路之外。
// frameworks/native/services/inputflinger/reader/TouchInputMapper.cpp void TouchInputMapper::processRawEvent(const RawEvent& rawEvent) { // 解析坐标、按键、压力等 ... // 判断全局开关：如果冻结中，直接丢弃触摸事件 if (mInputReaderPolicy->isGlobalTouchFrozen() && (rawEvent.type == EV_ABS || rawEvent.type == EV_KEY)) { return; } sync(rawEvent); }这段代码思路很简单，但放在什么位置很有讲究。放在processRawEvent里意味着这个设备的所有原始触摸数据都会被忽略，包括BTN_TOUCH的按下和抬起，系统层面的触摸状态机不会切换，连“当前是否有手指接触屏幕”这个信息都不再更新。这样做的最大好处是，恢复冻结之后，不会凭空冒出一个奇怪的触摸状态变更事件。
2.2 冻结的本质是丢弃而非屏蔽
触摸“冻结”听起来像是给设备发一个禁止指令，让硬件层停止上报数据。但实际上，Android的硬件输入设备大多不支持运行中动态启停，即使通过ioctl去操作设备节点，也只能影响特定的驱动实现，没法统一适配所有触摸IC。更重要的是，直接屏蔽硬件上报会导致设备状态和驱动状态脱离，恢复后可能出现需要重新校准或者产生无效触摸点的问题。
从InputReader层做全局开关，本质上是在事件源头做选择性丢弃。上游内核和EventHub照常工作，硬件设备上报的坐标流也不中断，只是这些数据在转换成触摸语义事件之后、进入系统分发链路之前，被一个布尔开关拦下来了。这样实现的是“软冻结”，对硬件和驱动零侵入，随时切换、随时恢复，干净利落。
我们实际用下来，这种做法最舒服的地方在于：Android的触摸事件是带完整Down-Move-Up状态序列的，如果在应用层吞事件，很容易把一个序列掐半截，导致手势状态机紊乱；但在InputReader的processRawEvent位置直接丢弃，后面的状态机根本不知道序列的存在，自然也就不存在半截序列问题。
2.3 保留按键、冻结触摸的精细控制
做全局开关的时候，绝大多数场景并不是六亲不认地把触摸全干掉。比如老化测试、防止书包误触这类场景，通常都希望物理按键（电源键、音量键）还能正常工作，不然屏幕冻结之后系统连唤醒、重启都做不了。
这就需要在开关过滤逻辑里区分事件类型。触摸事件走的是EV_ABS和EV_KEY（BTN_TOUCH/BTN_TRIGGER），而物理按键走的是EV_KEY（KEYCODE_POWER等）。在InputReader的处理循环中，可以根据事件类型和对应的按键码做精细过滤。
// 伪代码示意 bool InputReader::isInputEventAllowedLocked(const RawEvent& rawEvent) { if (!mGlobalTouchFrozen) { return true; } // 触摸类事件全部丢弃 if (rawEvent.type == EV_ABS) { return false; } // 部分按键事件：保留电源键、音量键，屏蔽触摸屏上映射的按键 if (rawEvent.type == EV_KEY) { int keyCode = getKeyCode(rawEvent); if (keyCode == AKEYCODE_POWER || keyCode == AKEYCODE_VOLUME_UP || keyCode == AKEYCODE_VOLUME_DOWN) { return true; } return false; } return true; }这里有容易被忽略的细节：很多触摸屏在多点触控模式下会通过TYPE_B协议上报SLOT信息，EV_ABS里的ABS_MT_SLOT、ABS_MT_TRACKING_ID都是触摸专用。有些触摸固件还会把触摸板上的物理按键映射成BTN_LEFT、BTN_RIGHT这类EV_KEY事件，单独按EV_ABS过滤的话，这些触摸板按键会漏过去。所以实际实现时，判断逻辑不仅要看事件类型，还得结合当前正在处理的事件所属设备类型，做组合过滤。
3. 不同AOSP版本的差异与兼容做法
3.1 Android 8到9：文件位置与代码结构
在Android 8到9的年代，InputReader相关的代码集中在frameworks/native/services/inputflinger/下，包括InputReader.cpp和InputDispatcher.cpp。那时候的InputReader结构还算简单，TouchInputMapper和MultiTouchInputMapper都待在同一个目录里，类方法没有像后来那样拆成独立的.h/.cpp文件。
早期版本添加一个全局开关比较直接：在InputReader.h里加一个mGlobalTouchFrozen成员变量，再在InputReader::processEventsLocked循环体里统一拦截底层传来的RawEvent。不过我要提醒的是，Android 8的设备支持了InputManagerService的setInputFilter，但它走的是Java层过滤器，跟我们在Native层做的开关是两条路径，千万别混为一谈。
如果是从Android 8往后续版本移植patch，最直观的变化是类文件被拆得越来越细，原来全写在InputReader.cpp里的方法，现在散落在reader/和dispatcher/两个子目录，函数签名也加了Locked后缀或者改传引用参数。早期很多全局开关的patch在Android 10上编译失败，基本都是因为拿旧代码路径硬套新目录结构导致的。
3.2 Android 10到12：线程模型与回调机制调整
Android 10开始，InputReader和InputDispatcher的线程模型做了比较大的调整，InputDispatcher不再单独持有所有窗口状态的同步锁，而是引入InputDispatcherPolicy那种策略接口机制，Reader和Dispatcher之间的交互也变得更加解耦。在这个阶段做全局开关，比较好的做法是把开关状态放到一个公共的策略类里，让InputReader和InputDispatcher都能读取，而不是只简单地在Reader线程里搞一个局部变量。
Android 11到12之间，触摸相关的改动相当密集，比较有代表性的是触摸点“取消”语义的加强。如果冻结发生在触摸事件序列的中间（比如用户正按着屏幕时触发冻结），旧版本直接丢弃后续事件可能会导致上层收到一个没有结束序列的DOWN事件，造成手势被永久挂起。从Android 11开始，InputReader中增加了序列完整性检查相关逻辑，丢弃事件时如果发现当前同步批次内存在未结束的触摸序列，需要主动伪造一个ACTION_CANCEL事件投递出去，让应用层把手势栈清理干净。这个细节在Android 8到9上没那么严格，但在10以上版本如果忽略掉，极容易引发Input ANR。
3.3 Android 13及后续版本的适配要点
Android 13的Input系统又发生了一些结构性变化，最直观的是InputManagerService的Native部分和InputReader的代码做了进一步重构，像QueuedInputListener、InputMapper的缓冲区管理方式都和早期不同了。如果要做多版本兼容，建议不要把patch粘死在具体的函数内部，而是抽出一个独立的策略模块，通过接口向InputReader暴露isGlobalTouchFrozen()方法。
此外，Android 12L开始引入了Touchpad相关的手势映射，Android 13对外接鼠标、触摸板的支持也调整了。全局开关如果只是针对“触摸屏”来的，一定注意过滤条件里要加上设备类型判断，否则容易连鼠标和外接输入设备也一起冻结掉，这对某些需要保留USB鼠标操作系统的场景是不可接受的。
// 伪代码：根据设备类型区分过滤范围 bool shouldFilterDevice(const InputDeviceNode& node) { // 外接触摸板/鼠标：不过滤 if (node.hasMouseCapability()) return false; // 内置触摸屏/触摸板：过滤 if (node.hasTouchscreenCapability()) return true; // 其他设备类型按默认策略 return mDefaultFilterPolicy; }还有一个不同的点在于，Android 13的纯净AOSP版本里，frameworks/native/services/inputflinger/目录下新增了更细的reader/、dispatcher/划分，并且部分代码开始用C++17的std::optional、结构化绑定等新特性。这意味着老patch拿过来后，除了逻辑层面的问题，还有语言标准适配的问题要处理。多版本兼容时，建议用条件编译或独立类封装来隔离差异，而不是试图通过一堆#if宏把代码粘在一起。
4. 实战实现：一份兼容多版本的“全局开关”Patch
4.1 控制接口的选择
实现全局开关，免不了要决定“上层如何通知Native层冻结状态”。实际操作中无外乎三种：Binder接口、SystemProperties、自定义socket。
Binder接口看起来最正统，但实现周期长，要同时改IInputManager.aidl、InputManagerService.java和Native侧的JNI绑定，适合做商业化产品。SystemProperties最省事，修改framework层直接设置一个系统属性，Native侧监听属性变化即可，但属性的跨进程传递不是实时回调式的，轮询开销会比较难看。自定义socket则适合内部调试工具用，通过InputReader内部新增的监听端口来控制，不污染系统API。
我们最终采用的是SystemProperties + 底层状态缓存组合的方案：上层设置sys.input.touch_frozen属性，通过__system_property_set写入，底层在InputReaderThread的loopOnce循环里以20ms为周期读取一次属性值，同步更新到内存中的mGlobalTouchFrozen变量。属性读取虽然不是严格意义上的事件驱动，但20ms的轮询对触摸冻结这种低频操作来说完全够用，而且实现简单、兼容性好，不需要在不同Android版本之间维护AIDL文件。
// InputReader.cpp 中添加 void InputReader::updateGlobalTouchStateLocked() { char value[PROPERTY_VALUE_MAX]; __system_property_get("sys.input.touch_frozen", value); mGlobalTouchFrozen = (strcmp(value, "1") == 0); }4.2 在InputReader处理循环中插入开关逻辑
以Android 10到12为主要基准，我们给出一个兼容的修改方案。在InputReader::loopOnce里，我们锁定输入队列后，会从EventHub拿到一批原始事件。在此处调用更新函数，把系统属性的最新状态同步到内存变量。
void InputReader::loopOnce() { ... size_t count = mEventHub->getEvents(&mEventBuffer); if (count > 0) { { // acquire lock AutoMutex _l(mLock); updateGlobalTouchStateLocked(); processEventsLocked(mEventBuffer, count); } } ... }然后重头戏是processEventsLocked。这是所有原始事件进入后续处理管线的门卫。我们在循环内部对单个事件做判断，如果是设备添加或移除事件，仍然放行，以保证热插拔场景下系统还能正常处理设备变化。如果判断是触摸类事件，再判断冻结状态。
void InputReader::processEventsLocked(const RawEvent* rawEvents, size_t count) { for (size_t i = 0; i < count; i++) { const RawEvent& rawEvent = rawEvents[i]; if (rawEvent.type == EventHubInterface::DEVICE_ADDED || rawEvent.type == EventHubInterface::DEVICE_REMOVED || rawEvent.type == EventHubInterface::FINISHED_DEVICE_SCAN) { // Device add/remove 永远放行 processDeviceChangesLocked(rawEvent); continue; } // 全局触摸冻结时，过滤触摸设备的事件 if (mGlobalTouchFrozen) { int32_t deviceId = rawEvent.deviceId; InputDeviceNode* deviceNode = getInputDeviceNodeLocked(deviceId); if (deviceNode && deviceNode->hasTouchscreenCapability()) { // 保留按键，屏蔽触摸 if (rawEvent.type == EV_ABS) { continue; // 丢弃 } if (rawEvent.type == EV_KEY) { int32_t keyCode = classifyKeyCode(rawEvent.code); if (keyCode != AKEYCODE_POWER && keyCode != AKEYCODE_VOLUME_UP && keyCode != AKEYCODE_VOLUME_DOWN) { continue; // 非白名单按键丢弃 } } } } processEventForDeviceLocked(rawEvent); } }这段逻辑里hasTouchscreenCapability()是个关键封装，它需要从InputDeviceNode里读取设备的能力位。每个设备节点在初始化时，会通过EventHub查询/proc/bus/input/devices或ioctl获取能力标志位，触摸屏设备通常带有INPUT_DEVICE_CLASS_TOUCH或INPUT_DEVICE_CLASS_TOUCH_MT标志。通过能力判断而不是简单地按事件类型判断，可以避免把物理键盘、鼠标、遥控器这些也给过滤掉。
4.3 主动清理残留事件序列
只是简单丢弃事件，在多数情况下够用，但前面提到过，如果冻结发生在触摸序列进行中，比如用户手指还按在屏幕上，此时直接丢弃后面的事件，上层应用只会接收到一个DOWN事件，然后流石沉大海，再也没有UP。对于很多自定义View来说，这会导致按钮一直处于按压态，非常难排查。
为了解决这个问题，我们在状态切换的瞬间插入了一个主动清理动作：检测到mGlobalTouchFrozen从false变为true时，遍历当前所有触摸屏设备节点，如果发现设备有活跃的TouchSequence，就生成一个ACTION_CANCEL，投递到QueuedInputListener中，让上层的InputDispatcher立即结束当前手势序列。
void InputReader::abortActiveTouchSequencesLocked() { for (auto& deviceNode : mDevices) { TouchInputMapper* mapper = deviceNode->getTouchInputMapper(); if (mapper != nullptr && mapper->hasActiveSequence()) { mapper->abortTouchSequence(); } } }在TouchInputMapper::abortTouchSequence内部，一般是构造一个包含ACTION_CANCEL的MotionEvent，通过getListener()->notifyMotion上报。这样应用层会收到一次标准的取消事件，所有按下的状态都会立即复位。
这个细节在实际项目中帮了大忙。如果没有这步，老化测试反复切换冻结和恢复状态时，很容易出现“冻结后恢复，界面上的按钮还是高亮状态”这类问题，非常影响自动化脚本的稳定性。
4.4 冻结/恢复时的时序边界处理
冻结和恢复的切换瞬间，系统里可能有大量事件在管线里排队。最理想的流程是：冻结前，先等上一批事件处理完；冻结后，确保不再有新触摸事件进入分发队列。在单线程的InputReader模型里，这个目标通过在循环开头检查开关状态就能基本达成，但还有两个边界情况需要注意。
第一个是恢复的瞬间。如果恢复开关被触发，但InputReader当前批次的事件还没有全部处理完，那么这批事件里可能有部分触摸事件已经在冻结状态时被丢弃了，剩下的部分事件在恢复后会被继续处理。这样会导致一个不完整的触摸序列进入上层。所以在恢复开关状态后，我们不建议在当批事件中间立即恢复放行，更稳妥的做法是标记一个mPendingUnfreeze标志，等到下一轮循环再插入一个空批次执行mGlobalTouchFrozen = false，确保每个事件向量的处理都在一个确定的冻结状态下进行。
第二个是InputDispatcher侧的队列长度。如果冻结持续了很久，比如屏幕冻结了十几分钟，输入管道里已经没有任何触摸事件了，但此时用户如果发起了触摸，手机会在物理层面先缓冲一小批事件到内核输入节点。恢复触摸的瞬间，这批事件会一起涌入EventHub，导致上层一瞬间收到多个快速触摸事件。实际解决方法是恢复后，立即向InputDispatcher发送一个带有ACTION_BATTERY_LOW语义的同步屏障，让Dispatcher清理掉旧队列的时间戳，但这个方法在AOSP源码里属于深度定制，普通场景建议在恢复后加一个200ms的事件丢弃窗口作为缓冲，避免“鬼手”。
4.5 验证方法与性能开销
编译烧录后，可以用几组命令快速验证效果：
# 设置冻结 adb shell setprop sys.input.touch_frozen 1 # 触摸屏幕 -> 无任何响应，但屏幕保持常亮 adb shell getevent # 确认底层事件仍在上报 # 解除冻结 adb shell setprop sys.input.touch_frozen 0 # 触摸屏幕 -> 响应恢复正常性能开销方面，增加的这个属性读取和设备能力判断，每个事件只会多执行一次字符串比较和一个位运算判断，成本可以忽略不计。我们用自动化脚本以每秒50次的速度往触摸屏注入事件时，打开和关闭开关后的触摸响应延迟差异在1ms以内，整体感知不到。不过要注意__system_property_get在低端平台上单次调用约几微秒，如果在processEventsLocked的事件循环里每个事件都读一次属性，事件量极大时还是会有轻微损耗。这也是我们选择在loopOnce里先读属性、再更新内存变量的原因。
5. 常见问题与排查技巧实录
5.1 冻结后系统假死、没有任何输入可用
这种情况多半是过滤逻辑没有保留白名单按键，导致电源键也被丢弃。在InputReader的过滤判断里，如果返回false的事件类型覆盖了所有EV_KEY，那么电源键、音量键、Home键全部会被丢弃，系统一旦冻结就再也叫不醒。
排查方法：先确认sys.input.touch_frozen属性值确实为1，然后用adb shell getevent -lt输出事件，观察按电源键时是否有KEY_POWER事件上报。如果底层有上报但系统无响应，检查过滤条件里是否对电源键进行了白名单放行。
5.2 恢复触摸后出现“鬼手”或一次误触发
这个问题的根源在前面的“时序边界处理”里已经提到。恢复后的事件可能会有一次突发的批量涌入，或者一个未完整丢弃的触摸序列被上层应用识别成了新的手势。表现就是，恢复触摸后，哪怕手还没碰到屏幕，应用自动点了一下。
处理方案有两种，推荐先试简单的：恢复时用一个独立线程先调用一次Thread.sleep(150)再清零mGlobalTouchFrozen，把刚刚残留的内核输入队列清理掉。复杂一点的做法是在InputReader里注册一个unfreezeCallback，在恢复状态下主动触发一次FINISHED_DEVICE_SCAN型同步事件，让管线整体flush一次。
5.3 热插拔外接设备后冻结失效
如果用户冻结触摸后插拔了USB鼠标或键盘，InputReader会收到DEVICE_ADDED事件，这个事件在我们的代码里是永远放行的，所以本身不受影响。但如果外接设备也有触摸屏能力（比如一些带触摸功能的显示器），它的触摸事件就有可能绕过过滤条件。
解决办法是在DEVICE_ADDED事件处理时，重新检查全局冻结状态。如果发现当前处于冻结状态，立即把这个新设备的能力标记为“触摸已被屏蔽”，也就是在设备节点上临时挂一个FROZEN_BY_POLICY状态，后续哪怕再收到触摸事件，也会被设备节点的状态拦截。这个状态在全局解冻时统一清除。
5.4 事件处理线程的Log排查技巧
InputReader本身有systrace支持，如果问题难以定位，可以打开输入事件调试日志：
adb shell setprop persist.input.trace.enable 1 adb shell dumpsys inputdumpsys input的输出里会包含InputReader每个设备的详细状态、mapper信息以及最新事件的时间戳，可以据此判断事件到底有没有进入InputReader、停在哪个环节。我们在开发阶段还会在过滤分支里加上ALOGI，每丢弃一个触摸事件就打印一条“Touch event dropped due to global freeze”，确认过滤条件命中正常后再移除，这个习惯能省下大量反复烧录排查的时间。
5.5 多版本patch维护的实践经验
最后分享一个多版本维护上的经验。在各版本之间复制patch时，不要盲目地git cherry-pick，因为InputReader的类结构在不同版本之间差异很大。我的做法是：把“全局触摸开关”拆成三个独立的修改点——状态读取、事件过滤、序列清理，分别对应三个小的patch，然后针对每个版本单独调整函数入口位置。搜索函数入口时，优先找各版本都存在的稳定方法名，比如processEventsLocked、loopOnce、TouchInputMapper::processRawEvent，不要依赖行号或者文件名来定位。这样维护下来，从Android 8到Android 13的代码分支，每份patch的改动量能控制在几十行以内，整体风险和时间成本都低很多。
对于做系统定制或者自动化测试框架的同学来说，这个方案的优势就在于它是在输入源头的软开关，不需要动驱动、不需要改硬件，随时可以热切换，完全契合“动态冻结”这个需求。不过也正因为是在底层直接丢弃事件，调试时如果不加日志，整个触摸失灵的过程几乎没有任何痕迹，所以从一开始开发就建议把关键节点的日志通道留好，否则出了诡异问题真的会把人折磨疯。
