简介：一份 ADB（Android Debug Bridge）工具的完整源码包，面向嵌入式开发、驱动调试、系统移植等场景的工程师，也适合有交叉编译基础的中高级开发者。官方预编译版本常受架构与运行环境限制，而这份源码可直接拉取后依据 README 交叉编译，作者已在 ARM 机器上完成编译，并验证生成的 ADB 工具可正常使用。压缩包约 41.9MB，格式为 tgz；上游未提供文件总数与类型明细，因此不赘述，包内以源码文件为主，附带编译说明与构建脚本，便于复现整个适配过程。已有 179 人学习浏览，说明该方法对需要自行移植 ADB 的团队有实际参考价值。借助此包，能跳过从零搭建交叉工具链的繁琐环节，获得一条已在 ARM 平台跑通的构建路径，降低向其他架构迁移时的排错成本，大幅提升调试工具的部署效率。
1. 从 arm_adb-master_default.tgz 说起：为什么 ARM 设备的调试要从一个压缩包开始
一台 ARM 设备到你手上，配套调试包经常就是 arm_adb-master_default.tgz 这样一份 tar 压缩档：arm 指目标架构，adb 说明包内是 Android 调试桥相关组件，master 和 default 分别是分支与构建配置标记，tgz 只是打包格式，不是安装程序。这份文件解决的实际问题是：盒子、车载中控、开发板这类设备往往没有显示器也没有键盘，你需要在最小依赖下完成文件推送、shell 脚本执行、logcat 抓取和应用安装禁用。适合做嵌入式 Linux、Android 系统定制和盒子类产品调测的工程师。我一般建议先别急着解压，把包结构、目标机架构和 adb 的角色关系理清，后面每一步才不返工。
2. 解包前先读包：tar 清单、file 命令与 ARM 架构识别
2.1 先列清单再落盘：一条 tar 命令看出包的类型
很多人拿到 tgz 的第一反应是tar -xzf解压到当前目录，然后面对一屏文件不知所措。我一般先用只读参数把包内容列一遍，判断这是预编译产物还是源码包：
# -t 只列清单不落盘，避免解压出不期望的文件污染目录 tar -tzf arm_adb-master_default.tgz | head -50 # 统计文件后缀分布，快速判断包内是源码还是二进制 tar -tzf arm_adb-master_default.tgz | awk -F. '{print $NF}' | sort | uniq -c | sort -rn | head -10第一条命令里，-t是 list 模式，-z表示 gzip 压缩，head -50限制输出量，避免大包刷屏。第二条命令按点号切分文件名后缀做频次统计，主要为了区分三类结果：大量.c、.cpp、.h说明是源码包，下一步要先交叉编译；大量.so、.bin是预编译产物，解压即用；只有无后缀的adb、adbd是纯单文件二进制。这一步决定了后续完全不同的两条路径，值得花十秒看清楚。
2.2 用 uname -m 与 file 双重确认目标机架构
包名里的 arm 只是粗粒度，armv7 和 aarch64 的 adb 二进制不能互换，强行运行只会得到一条 "Exec format error"。先在目标设备上确认运行时架构，再在 PC 上检查包内二进制的编译目标：
# 在目标 ARM 设备（Android shell 或嵌入式 Linux）上执行 uname -m # 常见输出 armv7l、aarch64，个别为 armv8l # 在 PC 上检查包内二进制属于哪种架构 file arm_adb-master_default/adb # 动态链接时额外查看依赖库，静态链接时此步可跳过 ldd arm_adb-master_default/adb 2>&1 | headfile输出里看到 "ELF 32-bit LSB executable, ARM, EABI5" 就是 32 位 ARM，"ELF 64-bit LSB executable, ARM aarch64" 就是 64 位 ARM。ldd列出的依赖如果在目标机缺失，运行时就会报 "No such file or directory"，这是动态链接 adb 最常见也最隐蔽的坑。
| uname -m 输出 | 常见叫法 | 调试注意点 |
|---|---|---|
| armv7l / armv6l | 32 位 ARM（ARMv7/ARMv6） | 对应 armeabi-v7a 构建，区分软浮点和硬浮点 |
| aarch64 | 64 位 ARM（ARMv8 及以后） | 现代盒子、车机的主流架构，对应 arm64-v8a |
| armv8l | 用户态 32 位、内核 64 位 | 按 32 位构建处理 |
| x86_64 | x86 主机跑的 ARM 模拟镜像 | VMware 里常见，行为与真机有差异 |
这里有个容易混淆的点：包名写 arm，不代表里面所有文件都是同一架构。预编译包里混入 x86 的 adb 或 so 是常见的打包事故，所以file检查的是具体文件，不是包名。
2.3 ARM 编译器与 adb 工具链的区别
ARM 调试圈里，工具链混淆是高频问题。你搜 "arm compiler 5.06u7 download" 这类词，得到的通常是 Keil MDK / DS-5 里编译裸机固件的 ARMCC 编译器，输出 axf、bin 固件，跟 adb 调试链路没有关系。如果arm_adb-master_default.tgz里只有 adb 相关组件，就不需要装任何编译器；如果包内是源码，才需要arm-linux-gnueabihf-gcc（32 位）或aarch64-linux-gnu-gcc（64 位）做交叉编译。企业内部常说的"嵌入式 6.22 的 arm 编译器"也是编译器版本号，不参与 adb 运行。
我建议构建 adb 时选静态链接。目标机的 libc 和依赖库环境往往与构建机不一致，静态链接的 adb 是一个单文件，解压后直接运行，省去一堆ldd排查。代价是体积大几百 KB，在调试场景里完全可接受。
3. 在 ARM 设备上部署 adb 环境：解压、PATH 配置与服务端拉起
3.1 解压目录的选择与挂载权限检查
Android 系统上首选/data/local/tmp，嵌入式 Linux 上用/opt/adb或/usr/local/bin。这个选择不是随手定的，而是跟分区挂载权限直接相关：
# Android 设备，shell 有写权限时 mkdir -p /data/local/tmp/adb tar -xzf arm_adb-master_default.tgz -C /data/local/tmp/adb # 嵌入式 Linux 设备 mkdir -p /opt/adb tar -xzf arm_adb-master_default.tgz -C /opt/adb-C指定解压目标目录，先mkdir -p是为了防止目标目录不存在导致解压失败。解压前执行一下mount | grep 目标分区，如果看到noexec字样就换目录，否则后面运行 adb 会报 Permission denied，而文件权限明明是对的。这类问题在国产盒子和车机上很常见，检查优先级应该排在权限排查之前。
提示：
noexec是安全加固的常规配置，不要尝试用mount -o remount,exec强行改挂载参数，产品固件重启后改动会丢失，而且可能触发系统完整性校验。
3.2 设置 PATH 与 adb 的 -s / -H / -P 参数
部署完成后的第一件事是让 shell 能找到这个可执行文件：
# 临时加入 PATH，当前 shell 会话生效 export PATH=/data/local/tmp/adb:$PATH # 验证版本，能打印出版本号说明可执行文件已就绪 adb versionadb 本身是 C/S 架构：命令行客户端（client）、本机常驻服务（server，监听 5037 端口）、设备端守护进程（adbd）。tgz 包里如果三件套都齐，就能在 ARM 设备本地起 client 和 server，不依赖 PC；如果只有 adb client，那它只能作为 PC 端工具的补充。Windows 上常见的 "15 seconds adb installer" 是驱动一键安装工具，和这里的 tgz 部署是两码事，别混在一起。
| 参数 | 作用 | 典型用法 |
|---|---|---|
-s 序列号 | 指定目标设备，多设备时必用 | adb -s 192.168.1.10:5555 shell |
-H host | 指定 adb server 所在主机 | adb -H 10.0.0.2 shell |
-P port | 指定 server 端口，默认 5037 | adb -P 5039 shell |
-H和-P在车载和 CI 场景里用得很多：把 adb server 部署在服务器上，多个执行机通过-H连过去，避免每台机器都起一个 server 导致端口冲突。
3.3 adb devices 识别、unauthorized 与系统级校验码
部署完先跑adb devices，看到unauthorized是最常见的现场。这个状态的本质是 RSA 密钥配对没有完成：
# 查看设备状态，unauthorized / device / offline 三种状态一眼可见 adb devices -l # 删除本机已保存的授权 key，重新配对 rm -f ~/.android/adbkey ~/.android/adbkey.pub adb kill-server && adb start-server adb devices原理是这样的：客户端首次连接时把~/.android/adbkey.pub公钥发给设备端 adbd，adbd 把它写进/data/misc/adb/adb_keys。如果设备上曾经拒绝过这个 key，或者 key 已过期，就会一直停在 unauthorized。删掉本机 key 后重连，设备端会再次弹确认框；车机、电视没有弹窗，需要去系统设置里找"允许 USB 调试"开关。
部分定制设备会在 adb key 之上做二次动态校验码，本质是产品策略，命令行层面能做的只有清理 key 重新申请，设备设置页没有授权入口时不要硬绕。还有一类盒子和电视的开发者选项里，"ADB 调试"开关会定时失效，这是 adbd 会话被系统回收，自动化通道应该做重连机制，而不是追求"永久打开"。设备在 fastboot 或 recovery 模式下adb devices也看不到，那是另一个协议域，后面单独说。
4. 实战两组高频命令：adb shell 脚本执行与 logcat 抓取
4.1 执行设备内 sh 脚本的完整链路
日常调试里最常见的操作就是执行设备侧脚本，比如adb shell sh /storage/emulated/0/android/data/com.omarea.vtools/up.sh这种形式。注意这里必须给整条远端命令加引号：
# 执行外部存储上的脚本，整体加引号防止本地 shell 先解析 adb shell "sh /storage/emulated/0/android/data/com.omarea.vtools/up.sh"逐段拆解：adb shell进入设备端 shell；sh明确指定解释器，避免脚本没有 shebang 时执行失败；路径指向 Android 外部存储，/storage/emulated/0是模拟外部存储的挂载点。引号的作用很关键——不加引号时，如果路径里有空格，或者脚本里有>、|这类重定向符号，本地 shell 会先处理掉，等到了设备端命令已经被拆得面目全非。
4.1.1 提权与脚本内路径问题
脚本要写/system或/vendor分区时，权限会立刻挡路。处理方式取决于固件类型：
# userdebug/eng 固件：adbd 直接以 root 重启 adb root # 正式固件：脚本内部或外部用 su 提权 adb shell "su -c 'sh /data/local/tmp/deploy.sh'"su -c的引号嵌套有个固定套路：外层双引号交给本地 shell，内层单引号保护远端命令，顺序不能反。常见失败三件套按频率排列：第一是sh: can't open，路径不存在或拼错；第二是permission denied，脚本没有执行权限，或者所在分区挂了 noexec；第三是Read-only file system，分区只读，需要 remount。
# userdebug 固件可用，正式固件通常被禁用 adb root && adb remount提示：正式固件上不要用
adb remount强行改分区。产品固件重启后改动丢失，而且可能触发 dm-verity 完整性校验，直接把系统锁进 bootloop。
4.1.2 脚本内容里常见的网络策略
这类设备侧脚本里经常顺带做应用联网管控，实现方式一般是 iptables 的 owner 匹配。按应用 uid 做限制是 Android 上禁网的惯用手段：
# 丢弃 uid 10123 的所有对外连接，效果持续到重启前 iptables -I OUTPUT -m owner --uid-owner 10123 -j DROP-I插入到规则链头部，保证优先生效；-m owner加载 owner 模块按 uid 匹配；-j DROP丢弃数据包。注意这条规则不持久，重启后需要由 init 脚本或应用自身重新写入。排查网络问题时记得先iptables -L OUTPUT -n -v看一眼规则列表，很多"设备突然连不上 adb"的现场其实是策略脚本把 5555 端口或 adb 连接 uid 给丢了。
4.2 logcat 抓取：buffer 选择与参数过滤
本地复现不了的问题，全靠 logcat 现场抓取。给一组生产环境常用的组合：
# 带线程时间戳，同时收 main 和 system 两个 buffer，落盘 adb logcat -v threadtime -b main -b system > bug.log 2>&1 # 只看某个 tag 且级别不低于 Info adb logcat -v time -s Vtools:I *:S # 调大环形缓冲区，防止日志被冲掉 adb logcat -G 256M-v threadtime输出线程 ID 和毫秒时间戳，是排查时序问题的标配；-b可以重复指定多个 buffer，-b main -b system就同时抓两层；-s Vtools:I *:S是静默模式的简写，只看 Vtools 的 Info 以上级别，其余全部丢弃。-G 256M把 logd 环形缓冲区调到 256MB，适合长时间压测场景。
| buffer 名 | 内容 | 什么时候用 |
|---|---|---|
| main | 应用层 stdout/stderr、普通 log | 默认场景 |
| system | 系统服务日志 | 服务崩溃、权限问题 |
| crash | Java 崩溃栈 | 空指针、ANR、JNI 异常 |
| events | 事件日志（am、pm、net） | 开机流程、组件生命周期异常 |
现场抓取时我一般先全量落盘，回到工位再过滤，避免在设备上做二次筛选丢现场：
# 先抓全量 crash buffer，再本地过滤关键字 adb logcat -v threadtime -b crash > crash.log 2>&1 grep -E "FATAL|AndroidRuntime" crash.log | tail -50native 库崩溃时，"dlopen failed" 这行字会出现在 crash buffer 或 logcat 主 buffer 里，配合/data/tombstone目录下的 tombstone 文件一起看，基本能定位到具体 so。
5. 进阶排查：fastboot 回连、.so 迁移校验与错误码速查
5.1 fastboot 阶段拿不到 adb 设备是正常的
设备进入 bootloader 后，用户态 adbd 还没起来，adb 协议自然不存在。此时adb devices必然是空的，要用 fastboot 协议对话：
# fastboot 阶段用 fastboot 命令，别等 adb devices fastboot devices fastboot reboot红米 K50 这类机型网上大量"fastboot 连不上"的求助帖，排查下来多半是数据线不支持数据传输，或者 USB 驱动没装对，而不是设备问题。如果你是在 VMware 里跑 ARM 镜像做调试，fastboot 阶段通常没有可用的 USB 直通，优先走网络 adb 更现实。
5.2 x86 到 ARM 的 .so 迁移怎样验证
.so从 x86 迁移到 ARM 的典型错误不是编译不过，而是推到设备后运行时报dlopen failed。最直接的验证是看 ELF 头：
# 在 PC 上看本地 so 的机器类型 readelf -h libfoo.so | grep Machine # 推到设备后做完整性校验 adb push libfoo.so /data/local/tmp/ adb shell "md5sum /data/local/tmp/libfoo.so"readelf -h输出里Machine: ARM或AArch64才符合 ARM 设备预期，看到Intel 80386或X86-64说明产物本身就是 x86 的，改文件后缀没用。push 完成后用md5sum与本地编译产物比对，能排除传输损坏和推错文件两个低级问题。APK 场景里，so 要按 abi 目录分放：arm64-v8a、armeabi-v7a各放各的，同名 so 由系统按设备架构择优加载，目录放错比编译错更难发现。
| 错误提示片段 | 原因 | 处理 |
|---|---|---|
| is for EM_X86_64 | so 还是 x86 产物 | 用交叉编译器重编 |
| only position independent executables (PIE) | 链接参数缺-fPIC | Android 5.0+ 强制 PIE |
| cannot locate symbol | 依赖的 so 没同步迁移 | 用readelf -d查看 NEEDED 清单 |
| dlopen failed: library not found | 依赖路径不对 | 检查LD_LIBRARY_PATH或 so 放置目录 |
5.3 adb 错误提示速查
| 提示 | 原因 | 处理 |
|---|---|---|
| adb: not found | PATH 未配置或包内无该文件 | 检查 PATH，或./adb绝对路径调用 |
| server version ... doesn't match | client 与 server 版本冲突 | adb kill-server后重启 server |
| unauthorized | RSA 配对未完成或 key 被清 | 删~/.android/adbkey后重连，设备端确认 |
| device offline | adbd 保活失败或网络通道断了 | 重新插拔、重启 adbd，检查 iptables 是否挡了 5037/5555 |
| insufficient permissions for device | Linux 下 udev 权限不足 | 加 udev 规则或sudo运行 adb |
adb 的错误提示通常不告诉你根因，只告诉你现象。比如device offline在车机上有一半原因是车载系统休眠策略把 USB 口断电了，另一半是网络 adb 的 5555 端口被脚本策略塞住。按表格顺序排查，比反复插拔有效率。把md5sum校验写进你的部署脚本固定步骤里，它能挡住大部分"在你那儿好的，到我这儿不行"的迁移返工，这比任何参数调优都更省时间。
本文还有配套的精品资源，点击获取
