1. 车机无线调试到底解决了什么痛点做车载测试这行的朋友都清楚车机调试最烦人的一件事就是接线。早期做车机测试基本上人手一根USB线从工位拉到车机端口线短了够不着线长了绊脚稍微碰一下接触不良就掉线。更别提整车环境下的测试车机装在仪表台里面你根本不可能趴到副驾脚垫上去插线。所以当adb无线调试这个能力在车机端逐步开放之后整个测试效率的提升是肉眼可见的。adb无线调试的核心原理其实不复杂。adb本身是Android Debug Bridge的缩写是Android系统提供的一套调试桥接工具。它默认走USB通道但同时也支持通过TCP/IP协议进行网络通信。只要车机和你的电脑处在同一个局域网内就可以把adb的连接方式从USB切换到网络从而实现无线调试。这个能力对车载测试来说意义很大因为车机本质上就是一个定制化的Android设备只要它能开放adb调试权限你就能用同一套工具链去操作它。但问题在于车机不是手机。车机的系统定制程度远高于普通手机不同车机厂商对adb的开放程度、网络配置方式、端口策略都不一样。有些车机默认关闭了adb网络调试功能有些车机虽然能连上但过一会儿就断还有些车机在无线调试模式下权限会被降级。这些坑我在实际项目中都踩过所以这篇文章不只是告诉你几个命令怎么敲更重要的是把每个命令背后的逻辑、适用场景、以及可能遇到的问题讲清楚。这篇文章适合谁看如果你是刚入行车载测试的新人正在被各种线缆和连接问题折磨那这5个命令能帮你快速建立无线调试的工作流。如果你是有一定经验的测试工程师但一直用USB线做调试想切换到无线方式提高效率那文中的避坑指南能帮你少走弯路。如果你做的是车机自动化测试需要批量管理多台车机设备那无线调试更是绕不开的基础能力。下面我会围绕5个核心adb命令展开每个命令都会讲清楚它解决什么问题、怎么用、参数怎么配、以及我在实际使用中遇到的坑和应对方法。命令本身不难难的是知道什么时候用哪个命令、参数怎么调、出了问题怎么排查。2. 无线调试前的环境准备与连接建立2.1 车机端和PC端的网络前提在敲任何adb命令之前你得先确保两件事车机和电脑在同一个网络里以及车机的adb调试权限已经打开。这两件事听起来简单但实际操作中经常卡住。先说网络。车机联网的方式通常有两种一种是车机自带4G/5G模块通过移动网络上网另一种是通过WiFi连接局域网。做无线调试必须用第二种因为adb的TCP连接需要车机和电脑在同一个局域网内能互相ping通。车机用移动网络上网时你的电脑是没法直接访问到它的。具体操作上你需要让车机连接到一个和电脑相同的WiFi热点。如果测试环境里没有现成的WiFi可以用电脑开一个移动热点让车机连上来。Windows系统在“设置 - 网络和Internet - 移动热点”里可以开启热点功能把网络共享给车机。Mac系统在“系统偏好设置 - 共享 - 互联网共享”里也能做类似的事。这样车机和电脑就在同一个子网里了。连上之后你需要在车机上查到它的IP地址。不同车机的查看方式不一样常见的有几种在车机的“设置 - 关于 - 状态信息”里找IP地址或者在车机的开发者选项里查看如果车机支持终端应用也可以直接在里面输入ifconfig或ip addr来查看。拿到IP地址后先在电脑上ping一下确认网络是通的。注意有些车机的WiFi模块在连接后会进入省电模式导致网络不稳定。如果发现ping延迟很高或者丢包可以在车机的开发者选项里关闭WiFi省电优化或者让车机保持充电状态。2.2 车机端adb调试开关的开启车机的adb开关和手机不太一样。手机通常在“开发者选项”里有一个“USB调试”开关打开就行。但车机的adb开关位置五花八门有的在开发者选项里叫“ADB调试”有的叫“网络调试”还有的藏在工程模式里。常见的开启方式有这么几种。第一种是在车机设置里连续点击“版本号”或“系统版本”7次激活开发者选项然后在开发者选项里找到adb相关开关。第二种是在车机的拨号界面输入特定的工程代码进入工程模式后开启adb。第三种是通过车机上的特定应用比如某些车机自带的“调试助手”来开启。具体用哪种方式取决于你的车机型号和系统版本。这里有个经验如果你拿到的车机是已经量产版本的adb开关很可能被厂商锁定了。这种情况下你需要联系车机的系统供应商或者通过特定的工程账号来解锁。有些车机在出厂时会把adb端口设成非标准端口比如5555之外的端口号这个也需要提前确认。开启adb调试后建议在车机的开发者选项里同时打开“保持唤醒状态”和“允许模拟位置”这两个选项。前者防止车机在调试过程中休眠断连后者在某些需要模拟GPS信号的测试场景下会用到。2.3 第一次连接从USB到无线的切换环境准备好之后第一次连接建议还是先用USB线连一次。原因很简单你需要通过USB连接来授权电脑的adb密钥并且把车机的adb服务切换到TCP模式。具体步骤是这样的。先用USB线把车机连到电脑上在电脑终端里输入adb devices确认设备列表里出现了车机设备。如果显示的是unauthorized说明车机上还没有授权这台电脑你需要在车机屏幕上点击“允许USB调试”的弹窗。如果车机上没有弹窗可能是车机的adb授权界面被定制掉了这种情况需要手动把电脑的adb公钥推送到车机的/data/misc/adb/adb_keys文件里。授权成功后输入adb tcpip 5555这个命令的作用是把车机的adb服务从USB模式切换到TCP模式监听5555端口。执行成功后你就可以拔掉USB线了。然后在电脑上输入adb connect 车机IP:5555如果一切正常会显示connected to 车机IP:5555。再输入adb devices应该能看到两个设备条目一个是USB的一个是网络连接的。提示adb tcpip命令设置的端口号默认是5555但有些车机可能占用了这个端口或者厂商指定了其他端口。如果5555连不上可以试试adb tcpip 5556或其他端口然后adb connect时用对应的端口号。这里有个容易忽略的细节adb tcpip命令在车机重启后会失效车机会恢复到USB模式。所以每次车机重启后你都需要重新用USB线连一次再执行adb tcpip 5555。如果车机支持在开发者选项里直接开启“网络adb调试”那就可以跳过USB这一步直接在车机上开启网络调试然后电脑上adb connect就行。但很多车机没有这个选项所以USB切换法还是最通用的方式。3. 五个核心adb命令的实战用法3.1 adb connect与adb devices连接管理与设备识别adb connect和adb devices是无线调试的入口命令看起来简单但实际使用中有不少细节。adb connect的基本用法是adb connect IP:端口。连接成功后adb会把设备信息保存在本地的设备列表里。但这里有个问题adb的连接状态不是实时的。有时候车机已经断网了但adb devices里还显示设备在线这时候你执行任何adb命令都会卡住或者报错。所以我的习惯是在执行关键操作前先用adb devices -l看一下设备的详细状态确认设备是真的在线。adb devices的输出格式是这样的List of devices attached 192.168.1.100:5555 device如果显示的是offline说明连接建立了但设备没有响应通常是车机端的adb服务挂了需要重启车机的adb服务或者重新连接。如果显示的是unauthorized说明授权没通过需要重新授权。在实际项目中我经常需要同时连接多台车机做对比测试。这时候adb devices会列出多个设备你需要在每条adb命令后面加-s 设备序列号来指定操作哪台设备。比如adb -s 192.168.1.100:5555 shell。设备序列号就是adb devices里显示的那一列。还有一个实用技巧如果你经常需要连接同一台车机可以在电脑上写一个批处理脚本或者shell脚本把adb connect和adb devices封装进去一键完成连接和状态检查。这样每次调试前跑一下脚本就行不用手动敲命令。注意adb的默认连接超时时间是5秒如果车机响应慢可能会连接超时。可以通过设置环境变量ADB_CONNECT_TIMEOUT来延长超时时间比如设为10000毫秒。3.2 adb shell车机内部操作的万能入口adb shell是使用频率最高的命令没有之一。它的作用是让你在电脑上直接执行车机内部的shell命令相当于远程登录到车机的Linux终端。基本用法是adb shell 命令。比如adb shell ls /sdcard/可以查看车机内部存储的文件列表adb shell pm list packages可以列出车机上安装的所有应用包名adb shell dumpsys battery可以查看电池状态。这些命令在车载测试中非常常用。但adb shell在车机上有几个特殊的坑。第一个坑是权限问题。车机的adb shell默认权限通常是shell用户不是root。有些目录和文件是shell用户无权访问的比如/data/data/下的应用私有数据。如果你需要访问这些数据要么车机已经root了要么你需要用run-as命令以应用的身份来访问。比如adb shell run-as com.example.app ls /data/data/com.example.app/。第二个坑是命令兼容性。车机的Android版本和桌面Linux发行版不一样很多常用的Linux命令在车机上可能不存在或者参数不同。比如grep命令在有些车机上不支持-P参数find命令的用法也可能有差异。遇到这种情况可以先adb shell进去然后用which命令确认某个命令是否存在再用命令 --help查看支持的参数。第三个坑是中文乱码。车机上的shell环境可能没有配置UTF-8编码导致中文文件名或者中文输出显示为乱码。解决办法是在adb shell命令前加上LANGen_US.UTF-8或者直接在电脑端用adb exec-out代替adb shell来获取二进制输出。在实际测试中我经常用adb shell做这几件事查看车机的系统属性getprop、检查网络状态ifconfig或ip addr、查看当前运行的进程ps -A、以及执行车机上的特定测试脚本。这些操作在USB模式下和无线模式下完全一样但无线模式下你可以坐在工位上操作不用趴在车里。3.3 adb logcat日志抓取与问题定位adb logcat是车载测试中排查问题的核心工具。车机上的应用崩溃、系统异常、性能问题基本上都要靠logcat来定位。基本用法是adb logcat它会实时输出车机的系统日志。但直接输出所有日志信息量太大通常需要加过滤条件。常用的过滤方式有几种按标签过滤adb logcat -s TAG、按优先级过滤adb logcat *:E只显示Error及以上级别、按进程ID过滤adb logcat --pidPID。在车载测试中我常用的logcat命令组合是这样的adb logcat -v time -b main -b system -b crash logcat_$(date %Y%m%d_%H%M%S).txt这个命令的作用是把main、system、crash三个缓冲区的日志都抓下来带上时间戳保存到文件里。-v time表示日志格式包含时间信息-b指定要抓取的缓冲区。车机上的日志缓冲区通常比手机多除了标准的main、system、crash之外还有radio、events等。具体有哪些缓冲区可以用adb logcat -b all -v brief来查看。抓取日志时有个很重要的技巧先清空旧日志再抓。用adb logcat -c清空所有缓冲区然后复现问题再抓取日志。这样日志文件里只有问题复现过程中的记录排查起来效率高很多。如果不先清空日志文件里会混入大量无关的历史记录找问题就像大海捞针。还有一个坑是日志丢失。车机的日志缓冲区大小有限如果日志产生速度太快旧的日志会被覆盖。对于需要长时间抓取日志的场景建议用adb logcat -r 1024 -n 10这样的参数让logcat自动轮转日志文件每个文件1024KB最多保留10个。这样即使抓取时间很长也不会因为缓冲区溢出而丢失关键日志。提示如果车机上的logcat命令被厂商定制过参数可能不完全一样。可以先adb shell logcat --help看一下支持哪些参数。另外有些车机会把日志写到特定的文件里比如/data/log/或/sdcard/logs/这些文件也可以用adb pull拉取下来分析。3.4 adb pull与adb push文件传输的双向通道adb pull和adb push是文件传输命令在车载测试中用途很广。adb pull是把车机上的文件拉到电脑上adb push是把电脑上的文件推到车机上。基本用法是adb pull 车机路径 电脑路径和adb push 电脑路径 车机路径。比如adb pull /sdcard/logs/ ./logs/可以把车机上的日志目录拉到电脑当前目录下。在车载测试中这两个命令的典型使用场景包括拉取车机上的日志文件、推送测试APK到车机安装、推送配置文件到车机、以及拉取车机上的截图和录屏文件。这里有几个实操中总结出来的经验。第一路径中的空格和特殊字符要处理好。车机上的文件路径可能包含中文或空格这时候需要用引号把路径括起来比如adb pull /sdcard/我的文件/ ./。第二大文件传输时建议加上-p参数显示进度不然你不知道传输是卡住了还是在正常进行。第三如果传输过程中断可以重新执行命令adb会覆盖已存在的文件但不会断点续传。对于特别大的文件建议先压缩再传输。还有一个容易踩的坑车机上有些目录是只读的adb push会失败。比如/system/目录在非root状态下是不可写的。如果你需要往这些目录推送文件要么车机已经root要么用adb remount重新挂载分区为可写。但adb remount在车机上不一定可用很多车机的系统分区是锁定的。在实际项目中我经常用adb pull来拉取车机的ANR日志和tombstone文件。这些文件通常在/data/anr/和/data/tombstones/目录下是分析应用崩溃和系统异常的关键资料。但这两个目录通常需要root权限才能访问如果车机没有root可以通过adb bugreport命令来生成一个完整的系统报告里面会包含这些信息。3.5 adb install与adb uninstall应用管理利器adb install和adb uninstall是应用安装和卸载命令在车载测试中用于部署测试版本和清理环境。adb install的基本用法是adb install APK路径。常用的参数有-r表示覆盖安装并保留数据-d表示允许降级安装-g表示授予所有运行时权限-t表示允许安装测试包。在车载测试中-r和-d用得最多因为测试过程中经常需要反复安装不同版本的APK。adb install -r -d -g ./test_app_v2.3.apk这个命令会覆盖安装test_app_v2.3.apk允许版本降级并自动授予所有运行时权限。对于车机上的系统应用adb install可能会失败因为系统应用的签名和普通应用不一样。这种情况下需要用adb push把APK推到/system/app/或/system/priv-app/目录下然后重启车机。adb uninstall的基本用法是adb uninstall 包名。加-k参数可以保留应用数据和缓存。在测试中有时候需要彻底清理应用环境就用adb uninstall 包名不加-k这样应用和数据都会被删除。这里有个坑车机上有些预装应用是无法卸载的adb uninstall会返回Failure。对于这些应用可以尝试用adb shell pm disable-user 包名来禁用它们效果类似于卸载但系统更新后可能会恢复。如果要彻底移除需要root权限后删除对应的APK文件。还有一个实用技巧批量安装多个APK时可以写一个循环脚本。比如for apk in ./apks/*.apk; do adb install -r -d -g $apk done这样可以一次性安装一个目录下的所有APK省去手动一个个安装的麻烦。在搭建测试环境时特别有用。4. 无线调试中那些让人抓狂的坑4.1 连接不稳定与频繁掉线的排查思路无线调试最大的问题就是连接不稳定。USB线虽然麻烦但至少连接是可靠的。无线连接受网络环境影响很大车机WiFi模块的性能、路由器的负载、甚至周围的其他无线设备都可能影响连接质量。我遇到过的掉线情况大概有这么几种。第一种是车机WiFi休眠导致的掉线。车机为了省电在屏幕关闭后可能会让WiFi模块进入低功耗模式导致adb连接断开。解决办法是在车机的开发者选项里关闭WiFi省电优化或者用adb shell svc wifi disable和adb shell svc wifi enable来重启WiFi。但更根本的办法是让车机保持充电状态因为很多车机只有在充电时才会禁用WiFi省电策略。第二种是IP地址变化导致的掉线。如果车机是通过DHCP获取IP的网络重启后IP可能会变原来的adb连接就失效了。解决办法是在路由器上给车机设置静态IP绑定或者在车机上手动配置静态IP。如果车机不支持静态IP那就每次连接前先确认车机的当前IP。第三种是adb服务端的问题。电脑上的adb服务端有时候会卡死导致所有adb命令无响应。这时候需要重启adb服务adb kill-server然后adb start-server。重启后再重新adb connect。这个操作我基本上每天都要做好几次已经成了肌肉记忆。排查连接问题的基本流程是这样的先ping车机IP确认网络通不通然后adb devices看设备状态如果设备不在列表里就重新adb connect如果设备显示offline就adb kill-server后重连如果还是不行就检查车机的adb开关是否还开着。这个流程能解决90%以上的连接问题。4.2 adb unauthorized的根因与修复adb unauthorized是无线调试中最常见也最让人头疼的问题之一。它的意思是车机没有授权这台电脑的adb连接。根本原因在于adb的授权机制。每台电脑第一次连接车机时车机会弹出一个授权对话框询问是否允许这台电脑进行调试。如果你点了“允许”电脑的公钥就会被保存到车机的/data/misc/adb/adb_keys文件里以后连接就不需要再授权了。但如果这个对话框没有弹出来或者你点了“拒绝”就会显示unauthorized。在车机上这个授权对话框经常不弹。原因可能是车机的系统UI被定制过去掉了这个弹窗也可能是车机的adb授权界面被隐藏了。遇到这种情况有几种解决办法。第一种办法是手动把电脑的公钥推送到车机。电脑的adb公钥通常在~/.android/adbkey.pubLinux/Mac或%USERPROFILE%\.android\adbkey.pubWindows。你可以把这个文件的内容追加到车机的/data/misc/adb/adb_keys文件里。但问题是/data/misc/adb/目录通常需要root权限才能写入。如果车机没有root这个办法就行不通。第二种办法是在车机上找到授权设置。有些车机在开发者选项里有一个“撤销USB调试授权”的选项点击后会清除所有已授权的电脑然后重新连接时会弹出授权对话框。如果车机上有这个选项可以试试。第三种办法是重启车机的adbd服务。用adb shell stop adbd和adb shell start adbd来重启adb守护进程有时候能触发授权对话框重新弹出。但这个命令需要车机已经授权才能执行所以只适用于之前授权过但后来失效的情况。第四种办法是检查车机的时间。adb授权机制依赖时间戳如果车机的时间和电脑的时间相差太大授权可能会失败。确保车机和电脑的时间同步可以避免这个问题。注意如果车机是工程样机或者开发板通常不会有授权限制。但如果是量产车机厂商可能会锁定adb授权这种情况下需要联系车机供应商获取解锁方式。4.3 车机重启后无线调试失效的应对车机重启后无线调试失效这是adb无线调试的机制决定的不是bug。前面说过adb tcpip 5555命令设置的是临时的TCP模式车机重启后会恢复到默认的USB模式。所以每次车机重启后你都需要重新用USB线连一次再执行adb tcpip 5555。这个限制在测试中很麻烦尤其是做自动化测试的时候车机重启是常见操作每次重启都要插线太影响效率了。有没有办法让车机重启后自动进入TCP模式呢有几种思路。第一种是在车机的启动脚本里加入setprop service.adb.tcp.port 5555和stop adbd; start adbd。这样车机每次启动时都会自动把adb切换到TCP模式。但这个操作需要修改车机的系统文件需要root权限而且不同车机的启动脚本位置不一样通用性不强。第二种思路是用车机上的自动化工具比如Tasker或车机自带的自动化应用来监听启动事件然后执行切换命令。但这个方案依赖车机上有相应的自动化工具而且执行adb命令本身也需要权限。第三种思路是在电脑端做文章。写一个脚本检测到车机USB连接后自动执行adb tcpip 5555和adb connect。这样虽然还是需要插USB线但至少不用手动敲命令了。对于固定工位的测试环境可以一直插着USB线脚本定时检查并维持TCP连接。在实际项目中我通常采用第三种方案。在测试工位上固定一根USB线连着车机电脑上跑一个后台脚本每隔30秒检查一次adb连接状态如果发现TCP连接断了就自动重连。这样即使车机重启最多30秒后无线调试就自动恢复了。4.4 多设备同时调试时的设备指定问题当同时连接多台车机时adb命令必须指定目标设备否则会报错more than one device/emulator。指定设备的方式是adb -s 序列号 命令。设备序列号在adb devices的输出里可以看到。对于无线连接的设备序列号通常是IP:端口的格式比如192.168.1.100:5555。对于USB连接的设备序列号是一串字母数字组合。在多设备环境下有几个实用技巧。第一用环境变量ANDROID_SERIAL来指定默认设备。设置export ANDROID_SERIAL192.168.1.100:5555后后续的adb命令如果不加-s参数就会默认操作这台设备。这个技巧在脚本里特别有用。第二用adb -s 序列号 命令时序列号可以用Tab键自动补全。在bash或zsh里输入adb -s然后按Tab会自动列出当前连接的所有设备序列号。第三批量操作多台设备时可以用循环for device in $(adb devices | grep -v List | awk {print $1}); do echo Processing $device adb -s $device shell getprop ro.build.version.release done这个脚本会遍历所有已连接设备分别执行命令。在做多车机对比测试时非常实用。提示如果设备列表里出现了你不认识的设备可能是之前连接过的设备残留。用adb disconnect IP:端口可以断开指定设备用adb disconnect可以断开所有无线设备。5. 把无线调试嵌入日常测试工作流5.1 常用命令的脚本化封装前面讲的5个命令如果每次都手动敲效率还是不够高。我的做法是把常用的操作封装成脚本放在电脑的PATH路径下随时调用。比如我写了一个caradb脚本封装了连接、断开、状态检查这几个操作#!/bin/bash # caradb - 车机无线调试助手 CAR_IP192.168.1.100 CAR_PORT5555 case $1 in connect) adb connect $CAR_IP:$CAR_PORT adb devices ;; disconnect) adb disconnect $CAR_IP:$CAR_PORT ;; status) adb devices -l | grep $CAR_IP ;; shell) shift adb -s $CAR_IP:$CAR_PORT shell $ ;; logcat) shift adb -s $CAR_IP:$CAR_PORT logcat $ ;; *) echo Usage: caradb {connect|disconnect|status|shell|logcat} ;; esac这样我只需要输入caradb connect就能连接车机输入caradb shell ls /sdcard/就能在车机上执行命令不用每次都敲完整的adb命令和IP地址。对于日志抓取我也写了一个脚本自动清空日志、抓取指定时长、然后保存到带时间戳的文件里#!/bin/bash # carlog - 车机日志抓取 DURATION${1:-60} CAR_IP192.168.1.100 CAR_PORT5555 TIMESTAMP$(date %Y%m%d_%H%M%S) OUTPUTlogcat_${TIMESTAMP}.txt adb -s $CAR_IP:$CAR_PORT logcat -c echo Cleared logcat buffer, capturing for ${DURATION}s... timeout $DURATION adb -s $CAR_IP:$CAR_PORT logcat -v time $OUTPUT echo Log saved to $OUTPUT这个脚本接受一个参数指定抓取时长默认60秒。执行后会自动清空日志缓冲区抓取指定时长的日志保存到文件里。在做问题复现时特别方便。5.2 无线调试在自动化测试中的角色无线调试在自动化测试中的价值比手动测试更大。因为自动化测试通常需要长时间运行USB线连接在长时间测试中容易因为接触不良或线缆松动导致中断而无线连接没有这个问题。在自动化测试框架中adb无线调试通常用于这几个环节测试前的环境准备安装APK、推送配置文件、设置系统属性、测试中的状态监控抓取日志、截图、检查应用状态、测试后的环境清理卸载APK、拉取测试报告、恢复系统设置。以Appium为例Appium连接车机的方式就是通过adb。在Appium的配置里deviceName填车机的IP和端口udid也填同样的值Appium就会通过adb无线连接到车机。这样测试脚本运行时车机可以放在任何有网络的地方不受线缆长度限制。在做车机的UI自动化测试时我经常用adb shell uiautomator dump来获取当前界面的UI层级信息。这个命令会把当前界面的控件树导出到/sdcard/window_dump.xml然后用adb pull拉取下来分析。在无线调试模式下这个操作可以远程完成不需要人工干预。还有一个自动化场景是性能测试。用adb shell dumpsys系列命令可以获取车机的CPU、内存、电量等信息。比如adb shell dumpsys meminfo 包名可以查看指定应用的内存占用adb shell dumpsys cpuinfo可以查看CPU使用率。这些数据可以定时采集形成性能趋势图。5.3 从无线调试延伸到车载以太网测试无线调试解决的是adb层面的连接问题但在车载测试中还有另一个重要的网络层面车载以太网。现在越来越多的车机支持车载以太网测试时需要验证车机的以太网通信功能。adb无线调试和车载以太网测试有什么关系关系在于很多车机的adb网络调试就是走以太网通道的。当你用adb connect连接车机时如果车机是通过以太网连接到测试网络那adb的TCP流量就是走以太网传输的。所以无线调试的稳定性在一定程度上也反映了车机以太网通道的稳定性。在做车载以太网测试时我通常会用adb来辅助验证。比如用adb shell ifconfig查看车机的网络接口状态用adb shell netstat查看网络连接用adb shell ping测试网络连通性。这些命令可以帮助快速定位是以太网物理层的问题还是上层协议的问题。如果车机支持VLAN或者特定的以太网协议还可以通过adb shell来配置和验证。比如用adb shell ip link查看网络接口用adb shell vconfig配置VLAN。这些操作在无线调试模式下都可以远程完成不需要直接接触车机硬件。5.4 无线调试的安全边界与注意事项最后说一下无线调试的安全问题。adb无线调试本质上是在网络上开放了一个调试通道如果网络环境不安全可能会被未授权的设备连接。在测试环境中建议把车机和测试电脑放在一个独立的VLAN或者独立的WiFi网络里不要和办公网络混在一起。如果测试环境里有其他人在同一个网络里他们的adb也可能连接到你的车机导致设备列表混乱。另外测试完成后记得关闭车机的adb调试开关。虽然车机重启后adb会恢复到USB模式但在不重启的情况下adb端口一直是开放的。如果车机要移交给其他人或者进入下一道工序关闭adb调试是一个好习惯。还有一点adb无线调试的通信是没有加密的。虽然adb协议本身有一些基本的认证机制但网络上的其他设备仍然可以嗅探到adb的通信内容。所以不要在无线调试模式下传输敏感数据比如账号密码或者个人隐私信息。在实际项目中我遇到过因为adb端口开放导致的安全扫描告警。安全团队扫描到测试网络里有设备开放了5555端口以为是安全漏洞。后来解释清楚是测试用的adb调试端口才解除了告警。所以如果你的测试环境有安全监控最好提前报备一下adb端口的使用。我个人在实际操作中的体会是无线调试虽然方便但不能完全替代USB调试。在车机系统崩溃、adb服务无法启动、或者需要进入fastboot/recovery模式时USB连接仍然是唯一的选择。所以我的工位上永远备着一根USB线无线调试是日常USB调试是保底。两者配合使用才能覆盖车载测试中的各种场景。 车机无线调试实战：5个核心adb命令与避坑指南
1. 车机无线调试到底解决了什么痛点做车载测试这行的朋友都清楚车机调试最烦人的一件事就是接线。早期做车机测试基本上人手一根USB线从工位拉到车机端口线短了够不着线长了绊脚稍微碰一下接触不良就掉线。更别提整车环境下的测试车机装在仪表台里面你根本不可能趴到副驾脚垫上去插线。所以当adb无线调试这个能力在车机端逐步开放之后整个测试效率的提升是肉眼可见的。adb无线调试的核心原理其实不复杂。adb本身是Android Debug Bridge的缩写是Android系统提供的一套调试桥接工具。它默认走USB通道但同时也支持通过TCP/IP协议进行网络通信。只要车机和你的电脑处在同一个局域网内就可以把adb的连接方式从USB切换到网络从而实现无线调试。这个能力对车载测试来说意义很大因为车机本质上就是一个定制化的Android设备只要它能开放adb调试权限你就能用同一套工具链去操作它。但问题在于车机不是手机。车机的系统定制程度远高于普通手机不同车机厂商对adb的开放程度、网络配置方式、端口策略都不一样。有些车机默认关闭了adb网络调试功能有些车机虽然能连上但过一会儿就断还有些车机在无线调试模式下权限会被降级。这些坑我在实际项目中都踩过所以这篇文章不只是告诉你几个命令怎么敲更重要的是把每个命令背后的逻辑、适用场景、以及可能遇到的问题讲清楚。这篇文章适合谁看如果你是刚入行车载测试的新人正在被各种线缆和连接问题折磨那这5个命令能帮你快速建立无线调试的工作流。如果你是有一定经验的测试工程师但一直用USB线做调试想切换到无线方式提高效率那文中的避坑指南能帮你少走弯路。如果你做的是车机自动化测试需要批量管理多台车机设备那无线调试更是绕不开的基础能力。下面我会围绕5个核心adb命令展开每个命令都会讲清楚它解决什么问题、怎么用、参数怎么配、以及我在实际使用中遇到的坑和应对方法。命令本身不难难的是知道什么时候用哪个命令、参数怎么调、出了问题怎么排查。2. 无线调试前的环境准备与连接建立2.1 车机端和PC端的网络前提在敲任何adb命令之前你得先确保两件事车机和电脑在同一个网络里以及车机的adb调试权限已经打开。这两件事听起来简单但实际操作中经常卡住。先说网络。车机联网的方式通常有两种一种是车机自带4G/5G模块通过移动网络上网另一种是通过WiFi连接局域网。做无线调试必须用第二种因为adb的TCP连接需要车机和电脑在同一个局域网内能互相ping通。车机用移动网络上网时你的电脑是没法直接访问到它的。具体操作上你需要让车机连接到一个和电脑相同的WiFi热点。如果测试环境里没有现成的WiFi可以用电脑开一个移动热点让车机连上来。Windows系统在“设置 - 网络和Internet - 移动热点”里可以开启热点功能把网络共享给车机。Mac系统在“系统偏好设置 - 共享 - 互联网共享”里也能做类似的事。这样车机和电脑就在同一个子网里了。连上之后你需要在车机上查到它的IP地址。不同车机的查看方式不一样常见的有几种在车机的“设置 - 关于 - 状态信息”里找IP地址或者在车机的开发者选项里查看如果车机支持终端应用也可以直接在里面输入ifconfig或ip addr来查看。拿到IP地址后先在电脑上ping一下确认网络是通的。注意有些车机的WiFi模块在连接后会进入省电模式导致网络不稳定。如果发现ping延迟很高或者丢包可以在车机的开发者选项里关闭WiFi省电优化或者让车机保持充电状态。2.2 车机端adb调试开关的开启车机的adb开关和手机不太一样。手机通常在“开发者选项”里有一个“USB调试”开关打开就行。但车机的adb开关位置五花八门有的在开发者选项里叫“ADB调试”有的叫“网络调试”还有的藏在工程模式里。常见的开启方式有这么几种。第一种是在车机设置里连续点击“版本号”或“系统版本”7次激活开发者选项然后在开发者选项里找到adb相关开关。第二种是在车机的拨号界面输入特定的工程代码进入工程模式后开启adb。第三种是通过车机上的特定应用比如某些车机自带的“调试助手”来开启。具体用哪种方式取决于你的车机型号和系统版本。这里有个经验如果你拿到的车机是已经量产版本的adb开关很可能被厂商锁定了。这种情况下你需要联系车机的系统供应商或者通过特定的工程账号来解锁。有些车机在出厂时会把adb端口设成非标准端口比如5555之外的端口号这个也需要提前确认。开启adb调试后建议在车机的开发者选项里同时打开“保持唤醒状态”和“允许模拟位置”这两个选项。前者防止车机在调试过程中休眠断连后者在某些需要模拟GPS信号的测试场景下会用到。2.3 第一次连接从USB到无线的切换环境准备好之后第一次连接建议还是先用USB线连一次。原因很简单你需要通过USB连接来授权电脑的adb密钥并且把车机的adb服务切换到TCP模式。具体步骤是这样的。先用USB线把车机连到电脑上在电脑终端里输入adb devices确认设备列表里出现了车机设备。如果显示的是unauthorized说明车机上还没有授权这台电脑你需要在车机屏幕上点击“允许USB调试”的弹窗。如果车机上没有弹窗可能是车机的adb授权界面被定制掉了这种情况需要手动把电脑的adb公钥推送到车机的/data/misc/adb/adb_keys文件里。授权成功后输入adb tcpip 5555这个命令的作用是把车机的adb服务从USB模式切换到TCP模式监听5555端口。执行成功后你就可以拔掉USB线了。然后在电脑上输入adb connect 车机IP:5555如果一切正常会显示connected to 车机IP:5555。再输入adb devices应该能看到两个设备条目一个是USB的一个是网络连接的。提示adb tcpip命令设置的端口号默认是5555但有些车机可能占用了这个端口或者厂商指定了其他端口。如果5555连不上可以试试adb tcpip 5556或其他端口然后adb connect时用对应的端口号。这里有个容易忽略的细节adb tcpip命令在车机重启后会失效车机会恢复到USB模式。所以每次车机重启后你都需要重新用USB线连一次再执行adb tcpip 5555。如果车机支持在开发者选项里直接开启“网络adb调试”那就可以跳过USB这一步直接在车机上开启网络调试然后电脑上adb connect就行。但很多车机没有这个选项所以USB切换法还是最通用的方式。3. 五个核心adb命令的实战用法3.1 adb connect与adb devices连接管理与设备识别adb connect和adb devices是无线调试的入口命令看起来简单但实际使用中有不少细节。adb connect的基本用法是adb connect IP:端口。连接成功后adb会把设备信息保存在本地的设备列表里。但这里有个问题adb的连接状态不是实时的。有时候车机已经断网了但adb devices里还显示设备在线这时候你执行任何adb命令都会卡住或者报错。所以我的习惯是在执行关键操作前先用adb devices -l看一下设备的详细状态确认设备是真的在线。adb devices的输出格式是这样的List of devices attached 192.168.1.100:5555 device如果显示的是offline说明连接建立了但设备没有响应通常是车机端的adb服务挂了需要重启车机的adb服务或者重新连接。如果显示的是unauthorized说明授权没通过需要重新授权。在实际项目中我经常需要同时连接多台车机做对比测试。这时候adb devices会列出多个设备你需要在每条adb命令后面加-s 设备序列号来指定操作哪台设备。比如adb -s 192.168.1.100:5555 shell。设备序列号就是adb devices里显示的那一列。还有一个实用技巧如果你经常需要连接同一台车机可以在电脑上写一个批处理脚本或者shell脚本把adb connect和adb devices封装进去一键完成连接和状态检查。这样每次调试前跑一下脚本就行不用手动敲命令。注意adb的默认连接超时时间是5秒如果车机响应慢可能会连接超时。可以通过设置环境变量ADB_CONNECT_TIMEOUT来延长超时时间比如设为10000毫秒。3.2 adb shell车机内部操作的万能入口adb shell是使用频率最高的命令没有之一。它的作用是让你在电脑上直接执行车机内部的shell命令相当于远程登录到车机的Linux终端。基本用法是adb shell 命令。比如adb shell ls /sdcard/可以查看车机内部存储的文件列表adb shell pm list packages可以列出车机上安装的所有应用包名adb shell dumpsys battery可以查看电池状态。这些命令在车载测试中非常常用。但adb shell在车机上有几个特殊的坑。第一个坑是权限问题。车机的adb shell默认权限通常是shell用户不是root。有些目录和文件是shell用户无权访问的比如/data/data/下的应用私有数据。如果你需要访问这些数据要么车机已经root了要么你需要用run-as命令以应用的身份来访问。比如adb shell run-as com.example.app ls /data/data/com.example.app/。第二个坑是命令兼容性。车机的Android版本和桌面Linux发行版不一样很多常用的Linux命令在车机上可能不存在或者参数不同。比如grep命令在有些车机上不支持-P参数find命令的用法也可能有差异。遇到这种情况可以先adb shell进去然后用which命令确认某个命令是否存在再用命令 --help查看支持的参数。第三个坑是中文乱码。车机上的shell环境可能没有配置UTF-8编码导致中文文件名或者中文输出显示为乱码。解决办法是在adb shell命令前加上LANGen_US.UTF-8或者直接在电脑端用adb exec-out代替adb shell来获取二进制输出。在实际测试中我经常用adb shell做这几件事查看车机的系统属性getprop、检查网络状态ifconfig或ip addr、查看当前运行的进程ps -A、以及执行车机上的特定测试脚本。这些操作在USB模式下和无线模式下完全一样但无线模式下你可以坐在工位上操作不用趴在车里。3.3 adb logcat日志抓取与问题定位adb logcat是车载测试中排查问题的核心工具。车机上的应用崩溃、系统异常、性能问题基本上都要靠logcat来定位。基本用法是adb logcat它会实时输出车机的系统日志。但直接输出所有日志信息量太大通常需要加过滤条件。常用的过滤方式有几种按标签过滤adb logcat -s TAG、按优先级过滤adb logcat *:E只显示Error及以上级别、按进程ID过滤adb logcat --pidPID。在车载测试中我常用的logcat命令组合是这样的adb logcat -v time -b main -b system -b crash logcat_$(date %Y%m%d_%H%M%S).txt这个命令的作用是把main、system、crash三个缓冲区的日志都抓下来带上时间戳保存到文件里。-v time表示日志格式包含时间信息-b指定要抓取的缓冲区。车机上的日志缓冲区通常比手机多除了标准的main、system、crash之外还有radio、events等。具体有哪些缓冲区可以用adb logcat -b all -v brief来查看。抓取日志时有个很重要的技巧先清空旧日志再抓。用adb logcat -c清空所有缓冲区然后复现问题再抓取日志。这样日志文件里只有问题复现过程中的记录排查起来效率高很多。如果不先清空日志文件里会混入大量无关的历史记录找问题就像大海捞针。还有一个坑是日志丢失。车机的日志缓冲区大小有限如果日志产生速度太快旧的日志会被覆盖。对于需要长时间抓取日志的场景建议用adb logcat -r 1024 -n 10这样的参数让logcat自动轮转日志文件每个文件1024KB最多保留10个。这样即使抓取时间很长也不会因为缓冲区溢出而丢失关键日志。提示如果车机上的logcat命令被厂商定制过参数可能不完全一样。可以先adb shell logcat --help看一下支持哪些参数。另外有些车机会把日志写到特定的文件里比如/data/log/或/sdcard/logs/这些文件也可以用adb pull拉取下来分析。3.4 adb pull与adb push文件传输的双向通道adb pull和adb push是文件传输命令在车载测试中用途很广。adb pull是把车机上的文件拉到电脑上adb push是把电脑上的文件推到车机上。基本用法是adb pull 车机路径 电脑路径和adb push 电脑路径 车机路径。比如adb pull /sdcard/logs/ ./logs/可以把车机上的日志目录拉到电脑当前目录下。在车载测试中这两个命令的典型使用场景包括拉取车机上的日志文件、推送测试APK到车机安装、推送配置文件到车机、以及拉取车机上的截图和录屏文件。这里有几个实操中总结出来的经验。第一路径中的空格和特殊字符要处理好。车机上的文件路径可能包含中文或空格这时候需要用引号把路径括起来比如adb pull /sdcard/我的文件/ ./。第二大文件传输时建议加上-p参数显示进度不然你不知道传输是卡住了还是在正常进行。第三如果传输过程中断可以重新执行命令adb会覆盖已存在的文件但不会断点续传。对于特别大的文件建议先压缩再传输。还有一个容易踩的坑车机上有些目录是只读的adb push会失败。比如/system/目录在非root状态下是不可写的。如果你需要往这些目录推送文件要么车机已经root要么用adb remount重新挂载分区为可写。但adb remount在车机上不一定可用很多车机的系统分区是锁定的。在实际项目中我经常用adb pull来拉取车机的ANR日志和tombstone文件。这些文件通常在/data/anr/和/data/tombstones/目录下是分析应用崩溃和系统异常的关键资料。但这两个目录通常需要root权限才能访问如果车机没有root可以通过adb bugreport命令来生成一个完整的系统报告里面会包含这些信息。3.5 adb install与adb uninstall应用管理利器adb install和adb uninstall是应用安装和卸载命令在车载测试中用于部署测试版本和清理环境。adb install的基本用法是adb install APK路径。常用的参数有-r表示覆盖安装并保留数据-d表示允许降级安装-g表示授予所有运行时权限-t表示允许安装测试包。在车载测试中-r和-d用得最多因为测试过程中经常需要反复安装不同版本的APK。adb install -r -d -g ./test_app_v2.3.apk这个命令会覆盖安装test_app_v2.3.apk允许版本降级并自动授予所有运行时权限。对于车机上的系统应用adb install可能会失败因为系统应用的签名和普通应用不一样。这种情况下需要用adb push把APK推到/system/app/或/system/priv-app/目录下然后重启车机。adb uninstall的基本用法是adb uninstall 包名。加-k参数可以保留应用数据和缓存。在测试中有时候需要彻底清理应用环境就用adb uninstall 包名不加-k这样应用和数据都会被删除。这里有个坑车机上有些预装应用是无法卸载的adb uninstall会返回Failure。对于这些应用可以尝试用adb shell pm disable-user 包名来禁用它们效果类似于卸载但系统更新后可能会恢复。如果要彻底移除需要root权限后删除对应的APK文件。还有一个实用技巧批量安装多个APK时可以写一个循环脚本。比如for apk in ./apks/*.apk; do adb install -r -d -g $apk done这样可以一次性安装一个目录下的所有APK省去手动一个个安装的麻烦。在搭建测试环境时特别有用。4. 无线调试中那些让人抓狂的坑4.1 连接不稳定与频繁掉线的排查思路无线调试最大的问题就是连接不稳定。USB线虽然麻烦但至少连接是可靠的。无线连接受网络环境影响很大车机WiFi模块的性能、路由器的负载、甚至周围的其他无线设备都可能影响连接质量。我遇到过的掉线情况大概有这么几种。第一种是车机WiFi休眠导致的掉线。车机为了省电在屏幕关闭后可能会让WiFi模块进入低功耗模式导致adb连接断开。解决办法是在车机的开发者选项里关闭WiFi省电优化或者用adb shell svc wifi disable和adb shell svc wifi enable来重启WiFi。但更根本的办法是让车机保持充电状态因为很多车机只有在充电时才会禁用WiFi省电策略。第二种是IP地址变化导致的掉线。如果车机是通过DHCP获取IP的网络重启后IP可能会变原来的adb连接就失效了。解决办法是在路由器上给车机设置静态IP绑定或者在车机上手动配置静态IP。如果车机不支持静态IP那就每次连接前先确认车机的当前IP。第三种是adb服务端的问题。电脑上的adb服务端有时候会卡死导致所有adb命令无响应。这时候需要重启adb服务adb kill-server然后adb start-server。重启后再重新adb connect。这个操作我基本上每天都要做好几次已经成了肌肉记忆。排查连接问题的基本流程是这样的先ping车机IP确认网络通不通然后adb devices看设备状态如果设备不在列表里就重新adb connect如果设备显示offline就adb kill-server后重连如果还是不行就检查车机的adb开关是否还开着。这个流程能解决90%以上的连接问题。4.2 adb unauthorized的根因与修复adb unauthorized是无线调试中最常见也最让人头疼的问题之一。它的意思是车机没有授权这台电脑的adb连接。根本原因在于adb的授权机制。每台电脑第一次连接车机时车机会弹出一个授权对话框询问是否允许这台电脑进行调试。如果你点了“允许”电脑的公钥就会被保存到车机的/data/misc/adb/adb_keys文件里以后连接就不需要再授权了。但如果这个对话框没有弹出来或者你点了“拒绝”就会显示unauthorized。在车机上这个授权对话框经常不弹。原因可能是车机的系统UI被定制过去掉了这个弹窗也可能是车机的adb授权界面被隐藏了。遇到这种情况有几种解决办法。第一种办法是手动把电脑的公钥推送到车机。电脑的adb公钥通常在~/.android/adbkey.pubLinux/Mac或%USERPROFILE%\.android\adbkey.pubWindows。你可以把这个文件的内容追加到车机的/data/misc/adb/adb_keys文件里。但问题是/data/misc/adb/目录通常需要root权限才能写入。如果车机没有root这个办法就行不通。第二种办法是在车机上找到授权设置。有些车机在开发者选项里有一个“撤销USB调试授权”的选项点击后会清除所有已授权的电脑然后重新连接时会弹出授权对话框。如果车机上有这个选项可以试试。第三种办法是重启车机的adbd服务。用adb shell stop adbd和adb shell start adbd来重启adb守护进程有时候能触发授权对话框重新弹出。但这个命令需要车机已经授权才能执行所以只适用于之前授权过但后来失效的情况。第四种办法是检查车机的时间。adb授权机制依赖时间戳如果车机的时间和电脑的时间相差太大授权可能会失败。确保车机和电脑的时间同步可以避免这个问题。注意如果车机是工程样机或者开发板通常不会有授权限制。但如果是量产车机厂商可能会锁定adb授权这种情况下需要联系车机供应商获取解锁方式。4.3 车机重启后无线调试失效的应对车机重启后无线调试失效这是adb无线调试的机制决定的不是bug。前面说过adb tcpip 5555命令设置的是临时的TCP模式车机重启后会恢复到默认的USB模式。所以每次车机重启后你都需要重新用USB线连一次再执行adb tcpip 5555。这个限制在测试中很麻烦尤其是做自动化测试的时候车机重启是常见操作每次重启都要插线太影响效率了。有没有办法让车机重启后自动进入TCP模式呢有几种思路。第一种是在车机的启动脚本里加入setprop service.adb.tcp.port 5555和stop adbd; start adbd。这样车机每次启动时都会自动把adb切换到TCP模式。但这个操作需要修改车机的系统文件需要root权限而且不同车机的启动脚本位置不一样通用性不强。第二种思路是用车机上的自动化工具比如Tasker或车机自带的自动化应用来监听启动事件然后执行切换命令。但这个方案依赖车机上有相应的自动化工具而且执行adb命令本身也需要权限。第三种思路是在电脑端做文章。写一个脚本检测到车机USB连接后自动执行adb tcpip 5555和adb connect。这样虽然还是需要插USB线但至少不用手动敲命令了。对于固定工位的测试环境可以一直插着USB线脚本定时检查并维持TCP连接。在实际项目中我通常采用第三种方案。在测试工位上固定一根USB线连着车机电脑上跑一个后台脚本每隔30秒检查一次adb连接状态如果发现TCP连接断了就自动重连。这样即使车机重启最多30秒后无线调试就自动恢复了。4.4 多设备同时调试时的设备指定问题当同时连接多台车机时adb命令必须指定目标设备否则会报错more than one device/emulator。指定设备的方式是adb -s 序列号 命令。设备序列号在adb devices的输出里可以看到。对于无线连接的设备序列号通常是IP:端口的格式比如192.168.1.100:5555。对于USB连接的设备序列号是一串字母数字组合。在多设备环境下有几个实用技巧。第一用环境变量ANDROID_SERIAL来指定默认设备。设置export ANDROID_SERIAL192.168.1.100:5555后后续的adb命令如果不加-s参数就会默认操作这台设备。这个技巧在脚本里特别有用。第二用adb -s 序列号 命令时序列号可以用Tab键自动补全。在bash或zsh里输入adb -s然后按Tab会自动列出当前连接的所有设备序列号。第三批量操作多台设备时可以用循环for device in $(adb devices | grep -v List | awk {print $1}); do echo Processing $device adb -s $device shell getprop ro.build.version.release done这个脚本会遍历所有已连接设备分别执行命令。在做多车机对比测试时非常实用。提示如果设备列表里出现了你不认识的设备可能是之前连接过的设备残留。用adb disconnect IP:端口可以断开指定设备用adb disconnect可以断开所有无线设备。5. 把无线调试嵌入日常测试工作流5.1 常用命令的脚本化封装前面讲的5个命令如果每次都手动敲效率还是不够高。我的做法是把常用的操作封装成脚本放在电脑的PATH路径下随时调用。比如我写了一个caradb脚本封装了连接、断开、状态检查这几个操作#!/bin/bash # caradb - 车机无线调试助手 CAR_IP192.168.1.100 CAR_PORT5555 case $1 in connect) adb connect $CAR_IP:$CAR_PORT adb devices ;; disconnect) adb disconnect $CAR_IP:$CAR_PORT ;; status) adb devices -l | grep $CAR_IP ;; shell) shift adb -s $CAR_IP:$CAR_PORT shell $ ;; logcat) shift adb -s $CAR_IP:$CAR_PORT logcat $ ;; *) echo Usage: caradb {connect|disconnect|status|shell|logcat} ;; esac这样我只需要输入caradb connect就能连接车机输入caradb shell ls /sdcard/就能在车机上执行命令不用每次都敲完整的adb命令和IP地址。对于日志抓取我也写了一个脚本自动清空日志、抓取指定时长、然后保存到带时间戳的文件里#!/bin/bash # carlog - 车机日志抓取 DURATION${1:-60} CAR_IP192.168.1.100 CAR_PORT5555 TIMESTAMP$(date %Y%m%d_%H%M%S) OUTPUTlogcat_${TIMESTAMP}.txt adb -s $CAR_IP:$CAR_PORT logcat -c echo Cleared logcat buffer, capturing for ${DURATION}s... timeout $DURATION adb -s $CAR_IP:$CAR_PORT logcat -v time $OUTPUT echo Log saved to $OUTPUT这个脚本接受一个参数指定抓取时长默认60秒。执行后会自动清空日志缓冲区抓取指定时长的日志保存到文件里。在做问题复现时特别方便。5.2 无线调试在自动化测试中的角色无线调试在自动化测试中的价值比手动测试更大。因为自动化测试通常需要长时间运行USB线连接在长时间测试中容易因为接触不良或线缆松动导致中断而无线连接没有这个问题。在自动化测试框架中adb无线调试通常用于这几个环节测试前的环境准备安装APK、推送配置文件、设置系统属性、测试中的状态监控抓取日志、截图、检查应用状态、测试后的环境清理卸载APK、拉取测试报告、恢复系统设置。以Appium为例Appium连接车机的方式就是通过adb。在Appium的配置里deviceName填车机的IP和端口udid也填同样的值Appium就会通过adb无线连接到车机。这样测试脚本运行时车机可以放在任何有网络的地方不受线缆长度限制。在做车机的UI自动化测试时我经常用adb shell uiautomator dump来获取当前界面的UI层级信息。这个命令会把当前界面的控件树导出到/sdcard/window_dump.xml然后用adb pull拉取下来分析。在无线调试模式下这个操作可以远程完成不需要人工干预。还有一个自动化场景是性能测试。用adb shell dumpsys系列命令可以获取车机的CPU、内存、电量等信息。比如adb shell dumpsys meminfo 包名可以查看指定应用的内存占用adb shell dumpsys cpuinfo可以查看CPU使用率。这些数据可以定时采集形成性能趋势图。5.3 从无线调试延伸到车载以太网测试无线调试解决的是adb层面的连接问题但在车载测试中还有另一个重要的网络层面车载以太网。现在越来越多的车机支持车载以太网测试时需要验证车机的以太网通信功能。adb无线调试和车载以太网测试有什么关系关系在于很多车机的adb网络调试就是走以太网通道的。当你用adb connect连接车机时如果车机是通过以太网连接到测试网络那adb的TCP流量就是走以太网传输的。所以无线调试的稳定性在一定程度上也反映了车机以太网通道的稳定性。在做车载以太网测试时我通常会用adb来辅助验证。比如用adb shell ifconfig查看车机的网络接口状态用adb shell netstat查看网络连接用adb shell ping测试网络连通性。这些命令可以帮助快速定位是以太网物理层的问题还是上层协议的问题。如果车机支持VLAN或者特定的以太网协议还可以通过adb shell来配置和验证。比如用adb shell ip link查看网络接口用adb shell vconfig配置VLAN。这些操作在无线调试模式下都可以远程完成不需要直接接触车机硬件。5.4 无线调试的安全边界与注意事项最后说一下无线调试的安全问题。adb无线调试本质上是在网络上开放了一个调试通道如果网络环境不安全可能会被未授权的设备连接。在测试环境中建议把车机和测试电脑放在一个独立的VLAN或者独立的WiFi网络里不要和办公网络混在一起。如果测试环境里有其他人在同一个网络里他们的adb也可能连接到你的车机导致设备列表混乱。另外测试完成后记得关闭车机的adb调试开关。虽然车机重启后adb会恢复到USB模式但在不重启的情况下adb端口一直是开放的。如果车机要移交给其他人或者进入下一道工序关闭adb调试是一个好习惯。还有一点adb无线调试的通信是没有加密的。虽然adb协议本身有一些基本的认证机制但网络上的其他设备仍然可以嗅探到adb的通信内容。所以不要在无线调试模式下传输敏感数据比如账号密码或者个人隐私信息。在实际项目中我遇到过因为adb端口开放导致的安全扫描告警。安全团队扫描到测试网络里有设备开放了5555端口以为是安全漏洞。后来解释清楚是测试用的adb调试端口才解除了告警。所以如果你的测试环境有安全监控最好提前报备一下adb端口的使用。我个人在实际操作中的体会是无线调试虽然方便但不能完全替代USB调试。在车机系统崩溃、adb服务无法启动、或者需要进入fastboot/recovery模式时USB连接仍然是唯一的选择。所以我的工位上永远备着一根USB线无线调试是日常USB调试是保底。两者配合使用才能覆盖车载测试中的各种场景。