Android 12 sensor_fusion测试脚本调试实战：从adb到SELinux

1. 核心背景sensor_fusion测试到底在测什么1.1 传感器融合是什么sensor_fusion直译是传感器融合在Android系统里它是一个很关键又很容易被忽视的模块。简单说系统把加速度计、陀螺仪、磁力计这几路原始数据扔进融合算法最终输出设备的姿态信息——比如手机屏幕朝向、运动轨迹、AR场景里的设备位姿全靠这个模块撑着。你用导航软件横竖屏切换、玩体感游戏背后都有它在干活。而所谓的sensor_fusion测试脚本本质上就是一套自动化验证手段往设备里灌入或触发指定传感器数据检查融合算法输出的姿态角、四元数、旋转矩阵这些结果是不是在预期误差范围内。这个测试网上能找到很多变体版本有的是Python写的有的是shell脚本套Java工具但核心逻辑都差不多驱动sensor事件 - 采集融合输出 - 对比阈值 - 输出pass/fail。1.2 Android 12上测试链路的特殊性把测试放到Android 12上情况就不一样了。Android 12在传感器这块做了不少底层改动比如传感器权限从位置权限的一部分里进一步剥离新增了body sensors后台权限限制sensor HAL的接口虽然大体延续了HIDL到AIDL的过渡节奏但部分厂商在适配时改写了自己的实现SELinux策略也比以前更严ndk可执行文件往设备上随便一推就能跑的时代在Android 12上好几次都被卡得死死的。所以你会看到一个很奇怪的现象同一个sensor_fusion测试脚本在Android 11的真机上跑得顺顺当当换到Android 12上就是各种花式报错要么是找不到设备要么是权限被拒要么是脚本根本起不来。这篇文章就是要把这些坑一个个填平从最底层的adb连接讲起一直到脚本跑完、数据回传把整条链路打通。2. 调试基础先把adb这条链路彻底打通2.1 adb环境配置与版本选择很多报错的根源不在脚本而在于adb环境本身。我见过太多同事电脑里装了各种杂七杂八的手机助手导致adb版本混乱一执行adb devices就出现adb server version doesnt match this client。这里说下我的固定做法只用Google官方platform-tools不走各种助手自带的老旧adb。# 下载并解压platform-tools后配置系统PATH export PATH$PATH:/你的路径/platform-tools # 验证版本 adb version # 看到类似如下输出即为正常 # Android Debug Bridge version 1.0.41 # Version 34.0.4-10950400配置好之后建议执行adb kill-server再adb start-server把可能残留的旧server进程清掉。这一步很多人忽略但它能解决一半以上的连接正常但命令无响应问题。Android 12对adb版本没有严格下限要求但建议用新版platform-tools因为新版对无线调试的支持、对Android 12权限模型的适配都更到位。老版本在Android 12上偶尔会遇到device unauthorized反复出现的诡异问题换新版本立马好。2.2 Android 12无线调试的正确打开方式做传感器测试时频繁插拔USB线其实是很大的负担尤其是设备要固定在支架上跑姿态测试一插线就破坏了物理姿态。所以Android 11开始引入的无线调试在Android 12上是我的主力连接方式它比老式的adb tcpip 5555稳定得多。老的无线调试方式叫网络adb需要先用USB连接一次然后执行adb tcpip 5555再把线拔掉用adb connect 手机IP:5555。这种方式在Android 12上依然能用但有明显的毛病一是每次重启设备后端口会失效得重新插线设置二是如果设备处于深度休眠连接经常断。Android 12的无线调试是在开发者选项里直接开的还带了加密配对机制开发者选项 - 无线调试 - 开启开启后点使用配对码配对设备会弹出一个6位配对码。电脑端执行# 配对只需要做一次 adb pair 192.168.1.100:41231 # 输入6位配对码 # 连接 adb connect 192.168.1.100:41231注意配对端口和连接端口是不一样的面板上会分别显示。连接成功后adb devices里会出现192.168.1.100:41231 device而不是unauthorized或offline。2.3 授权异常与多设备环境处理无线调试最怕的就是unauthorized状态这个问题在Android 12上尤其闹心。设备的RSA指纹信任是保存在/data/misc/adb/adb_keys里的一旦你误点了撤销USB调试授权或者换了电脑连接设备就会提示是否信任此电脑。如果设备是黑屏状态或者锁屏了你根本点不到那个允许按钮然后就是无限循环的unauthorized。遇到这种情况别急着重启设备先试这几步锁屏状态下无法点授权框时先点亮屏幕并解锁。如果授权框一直弹不出来执行adb kill-server后重新连接。实在不行在开发者选项里点撤销USB调试授权然后重新插入USB线让设备重新弹窗。设备如果锁屏但没锁屏密码可以临时用adb shell locksettings set-disabled true解锁但这个命令同样要求先有一台已授权的adb连接可用所以它解决不了连不上的问题只能用于连上了但不想每次解锁的场景。多设备同时调试时建议给每个设备加个标识adb devices -l # 通过设备序列号区分 # 指定设备执行命令 adb -s 序列号 shell我用无线调试同时管理过4台不同型号的设备-s参数是必须的不然adb会报more than one device/emulator这个报错不算致命但很打断节奏。3. 完整实操从脚本下推到结果回传3.1 测试脚本的构成与检查先看一份典型的sensor_fusion测试脚本长什么样。大多数开源版本是Python脚本依赖pyserial或adb库通过usb或adb发送sensor数据模拟指令也有纯shell版本配合dumpsys sensorservice来读取传感器状态。我用的这套大致结构如下sensor_fusion_test/ ├── run_test.py # 主入口 ├── test_vectors/ # 预置的传感器输入数据集 ├── lib/ │ ├── adb_utils.py # adb交互封装 │ └── fusion_checker.py # 融合结果校验逻辑 └── config.json # 设备信息与测试参数在把脚本往Android 12设备上推之前务必先在电脑上把Python依赖装齐。常见的是pip install numpy pyserial如果脚本用了adb库还得确认adb可执行文件在PATH里。这一步经常会遇到ModuleNotFoundError: No module named serial我在后面报错章节会专门讲。另外Android 12设备的sensor相关服务是sensorservice测试前最好先确认设备上的sensor列表符合预期adb shell dumpsys sensorservice | grep -A 20 Sensor list如果设备自检都过不了脚本跑起来也只会得到一堆无意义的失败结果。3.2 脚本推送与权限设置脚本准备好之后用adb把它推到设备里。很多测试脚本是要在设备端直接运行的比如编译好的so库配合shell脚本调用。这类文件通常推送到/data/local/tmp目录因为这个目录对shell用户是可写的而且不涉及SELinux的大范围限制。# 推送整个测试目录到设备 adb push sensor_fusion_test /data/local/tmp/ # 进入设备shell adb shell cd /data/local/tmp/sensor_fusion_test # 给脚本和可执行文件加执行权限 chmod 755 run_test.sh chmod 755 lib/arm64-v8a/fusion_test这里必须强调Android 12对/data/local/tmp下的可执行文件有SELinux限制直接运行经常报Permission denied即使你chmod 777也没用。解决办法后面会细说这里先记住一个原则能用shell脚本调的就不用ndk可执行文件能推到/data/local/tmp就不推到/data可以减少很多权限风波。3.3 执行测试与实时观测脚本执行过程中我习惯开三个终端一个跑测试脚本一个实时看logcat一个盯着sensorservice的状态。# 终端1执行测试 adb shell cd /data/local/tmp/sensor_fusion_test ./run_test.sh # 终端2抓取sensor相关日志 adb logcat -s SensorService -s sensors -v time # 终端3实时查看sensor状态 adb shell dumpsys sensorservice | grep -E active|fusion|orientationAndroid 12的日志tag和旧版本有些差异旧版本用-s Sensors能过滤出来12上更稳定的是SensorService某些厂商的ROM还自定义了tag比如华为是HwSensorService。遇到logcat抓不到东西的时候先不加过滤看全量日志确认tag名再减小范围。测试过程中重点关注这几个指标传感器事件的频率是否稳定、融合算法输出的姿态角是否连续无跳变、从数据注入到输出更新之间的延迟大小。我实际遇到过很多次脚本跑起来看起来一切正常但姿态角每隔几帧就跳一个大值这种数据异常如果只看pass/fail汇总根本发现不了必须实时盯着曲线或者抓原始输出分析。3.4 日志抓取与数据回传测试跑完之后设备端的日志和数据需要拉回电脑分析。这一步看似简单但有讲究# 抓取完整logcat到文件并拉回 adb logcat -d full_logcat.txt # 直接导出sensorservice状态 adb shell dumpsys sensorservice sensorservice_dump.tx # 拉取测试脚本生成的结果文件 adb pull /data/local/tmp/sensor_fusion_test/results ./results如果你用的是adb截图来验证UI状态也可以用adb exec-out screencap -p screen.png这种方式比adb shell screencap再adb pull少一次中转在无线调试下稳定性更好。还有一个细节无线调试时拉大数据容易中途断。我遇到过百来兆的日志拉一半就断的情况解决方法是拉之前先执行adb shell sync确保设备端的文件已经落盘避免拉到的是不完整的缓存数据。而且建议用adb pull的断点续传新版adb对pull命令做了resume优化旧版本则没有这也是我用新版本platform-tools的原因之一。4. 高频报错与排查方案4.1 连接与授权类报错报错1unauthorized device这个不用多说了前面提过。常见于第一次连接新电脑、或者设备端误操作撤销了授权。排查顺序是解锁设备屏幕 - 查看是否有授权弹窗 - 点击允许 - 如果没弹窗就撤销授权重来。无线调试下尤其注意配对成功不代表授权成功配对只是交换了密钥最终的信任此电脑确认框还是要手动点的。报错2device offline设备显示offline而不是device说明adb server和设备之间的通信已经断了。无线调试下最常见的原因是设备休眠导致网络连接挂起。解决方式# 先断开 adb disconnect # 重新连接 adb connect 设备IP:端口 # 如果依然offline adb kill-server adb start-server adb connect 设备IP:端口报错3more than one device/emulator这个纯粹是设备多了没指定序列号。解决办法用-s参数指定或者在adb connect时一个终端对应一台设备。4.2 权限与SELinux类报错Android 12上最阴间的就是这类报错形式千变万化但根源基本一致SELinux策略把shell域的可执行权限给限制死了。报错4Permission denied已经chmod 777了执行设备端二进制时报这个错第一反应通常是检查权限位但如果权限位没问题那就得看SELinux了。执行# 查看SELinux状态 adb shell getenforce # 输出Enforcing就是严格模式Permissive是宽松模式在严格模式下/data/local/tmp下自己push进去的文件默认继承的是shell域上下文但直接exec可能被限制。一个临时方案是把SELinux调到Permissiveadb shell setenforce 0但设备重启后会恢复Enforcing而且部分厂商的固件锁死了setenforce会报setenforce: setenforce() failed。这种情况下要么改用shell脚本调系统已有的工具要么把被测文件打成一个系统镜像重新刷入后者改动太大一般用前者。报错5CANNOT LINK EXECUTABLE可执行文件本身能执行权限通过了但链接动态库时失败。通常是ndk编译时链接了设备上不存在的库版本。Android 12对动态库的命名空间隔离更严格直接用dlopen加载/data/local/tmp下的so是会失败的。解决思路是把so放到/system/lib64或者/vendor/lib64这种系统库目录或者编译时把依赖库全静态链接进去。测试场景里我通常选择静态链接一了百了虽然so体积大一点但省去一堆加载问题。报错6remote object doesnt exist / unknown host service这个报错发生在执行adb shell尝试访问某个服务端口时目标是服务没有启动或者端口写错了。传感器脚本如果依赖设备的某个自定义sensor HAL服务在Android 12上该服务可能没启用。排查办法adb shell ps -A | grep sensor adb shell lshal | grep -i sensor检查HAL服务是否在跑。如果没跑大概率是init rc脚本里没有trigger这个服务需要手动adb shell start 服务名不过这个操作需要root权限普通userdebug固件下还经常被selinux挡住。4.3 传感器服务类报错报错7dumpsys sensorservice没有输出或输出为空执行adb shell dumpsys sensorservice发现结果里没有任何sensor列表。这个情况我在某些Android 12的user版本上见过原因是sensorservice进程崩了或者被系统反复拉起又崩掉。# 确认进程状态 adb shell ps -A | grep sensor # 查看崩溃日志 adb logcat -b crash | grep -i sensor如果是连续crash根因往往是底层sensor HAL的so库与Android 12的接口不匹配。这种问题光靠脚本debug是无解的需要联系驱动/固件团队拿一个适配Android 12的sensor HAL来刷。报错8sensor数据不更新脚本执行后姿态角输出一直不变。先别怀疑算法先验证原始sensor是否有数据# 查看每个sensor的事件上报情况 adb shell dumpsys sensorservice | grep -A 5 active connection如果accel和gyro的频率值都是0说明传感器没有真正使能HAL层就没上报数据。如果原始数据在动但融合输出不变那才有可能是fusion算法的问题。这里分享一个排查经验Android 12上传感器的批量上报模式batch mode如果配置有误事件可能只报一次就停了。看logcat里有没有batch timeout或flush complete的异常输出有的话基本就是sensor HAL对batch模式的支持有问题。报错9permission denial for sensor accessAndroid 12把传感器权限细化得非常多什么BODY_SENSORS、HIGH_SAMPLING_RATE_SENSORS如果没有对应权限app层访问sensor会被拒绝。但如果你是在adb shell里用root或者shell权限跑测试一般不受permission限制。真正被权限卡住的是你用普通应用去跑测试脚本的情况。这时需要在AndroidManifest.xml里声明权限并且在运行时动态申请。单位的测试APK曾经就因为这个在Android 12上直接拿不到sensor数据升级targetSdk到31之后权限申请逻辑必须重写。4.4 脚本运行环境类报错报错10python3: not found / no module named serial这是把Python脚本推到设备上直接运行时的高频报错。Android系统本身不自带Python你要么用adb shell里已有的toolbox/toybox命令重写测试逻辑要么就把Python脚本放电脑端跑通过adb遥控设备。后一种是更合理的架构电脑端Python负责下发命令设备端只负责执行底层sensor操作。# 电脑端执行通过adb调设备端的dumpsys python3 run_test.py --device 192.168.1.100:41231报错11index error / type error脚本自身逻辑排除环境问题后脚本本身的报错也得重视。最常见的是解析dumpsys sensorservice输出时Android 12改了输出格式导致脚本按旧正则去匹配匹配不到就报IndexError。遇到这种情况先手动执行一次dumpsys把输出保存下来对着脚本里的正则debug。我在Android 12上就遇到过它把Sensor 0x00000001这种十六进制句柄的显示方式改成了十进制脚本用0x开头去匹配直接全废。报错类型典型报错信息根因解决方案连接类device unauthorizedRSA指纹未信任解锁屏点确认授权连接类device offline无线连接断开/休眠adb disconnect后重连权限类Permission deniedSELinux Enforcingsetenforce 0或换shell方案链接类CANNOT LINK EXECUTABLE动态库找不到/命名空间隔离静态链接或放系统库目录服务类dumpsys无输出sensorservice崩溃logcat -b crash定位服务类sensor数据不更新batch模式配置异常检查HAL上报事件频率环境类python3: not found设备无Python环境脚本放电脑端adb遥控5. 调试过程中最值的几条经验做了这么多轮的sensor_fusion测试Android 12这次让我印象最深的一句总结就是先通链路再谈测试。脚本报错别急着改代码先确认adb连接是否正常、SELinux状态是什么、sensorservice是否稳定。这三个前提不满足后面所有调试都是白费功夫。还有一个实实在在的建议把常用的排查命令整理成一个shell脚本一键执行。我自己是写了个sensor_debug.sh里面包含设备连接状态检查、sensorservice dump、关键logcat抓取、SELinux状态查询每次换新设备或者遇到诡异问题先跑一遍这个脚本能省下至少半小时的排查时间。最后多说一句Android版本迭代越来越快sensor_fusion测试脚本这种东西最好的维护策略不是追着每个版本的格式改来改去而是把数据采集和结果解析做成两层设备端只管采集原始数据电脑端做解析和断言。这样下次Android 13、14改了输出格式你只需要更新电脑端的解析函数设备端的采集逻辑一行都不用动。这套思路帮我在后续的Android版本升级里少踩了很多坑分享出来供你参考。