Unix下Android调试卡壳？三步定位90%环境配置问题

　　做了五年Android自动化测试的老张上周找我吐槽，说在Unix下调试卡壳快把他逼疯了——adb connect失败、logcat没输出、NDK编译报错，三连炸直接把他下午的咖啡都喷键盘上了。我原以为他得折腾半天，结果他按我教的三步法，十分钟就定位到是环境变量PATH里混了旧版Android SDK的bin目录。这事儿让我突然想起，近两个月帮三个团队解决类似问题，发现90%的卡壳真就卡在环境配置上，而且这破事儿还有套路可循。

　　第一步先查adb版本。上周三下午，我在客户机房帮他们排查问题，空调外机嗡嗡响得像拖拉机，运维小哥接了个电话说“网络波动”，结果我一敲adb version，好家伙，终端卡了三秒才蹦出“1.0.32”——这版本比他们项目里用的Android 12还老两代。我直接让他们去官网下最新版，换完再试，adb connect立马通了。这招我敢打包票，但凡adb版本低于项目适配的Android版本，十有八九会卡在连接阶段，尤其是用了自定义ROM的机器。

　　第二步看logcat权限。上季度末帮金融团队调支付流程，他们的测试机插着USB线，logcat却死活没输出。我蹲在工位前盯着屏幕，发现他们把logcat命令写成了“adb logcat -c && adb logcat”，结果-c清完缓存后，第二个logcat因为没加-s参数过滤，被系统权限卡住了。我让他们改写成“adb logcat -s Payment:V :S”，再试，支付日志哗哗往外冒。这时候运维小李凑过来看，说“我们之前也遇到过，是selinux没关”，结果我一查，他们的测试机selinux早关了——这锅甩得比外卖小哥还快。

　　第三步揪NDK路径。上周五下午，我在茶水间啃三明治，开发小王举着笔记本冲进来：“快看！编译报错说找不到clang！”我瞥了眼屏幕，错误信息里混着“/opt/android-ndk-r20/toolchains/llvm/prebuilt/linux-x86_64/bin/clang: No such file or directory”。我让他敲“which clang”，终端显示路径是r23的，但项目里配置的是r20。我原以为得改CMakeLists.txt，结果发现是环境变量ANDROID_NDK_HOME没更新，还是指向r20的旧目录。改完再编译，顺利通过——这时候窗外突然下雨，雨点砸在玻璃上的声音，比编译成功的提示音还响。

　　这三步看着简单，但真能筛掉90%的环境问题。剩下10%才是硬骨头——比如上周遇到的，adb连接成功但设备列表不显示，查了半天发现是udev规则没写对；或者logcat有输出但时间戳乱跳，原来是系统时区没同步。这些破事儿得靠经验攒，但至少前90%能用这三步快速定位，省得在无关配置上浪费时间。

　　我见过最离谱的案例，是某个团队把JDK、Android SDK、NDK全装在/usr/local下，结果权限混乱，adb连不上，logcat没输出，编译还报错。他们折腾了三天，最后发现是/usr/local的权限被运维改过，普通用户没读写权限。我让他们把工具链移到/opt下，重新配环境变量，问题全解决——这团队后来还给我买了杯奶茶，说“早知道早找你，省了三天加班”。

文章配图，仅供参考

（编辑：站长网）

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