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

　　去年七月那会儿，我原以为给Android跑个Unix环境调试能有多难？结果好几台机器卡得死死的，adb logcat刷出来的全是"permission denied"，开发那边催得比催命鬼还急——"你到底能不能修啊？我这边版本要上线了！" 我盯着屏幕上的"Failed to connect to the device"，泡面在旁边放凉了都没顾上吃，机房空调吹得我后颈发凉，手机在裤兜里震个不停，不用看都知道是开发又发消息了。

　　其实这问题我见过——环境变量没配全、权限没给够、库文件版本冲突，90%的卡壳都逃不开这三样。但那天特别邪门，我查`$PATH`，`echo $ANDROID_HOME`，连`ls -l /dev/bus/usb`都看了，该有的都有，不该有的也没乱加。开发在旁边阴阳怪气："你们运维不是最懂环境吗？怎么连个调试都搞不定？" 我火"噌"一下就上来了，指着屏幕说："你行你上啊！这机器昨天还好好的，今天突然就抽风！" 说完又后悔——毕竟确实是我负责的环境。

　　后来我学乖了，先查`adb version`。结果你猜怎么着？三台机器里两台装的是不同版本的adb，一个28.0.0，一个31.0.3，混着用能不出问题吗？我原以为`which adb`能直接定位，结果`/usr/local/bin/adb`和`/home/user/.android-sdk/platform-tools/adb`同时存在，系统优先用了旧版。我直接`rm -f /usr/local/bin/adb`，然后从官方包重新装，`chmod +x`一顿操作，开发那边突然喊："动了动了！logcat有输出了！" 我松了口气，转头看见窗外天快亮了，机房的灯照得屏幕反光，眼睛酸得直掉泪。

　　但问题没完。第二天又卡壳，这次是`libstdc++.so.6`版本冲突。开发说："我明明在`LD_LIBRARY_PATH`里加了路径，怎么还报错？" 我查`ldd $(which adb)`，发现它偷偷调用了系统自带的旧库，根本没走我们指定的路径。我原以为`export LD_LIBRARY_PATH=/path/to/libs:$LD_LIBRARY_PATH`就能解决，结果发现这变量在`sudo`下不生效——因为`sudo`默认会重置环境变量！最后我直接在`/etc/sudoers`里加了`Defaults env_keep += "LD_LIBRARY_PATH"`，才算是彻底搞定。开发在群里发了个"666"，我回了个"下次别催这么急"，其实心里挺得意——这招他肯定不知道。

　　其实最坑的是权限问题。有一次`adb devices`能识别设备，但`adb shell`直接卡死。我查`dmesg`，全是`usb 1-1: device descriptor read/64, error -71`。开发说："是不是线坏了？" 我换了好几根线，甚至换了台机器试，还是不行。后来我无意间看到`lsusb`的输出里，设备ID是`18d1:4ee2`，但`/etc/udev/rules.d/51-android.rules`里只配了`18d1:d002`。我直接`vim`改了规则文件，`sudo reload udev`，再插设备——瞬间识别！开发在旁边看得目瞪口呆："这也能行？" 我冷笑："你以为运维就只会重启？" 其实我心里也在犯嘀咕——这规则文件谁配的？怎么漏了这么关键的ID？

文章配图，仅供参考

　　其实这些破事儿，90%都能靠三步解决：先查版本（`adb version`、`ldd`、`lsusb`），再查路径（`which`、`echo $PATH`、`LD_LIBRARY_PATH`），最后查权限（`ls -l`、`udev rules`、`sudoers`）。但为什么还是有人搞不定？因为大家都太自信了——开发觉得"我代码没问题，肯定是环境问题"，运维觉得"我环境配好了，肯定是开发问题"。结果两边互相甩锅，问题越拖越久。其实优胜劣汰就是这么来的——谁先放下架子，谁就能先解决问题。

　　现在我再遇到Unix下Android调试卡壳，第一反应就是查这三样。开发再催，我就说："别急，先让我看看`adb version`。" 他们要是敢说"这有什么关系"，我就把之前的案例甩给他们看——保证他们立马闭嘴。其实这事本来能避免，要是大家都能多查一步、多想一层，哪用得着熬到凌晨三点半？不过话说回来，运维这活儿，不就是这样吗？问题永远解决不完，但解决一个，就少一个——至少，下次能少熬点夜。

（编辑：站长网）

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