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

文章配图，仅供参考

　　我原以为又是SELinux在作妖——毕竟这玩意儿在Unix下搞Android调试最容易背锅——结果`getenforce`一看，Permissive模式，排除了。那会儿机房空调坏了，冷得我直搓手，泡面泡到一半就凉了，开发还隔着屏幕喊“再不解决我们今晚别想下班”，我直接怼回去：“你们代码里有没有硬编码路径？有没有依赖特定库版本？”他愣了两秒，说“应该没有吧”，我差点把键盘摔了——这他妈叫“应该”？

　　后来实在没辙，我翻了半天`strace`的输出，发现adb进程在访问`/data/local/tmp`的时候卡了半秒，接着就报错。这目录权限没问题啊？我顺手`ls -la`看了眼，发现有个隐藏文件`.android_secure`，权限是600，所有者是root——可adb是跑在shell用户下的！我原以为这文件是系统自动生成的，结果开发说“哦，那是我们之前测试用的安全存储，忘了删了”。我直接把那文件删了，adb瞬间活过来了，开发那边欢呼“牛逼”，我盯着屏幕上的“Permission denied”日志，心想这他妈也能算“牛逼”？

　　但这事儿没完。第二天又卡壳了，这次是`adb push`卡在99%不动。我查`dmesg`，全是“NFS mount failed”的报错——原来这机器挂载了NFS共享目录，而Android调试默认会把临时文件往`/data/local/tmp`扔，结果NFS服务器那边突然抽风，挂载断了。我原以为NFS挂载断了adb会报错，结果它就这么卡着，像个傻子似的等超时。我直接`umount /data/local/tmp`（其实应该先`umount -l`，但当时急得没多想），然后重新挂载本地目录，adb又活了。开发那边又喊“666”，我回了个“6你妹”，转头看窗外，天都快亮了。

　　第三次卡壳更离谱——`adb shell`能连上，但执行任何命令都报“Permission denied”。我查`ps aux`，发现adbd进程是root跑的，可`/data/local/tmp`的权限是777，理论上不该有问题。我试了`adb kill-server`、`adb start-server`，没用；试了重启adbd，也没用。最后我翻到一篇十年前的博客，说Unix下Android调试有时候会因为`/dev/android_adb`设备节点权限不对卡壳——我`ls -l /dev/android_adb`一看，权限是600，所有者是root，而adb需要666。我`chmod 666 /dev/android_adb`，再试`adb shell`，成了。开发那边又炸锅了，我直接关掉微信窗口——爱咋咋地，老子要睡觉。

　　其实这三步——查隐藏文件、查挂载点、查设备节点——都不是什么高深操作，但问题就出在“你以为没问题的地方，往往藏着最傻逼的坑”。比如那个`.android_secure`文件，谁会想到测试用的安全存储会影响调试？比如NFS挂载断了，adb居然不报错而是卡死？比如设备节点权限不对，连`strace`都抓不到关键错误？这些坑，没有十年八年的运维经验，根本想不到。

　　我后来跟开发吵了一架——他们总觉得“环境配置是运维的事，代码没问题就行”，可实际上，代码里硬编码路径、依赖特定库版本、乱用安全存储，这些不都是“代码问题”？运维要背锅，但开发也不能当甩手掌柜。那天晚上我老婆打电话来，问我几点回家，我说“快了快了”，结果挂掉电话又折腾了两小时——她后来跟我抱怨“你比总统还忙”，我无言以对。

　　现在回头看，这三步能揪出顽疾，说白了就是“优胜劣汰”——把所有可能出问题的点列出来，一个一个试，试到对的为止。没有捷径，没有灵丹妙药，只有耐心和经验。我原以为运维就是“备份、监控、迁机器”，结果发现，真正的运维是“在屎山里找金子”——你得知道哪坨屎可能藏着金子，哪坨屎只是纯屎。

　　这事儿本来能避免——如果开发不乱留测试文件，如果NFS服务器稳定点，如果设备节点权限默认设对。但现实是，这些“如果”都不存在。所以下次再遇到Unix下Android调试卡壳，别慌，先查隐藏文件，再查挂载点，最后查设备节点——这三步够你怼死大部分“环境配置顽疾”了。至于剩下的？呵，那得看运气了。

（编辑：站长网）

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