learnframework的博客

但是明显只使用命令还是有以下问题，命令注入事件性能不够块，注入的事件需要提前准备好，相当于只能实现录制事件，然后播放录制事件这种，所以基于这个背景那就需要有一个非常灵活的方式通过uinput来实现对事件的自由控制，那么需要使用代码来实现对/dev/uinput节点直接进行相关的事件写入，这样事件发什么都是由代码自由控制，灵活性大大提高。下面就用代码实现注入鼠标设备，而且鼠标可以在拨号盘上面进行点击的功能。对应的Android.mk文件。

要使用uinput命令一共需要2个步骤：1、录制好相关的 evemu-record文件，这里需要使用。

uinput通过创建一个虚拟的输入设备接口，允许用户在没有物理输入设备的情况下模拟输入操作。它允许开发者在软件层面模拟硬件设备的行为，这对于开发和测试涉及输入设备的软件非常有用。uinput支持多种输入事件，包括键盘按键、鼠标移动和点击等，使得开发者可以方便地测试和调试相关的应用程序。

更多framework实战干货，请关注下面“千里马学框架”

1、壁纸窗口本身在创建时候就已经有创建好对应的InputChannel，而且也会和正常窗口一样会有InputWindow在InputDispatcher，而且位置一般处于最底层2、要让壁纸可以接收事件，需要调用 setTouchEventsEnabled(true)，主要是把Window不进行设置NOT_TOUCHABLE的flag。

那么他这个anr到底是怎么复现的呢，具体是个啥情况呢？针对这个ANR问题，我与该学员沟通了解情况后，发现他这种anr问题明显不是常规的那种app某个地方执行耗时导致的卡顿，所以常规那种抓取anr trace来分析定位的套路明显就不行了。需要复现该问题，其实需要对系统正常的相关源码进行一些修改才可以，学员朋友也是一样，他修改了相关源码引入了ANR问题，但是又不知道怎么引入的。昨天有相关学员朋友一直在vip群里提出他的一个ANR问题，一直说自己分析这个ANR完全没有相关的头绪。2、分析出anr的原因。

在framework系统是属于一个很复杂的体系，每个小分支都会有很多不同的处理方式等，所以当使用正规的思路打堆栈分析不出来时候，不应该直接放弃，更应该从逆向，或者多角度来尝试探索分析，这样才符合实际项目中遇到各种问题都可以使用学习的知识灵活应对，而不是仅仅套一下模板，一旦有一些异常变化就又不知道如何分析，教给各位粉丝的知识一定要活学活用哈，整体理解多角度分析。更多framework实战干货，请关注下面“千里马学框架”

偷”走了其他窗口的事件，本质实现就是调用pilferPointers方法，实现让其他窗口收到CANCEL事件，同时派发的窗口列表中移除非token的window，后续事件派发时候，只派发给token对应的window。更多framework实战干货，请关注下面“千里马学框架”

近期有学员朋友在群里提出了关于input模块中的一个批处理相关的疑问点。针对这个批处理这块知识点，马哥不打算直接给大家blog输出干货给大家，即不准备直接给大家喂相关的知识点，而是采用给大家布置几个作业疑问点方式，让大家积极参与进来思考的方式。如果针对move事件不采用批处理方式，也和down事件一样，有事件来了就直接进行相关的派发主线程处理，那么可能会造成什么样的后果呢？为什么会需要有这个方法?好了上面就是留给大家关于input相关的思考作业哈，后续马哥这边会给大家进行剖析解答，更新到相关的vip群中。

已经分享过如何实现这种大厂里面一键连招，触摸宏的功能，原理本身是对dev/input下面的节点进行读取保存文件，然后在读取文件进行写入dev/input下面的节点，从而实现了触摸事件的读取和写入，不过这个一定要root的手机版本。很多同学就提出是否可以考虑参考scrcpy的事件注入，即已经实现了触摸注入了，只需要再额外补充一个事件的录制保存文件既可以。可以看的出这里重点的方案就是scrcpy如何获取用户的触摸事件，即要监听到全局的触摸事件。通过上面几步骤就完成了监听触摸事件保存到文件的操作。

1.EV_SYN同步事件完，在事件开始或完成会有对应的code：0004：代表一个事件开始（不必要）0005：代表一个事件开始（不必要）SYN_REPORT：代表一个事件的结束 （必要）## 2.EV_ABS事件的一种绝对坐标类型对应code：2.0 ABS_MT_SLOT本质代表者不同手指，它的value代表手指id2.1 ABS_MT_TRACKING_ID

简单说就是在多屏互动过程中，需要把Activity从这个屏幕移动到另一个屏幕，必然就导致原来屏幕的Activity相关会有移除，体现在input端就是相关的InputWindow会被remove，这个时候input派发事件发现根本没有可以用的window了，所以自然就无法派发事件了，因为不知道派发给谁。这个其实就需要对相关的InputDispatch代码进行详细的分析了。只能拖到一小段，然后在接收事件的部分就收到了一个CANCEL事件，但是在导航手势模式下却没有该问题。

hi，本节课我们来讲解一下经常做触摸相关开发同学都必须要掌握的一个命令：getevent下面将通过2个部分来分别讲解1、具体使用方法gemini:/ $ getevent -hUsage: getevent [-t] [-n] [-s switchmask] [-S] [-v [mask]] [-d] [-p] [-i] [-l] [-q] [-c count] [-r] [device] -t: show time stamps -n: don't print newlines

整个时序来说Activity的onCreate,onResume对应的LaunchActivtyItem的消息，在systemserver的realStartActivity就已经比focus的消息要早，导致app主线程早就有了onCreate，onResume的任务，focus消息还需要来回和sf跨进程后才可以到InputDispatcher，InputDispatcher。那么这个时候handler里面就有了相关的onCreate，onResume等执行的消息调用，都会在主线程执行。

到这里就完美解释清楚了ActivityRecordInputSink巨大区域是哪里来的，本质还是因为replaceTouchableRegionWithCrop设置成了true

既然上面分析的Instrumentation已经不行了，也不太可能修改framework把Instrumentation代码修改或者扩展，这里就使用和scrcpy的方法一样，采用InputManager接口，但是接口又是hide的，可以和scrcpy一样采用反射方式，我这边给出一种新方法，不采用反射，用的是一个模拟假接口，类和接口和InputManager一模一样，但是空实现。明显看到这里居然报错了，，，明明android 10版本是好的，那这个是为啥？所以可以排除掉没有权限的问题，那么为啥还会报错呢？

token是在InputChannel创建时候就有构造----》传递给WindowState的InputWindowHandleWrapper中------》InputMonitor遍历传递给Sf---------》Sf传递给InputDispatcher

其实这个在input专题的源码分析时候就有讲解过，不过那时候是完全基于源码分析的，没有和systrace或者perfetto结合起来分析，今天马哥就来补充一下这块知识。同学们经常在分析systrace或者perfetto时候，都会面临一个分析iq，oq，wq的问题，这个iq，oq，wq，到底是指的什么呢？这里3个过程中，离我们app处理最近的当然是第三个步骤，经常说的iq,oq,wq其实也是属于InputDispatcher类里面的变量。注意啦，这里的oq是带着有具体的目标窗口的。

dumpsys input可以看到一个ActivityRecordInputSink在Activity的下面

hi。

执行完成后手机画面一般就会响应一个click事件，这里发现一般都是一个手指，一直寻找看看input命令是否可以支持多个手指通过命令同时按下操作的情况，发现并没有这种多指的触摸的命令。pointId1 x y --pointId0代表具体手指索引，可以区分不一样手指，一般0开始，x，y代表是触摸事件的坐标位置。input tap命令只是进行传递了x,y坐标值，并没有传递多指相关的任何id，所以是不支持的多指的。考虑设置一个可以多指点击命令项，暂时命名叫做multiple-tap。看看这里sendTap。

所以这里的就会存在在CarLauncher上面显示两个Activity，一个是桌面自己，一个是地图绿色的Activity，但是大家注意哈，这里的绿色区域的地图Activity明显属于另一个display，这里我们是知道的触摸都是每个display独立的，即多屏display显示都是有各自display的触摸节点。看这里触摸事件时候大家是不是发现明明这个displayId居然还是0，明显不太和逻辑是吧，，，正常触摸事件是不是应该为displayId = 1（假设虚拟屏幕是displayId = 1）

可以看到的它的画面大小确实是frame=[0,84][1440,2960]，但是有一个touchableRegion=[0,1759][1440,2960],这个区域才是真正的触摸区域，这里我们就看出了猫腻，这里y是从1759的位置才开始可以触摸了，也就是我们上面看到的输入法的键盘区域。层级结构看输入法应该是盖在Activity的窗口上面，而且输入法又是全屏的，那么理论上所有的触摸事件就应该到输入法的窗口，而不应该到Activity的窗口。可以看出这里的setTouchableRegion设置是由触发。

即可以看出来，再服务端systemserver其实传递的触摸事件依然是move，只是move事件到了app端后，由于app端自己的业务把这个传递的move事件变成的cancel。如果发现更新之后的window的中已经没有了正在派发事件的window，那么说明window已经被移除，然后就会触发相关的cancel事件到原来的window。最为关键的mTouchStatesByDisplay变量，一般保存就是当前触摸事件的派发情况，主要保存了派发触摸相关的window信息。最后更多干货直接找千里马可以+w；

去源码的out路径下修改/aosp/out/target/product/emulator_x86_64/vendor/usr/idc/virtio_input_multi_touch_7.idc。确定了了display的port还有一个input相关inputPort参数，这个就直接通过dumpsy input获取哈，在dumpsys寻找对应屏幕的event，从而找到对应的Device。就是这里的 Location: virtio17/input0，virtio17/input0就是我们要的。

动态壁纸可以接受触摸事件，壁纸上面的Launcher也可以接受触摸事件，这个场景就是经典的，Wallpaper属于单独的window图层再最底层，Launcher是个Activiyt也是单独的Window图层L位于Wallpaer的上层，但是触摸桌面时候发现下面的壁纸也是可以接受到相关的触摸事件。哈其实这里壁纸是再WallpaperService中实现了一个类似InputMonitor，即它可以负责接受系统所有的事件，无论触摸事件派发到任何窗口上面，他都可以接受到，即全局监听了系统的所有触摸事件。

hi，粉丝朋友们：这两天刚好在做自由窗口相关国内需求，刚好遇到一个疑惑，那就是画面进行缩放后发现依然触摸画面可以正常反映问题。