Unix下Android调试卡壳？三步揪出90%环境顽疾

　　去年一月，凌晨三点十七分，群里突然@全员——不是告警BOT，是老张自己顶着个“[紧急]adb devices空列表”的标题手敲的。我正蹲在nginx access log里扒那个熟得不能再熟的IP段（10.244.17.198），上头刚扫完三台宿主机的crontab，发现其中一台多了个叫“_sync_log.sh”的文件，权限644，mtime是昨天下午四点零九分，创建者uid 1001，不是root也不是jenkins——但也没动它。

文章配图，仅供参考

　　我原以为又是udev规则没reload，结果连udev都还没碰，就先在dmesg里撞见那句“usb 1-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3”。熟。太熟了。三年前在苏州园区那台跑着Kali的ThinkPad上，这串字符后面永远跟着“configuration #1 chosen from 1 choice”，再然后adb就认人。可这次它卡在“strings”后面，不动了。真不动，不是timeout，是log停在那里，像被掐了脖子。

　　第一件事：别碰adb kill-server。真有人信这个能清环境？上个月王磊在devops频道里截图show出他的~/.android/adbkey.pub最后修改时间是二〇二三年十一月八日，而他机器上adb version返回1.0.41——你猜他debug.keystore是不是还躺在$HOME/.android/debug.keystore没换过？不换也行，但你得确认它对应的private key根本没被chmod 600过以外的任何操作。我们组小林试过用sha256sum比对两个目录下所有.pem，发现build-tools/33.0.2/platform-tools/adb和sdk/platform-tools/adb md5居然差三个字节。他说是符号链接搞的鬼，我没拆开看，因为当时我在盯那个10.244.17.198的反向DNS解析——它指向一个叫“jira-stage-mirror”的CNAME，但实际解析到的A记录归属是aws-us-east-2。没报错，也没告警，just there。

　　第二件事：检查udev rules。但别直接抄网上那套SUBSYSTEM=="usb", ATTR{idVendor}=="0bb4", MODE="0666"……你敢这么干？vendor ID写死？去年十月深圳那批小米测试机批量进厂时idVendor是2717，华为mate50 Pro是12d1，vivo X90s是22d9——你规则里只写了0bb4？那恭喜，剩下四分之三设备进来就是灰色图标。我们线上跑的rules是按product name做模糊匹配的，比如ATTRS{product}==".Android."，但必须加GOTO，不然遇到Type-C口插在Dock上会误触发——这事发生过两次，一次是财务部新来的实习生把手机充在会议平板USB口，结果把整条Jenkins pipeline里adb shell echo $USER的输出全替成“root”，因为Dock驱动加载时顺带载入了某个厂商闭源usb gadget模块，把整个usb subsystem给晃了一下。这事我说不准是不是跟后来那个莫名多出来的_svn_hook.bak有关，但它确实出现在同一台机器的/opt/backup/里。

　　第三件事：查strace -f -e trace=connect,bind,openat adb devices。别用-full。你只需要看到它到底连谁、连哪、连失败几次。我昨天亲眼看见它在openat(AT_FDCWD, "/etc/hosts", O_RDONLY|O_CLOEXEC)之后，立刻connect(3, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("127.0.0.53")}, 16)……停住五秒，然后重试三次，最后一次改连8.8.8.8。但它没发DNS query，只是反复connect。后来才发现是systemd-resolved监听在127.0.0.53，而adb根本不认这个地址——它只认传统的/etc/resolv.conf。这个我敢打包票，因为改完resolv.conf把它改成nameserver 1.1.1.1后，adb devices秒出列表，但连上之后logcat第一条是“E/libc: Access denied finding property 'ro.serialno'”。啧，又来了。

　　对了，上周溯源那个失陷的CI节点，线索断在gitlab-runner执行shell executor时的一个curl调用——它没走proxy，却绕过了WAF白名单，最后在/var/log/gitlab-runner/current里找到一句“Using /usr/bin/adb as adb binary”，路径没错，可sha256sum和官方包对不上。删掉重装？不行，脚本依赖它硬编码的路径。重软链？行，但第二天发现adb forward tcp:8080 tcp:8080绑不了，netstat -tuln|grep 8080全是ESTABLISHED，没LISTEN。这事没往下跟，因为当天下午客户打电话说API响应延迟从十八秒跳到三百七十二，我转头去扒flask app的日志buffer环了。

　　所以别跟我说什么“升级platform-tools就行”。上个月我帮杭州那边调一个Flutter Release版闪退问题，最后发现是他们本地bashrc里export ADB_VENDOR_KEYS="/dev/null"——对，就是/dev/null，不是空字符串，是真正的设备节点。adb认得出来，还认真往里写了十六进制密钥头，然后吐出一句“error: could not read keys”。没人看logcat里的这句，都在盯着Application Crash Report。这事让我想起二〇二一年在合肥那个项目，debug时所有设备都显示“unauthorized”，最后发现是团队共用一台mac mini，而钥匙被某人rm -rf ~/.android/后又用scp拉了个别人机器上的adbkey过来——pub key配不上priv key，但adb devices照样显示device，就是不让你install。这种坑，三步真揪不出，得看/dev/log/adb-auth.log，可惜Android没这玩意。

　　安全是成本不是收入——这话我贴在工位隔板上快两年了。但你要真把ADB调试当安全成本来管，就得接受它有时候就是卡在udev rule第十七行注释后的空格数上。今晚回去，我把那个_svn_hook.bak拷出来hexdump -C前两百字节，要是开头是7f454c46（ELF魔数），我就把它挪进/tmp/.sysinit，别的先不管。

（编辑：站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!