简介这是一款面向Android开发者、测试工程师及手机维修/刷机用户的ADB工具整合包将Android Debug Bridge常用功能集中打包便于快速连接USB或无线设备执行文件推送与拉取、Shell命令、安装卸载应用、logcat日志抓取、模拟点击与滑动等操作也可在忘记锁屏密码时通过清除数据等命令恢复设备满足日常调试与应急解锁的双重需求。压缩包体积约1.88MB包含23个文件其中exe为可执行核心程序bat为便捷批处理脚本dll为运行库txt与properties则为说明和配置类文件整体轻量、结构清楚适合入门用户直接解压使用。目前已有19047人学习使用热度不错。包内既有基础调试命令也有针对常见操作封装的辅助脚本免去逐一配置依赖与路径的麻烦开箱即用能帮助使用者快速建立Android调试环境提升设备管理、应用测试和故障排查的效率。1. ADB工具包是什么为什么调试安卓离不开它上周同事拿一台安卓平板找我说系统不定时闪退想抓日志又不知道在哪看。我给他一份 adb工具包解压后连上数据线一条 adb logcat -c 清空、一条 adb logcat 挂着复现崩溃堆栈就出来了。所谓 adb工具包就是指 Android 官方的 Platform Tools 命令行集合其中核心是 adbAndroid Debug Bridge附带 fastboot 等下装工具。它解决的是电脑和安卓设备之间的“桥接”装应用、传文件、跑 shell 命令、抓日志、模拟点击全都靠它。适合做 App 开发、测试、系统定制和小型运维的人不需要完整下载几个 GB 的 Android Studio一个小包就能干活。2. ADB工具包的组成与原理从守护进程到环境变量2.1 工具包里到底有什么很多人以为 adb工具包 就是那一个 adb.exe其实解压后你会看到一组文件。Windows 下至少包含 adb.exe、fastboot.exe、AdbWinApi.dll、AdbWinUsbApi.dll还有带着驱动说明的文件夹。adb.exe 是你敲命令时直接面对的客户端fastboot.exe 用于设备处于 bootloader 模式时的分区下装普通调试永远用不到但做系统开发、恢复出厂镜像时缺它不行。AdbWinApi.dll 和 AdbWinUsbApi.dll 是 Windows 上的 USB 通信库缺了它们adb.exe 连启动都会报“系统错误”所以网上那种只拷贝一个 adb.exe 的“精简包”是最容易埋雷的。macOS 和 Linux 下则是 adb 和 fastboot 两个不带扩展名的可执行文件结构更简单但同样不能只拿一个二进制走天下因为它们依赖系统自带的 USB 权限规则。选型上我一般只推荐官方渠道下载因为它的行为最可预期。第三方整合包为了开箱即用会做各种“优化”比如把 server 端口改掉、内置多个平台的驱动结果排查问题时像进了黑匣子。官方包解压即用文件名、依赖、版本都确定出了问题也好在网上搜到对应答案。下载回来第一件事我会看一眼压缩包里的 source.properties确认版本和构建时间。Platform Tools 会跟随 Android 版本同步更新如果你的机型是新系统旧版 adb 可能没法正确识别到 adbd所以保持版本新鲜是一个低成本高收益的习惯。反过来只在老设备上做简单连接时新版 adb 也兼容旧手机不存在向下兼容问题。2.2 一条adb命令的完整链路从你敲下 adb devices 到屏幕上出现序列号中间经过了三个角色adb client、adb server、adbd。adb client 是你在终端运行的程序adb server 是它自动在后台启动的子进程负责监听本机 5037 端口并维护电脑与所有设备的连接adbd 则是设备端运行的守护进程在 Android 系统启动初期就已经存在等待电脑通过 USB 或无线网络来握手。为什么是 5037这是 adb 的默认端口官方定死不提供配置项。所以只要这个端口被占用所有 adb 命令都要遭殃。在你敲 adb devices 时client 把请求发给 serverserver 检查已连接设备并尝试与 adbd 握手。握手成功后server 记录设备序列号和状态。如果你看到 unauthorized 和 offline说明握手没过或者设备反应异常。server 是一个伴随进程它不是守护服务也不会开机自启。第一次执行 adb 命令时它会自动跑起来电脑重启后重新启动。手动管理它只有两个命令adb kill-server 和 adb start-server。前者在你怀疑状态异常时使用后者其实不需要经常手动执行因为任意 adb 命令都会自动拉起 server。但在 CI 环境或脚本里我一般会在开头固定加 adb kill-server确保上一个任务的残留连接不会污染当前结果。端口被占的情形我遇到过不少次典型报错是 adb server version mismatch。Windows 上我用 netstat 和 tasklist 定位netstat -ano | findstr 5037 tasklist | findstr PID第一行看到监听 5037 的 PID第二行反查是哪个程序。如果是 adb.exe 但版本不同说明有另一份 Platform Tools 或 Android Studio 的 adb 抢在前面kill-server 后重启即可如果不是 adb.exe那就是被杀毒软件、手机助手类工具占用把那个程序退出问题立刻消失。不要一开始就去重装 adb问题根本不在安装。2.3 下载解压与配置环境变量下载 adb工具包 最可靠的途径是 Android 开发者网站或 Android Studio 的 SDK Manager 里单独下载 Platform Tools。拿到的是 zip 压缩包里面是当前平台的二进制。解压到固定目录后需要把目录加入 PATH这样在任何终端都能直接敲 adb。Windows 上的设置分临时和永久set PATH%PATH%;C:\platform-tools setx PATH %PATH%;C:\platform-toolsset 只对当前 cmd 窗口有效适合临时试一下setx 会写进用户环境变量永久生效。但 setx 有个坑如果 PATH 原本很长setx 会覆盖式写入可能截断其他路径所以使用前最好先用 echo %PATH% 备份原值。另一个常用做法是在系统设置界面手动添加一条 C:\platform-tools这样最安全不会动原来的值。macOS/Linux 下更简单把解压目录放到 home 下面然后导出到 PATHexport PATH$PATH:$HOME/platform-tools这一行只对当前终端有效想永久生效就把它追加到 ~/.zshrc 或 ~/.bashrc 末尾。还有一个常见误区是修改完环境变量后在同一个终端里继续敲命令却提示找不到命令因为终端在启动时读取 PATH并不会实时重读。新开一个终端窗口再验证就行。验证是否配置成功adb version能看到版本号说明环境没问题。如果确实不想动环境变量也可以每次 cd 到 platform-tools 目录再执行或者用别名。我自己的做法是在 ~/.zshrc 里写一行 alias adb/Users/me/tools/platform-tools/adb既不需要污染系统 PATH也不受目录权限限制。3. 用 adb工具包 干正事这几条命令能应付八成需求3.1 连接设备与状态检查拿到一台机器我从来不会直接上手装包而是先跑 adb devices 看连接状态。手机需要先在“开发者选项”里打开“USB 调试”插线后手机弹窗询问是否允许调试选择允许。如果没弹窗检查数据线是否支持数据传输很多廉价线只能充电。确认弹窗后终端里执行adb start-server adb devices -l-l会额外显示设备型号、Android 版本等细节这在多设备环境里非常有用。输出里第二列代表状态device表示正常unauthorized表示授权未确认offline表示连接不稳定。看到unauthorized时回到手机重新弹窗选允许如果一直没有弹窗可以在开发者选项里的“USB 调试”设置中撤销授权后重插。看到offline优先换线、换USB口而不是怀疑代码问题。这里有一个容易被忽略的点adb server 默认只监听本机 5037同一台电脑上同时跑多个 SDK 工具时它们会抢占 server 的所有权。所以我每次开局都会把adb kill-server adb start-server连在一起执行确保状态干净。还用过一个技巧如果插入多台设备直接敲adb devices会列出一串序列号这时候任何不带-s的 adb 命令都会报错“more than one device”因为 server 不知道该发给谁。后面第 4 章会专门讲多设备怎么选。3.2 安装卸载、文件传输与截图App 开发测试里最常用的就是安装包管理。我经常要在一台测试机上安装多个版本一条命令搞定adb install -r app-release.apk adb install -d app-old.apk adb uninstall com.example.app-r表示允许覆盖安装保留数据-d允许版本号降级比如从 2.0 装回 1.9 做回归。需要注意如果两个包签名不一致-r也救不了会报INSTALL_FAILED_UPDATE_INCOMPATIBLE这时候只能先卸载再装。卸载命令传的是包名不是 App 名字包名在 AndroidManifest.xml 里也可以用adb shell pm list packages查。文件传输主要靠 push 和 pull方向一定要记清楚第一个参数永远是本机路径adb push ./test.txt /sdcard/Download/ adb pull /sdcard/Download/test.txt ./push 的本地路径可以是相对路径目标目录必须存在且应用可写。/sdcard/Download/是 Android 公共存储目录绝大多数文件放这里都能读。如果要把截图直接截到电脑上最稳的命令是用exec-out而不是shell screencapadb exec-out screencap -p screen.png原因很简单adb shell会在 Windows 下把换行符做转换截图的 PNG 二进制会被污染文件打不开exec-out是纯二进制输出通道不做终端转换。这条是我踩过无数次坑后才固定下来的写法后面避坑章还会再提。如果只是想预览画面而不保存可以配合CONNECT工具但一般测试截图已经够了。3.3 日志抓取与崩溃定位日志抓取是 adb工具包 最值钱的能力远比看设备屏幕高效。复现崩溃的标准流程是先清空历史日志再触发问题最后导出日志adb logcat -c adb logcat -v threadtime app.log 21-c清空缓冲区-v threadtime让每条日志带线程名和精确到毫秒的时间用于还原先后顺序。21把 stderr 一并写进文件避免日志里夹杂错误通道的信息。崩溃堆栈一般在AndroidRuntime标签下优先级为E所以你也可以只过滤这条链adb logcat -s AndroidRuntime:E-s的意思是“静默模式只显示指定标签”适合现场交互查看。如果崩溃发生在 native 层多看看libc和DEBUG标签。除了 logcatadb bugreport也会把系统配置、进程列表、内核日志打包成一个 zip但命令执行时间长、输出大更适合事后分析。测试 App 时我习惯让 logcat 一直开着写文件同时用 adb 模拟点击复现这样崩溃现场一帧都不会漏。3.4 用 shell 命令做轻量自动化adb 不只是装包和看日志adb shell可以进入设备上的一个 Linux shell几乎能检查一切。日常我会用它做三件事模拟按键、滑动、启动页面以及查询系统状态。模拟操作命令adb shell input keyevent KEYCODE_HOME adb shell input swipe 500 1500 500 500 adb shell am start -n com.example.app/.MainActivitykeyevent KEYCODE_HOME相当于按 Home 键常见按键码还有KEYCODE_BACK、KEYCODE_POWER、KEYCODE_ENTER。input swipe的四个数字依次是 fromX fromY toX toY兼容不同分辨率的方法是先用adb shell wm size拿到屏幕宽高再按比例算坐标不然在平板和手机上很容易点偏。am start -n直接拉起指定 Activity-n后面必须是“包名/活动全名”用adb shell dumpsys activity activities能看到当前前台是什么 Activity。查询系统状态我更常用 dumpsys它按服务名输出大量信息adb shell dumpsys battery adb shell dumpsys meminfo com.example.appdumpsys battery会打印当前电量、充电状态和温度适合做功耗回归dumpsys meminfo跟在包名后面可以看该应用的内存占用明细定位内存泄漏很有用。做自动化测试时这些命令都能塞进脚本里循环跑比人在屏幕前判断快得多。工具包的价值就在这单条命令解决单点需求组合起来就是一套完整的设备控制台。4. 无线调试与多设备并行让 ADB 工具包真正融入工作流4.1 Android 11 无线配对与连接没有数据线也能用 adb这在设备分布在不同工位时特别有价值。Android 11 及以上系统原生支持“无线调试”不再需要先用 USB 线做初始连接。流程是先在手机“开发者选项”里打开“无线调试”进入子菜单点“使用配对码配对设备”屏幕会给出一个 IP 端口和配对码。电脑上执行adb pair 192.168.1.100:37000提示输入配对码时输入屏幕上的六位数字配对完成后正式连接adb connect 192.168.1.100:5555 adb devices注意pair的端口和connect的端口未必一样。pair 端口通常是 37000 左右connect 端口默认是 5555也可能由系统随机分配以手机界面显示为准。连接成功后adb devices会看到形如192.168.1.100:5555的序列号。断开连接用adb disconnect 192.168.1.100:5555。整套无线调试要求手机和电脑在同一局域网校园网、访客网络这类客户端隔离严重的场景会连不上这是网络策略问题不是 adb 配置问题。无线调试最怕的是一个看起来连上、实际传输丢包的 Wi-Fi。如果你发现 adb shell 卡顿优先检查信号强度和 AP 隔离。很多办公网络的“访客 SSID”不允许终端互访这种环境下无线调试是永远连不上的不要怀疑 adb 设置。如果设备是 Android 10 或更早就只能先插 USB 线启用 TCP/IP 模式再切到无线adb tcpip 5555然后拔线用adb connect 设备IP:5555。这种方式每次开机后可能要重新设置所以我通常只在临时需要时才用。无线调试最大的隐患是稳定性Wi-Fi 环境抖动会让adb shell长时间卡住脚本里没有设超时就会一直挂死。我的习惯是给远程 shell 命令加一层timeout超过 10 秒没返回就放弃后面第 6 章会演示这个写法。4.2 多设备并行与端口转发团队测试经常面临一台电脑控制多台手机的场景比如一部真机、一个模拟器同时在工作。先用adb devices拿到全部序列号然后命令里加-s指定目标adb devices adb -s emulator-5554 shell wm size adb -s 192.168.1.100:5555 install app-test.apk没有-s时如果检测到多台设备adb 会直接报more than one device。-s后面的参数可以是 USB 序列号也可以是IP:端口甚至可以用-d表示唯一 USB 设备、-e表示唯一模拟器但这两者只在确实只有一台时安全。常见的需求是把同一个测试包安装到所有在线设备上可以用 shell 循环for device in $(adb devices | awk NR1 $2device {print $1}); do adb -s $device install app-test.apk done wait让安装命令在后台并发执行wait等所有后台任务结束。并发量太大时注意同一台电脑的 USB 带宽如果装到一半有设备失败把去掉改串行更稳。多设备场景里还有个很有用的能力是端口转发。比如你需要让手机上的 App 访问电脑本地的 8080 端口可以用adb forward tcp:8080 tcp:8080forward把电脑 8080 收到的数据转到设备的 8080适合电脑提供服务、手机访问的场景。反过来如果需要让电脑访问手机上的端口用reverseadb reverse tcp:8081 tcp:8081这样手机在 localhost:8081 监听的接口电脑也能通过本机 8081 访问。做混合开发时前端经常依赖手机内存的 mock serverreverse是一条后悔药级别的命令。需要注意的是forward和reverse都会在设备断开后失效脚本里每次连接后要重新设置。如果同时维护多台设备我会把adb -s device reverse tcp:8081 tcp:8081封装成一个小函数批量建立避免漏配导致联调翻车。5. ADB工具包避坑指南现象、原因、解决5.1 设备状态不对unauthorized、offline 与 no permissions现象adb devices里设备状态是unauthorized命令全部无法执行。原因手机屏幕上出现的“允许 USB 调试吗”弹窗没有被确认或者在弹窗时点了“否”并且勾选了“不再询问”。授权以 RSA 指纹为凭据只要电脑端指纹没被信任这个问题会一直存在。解决在手机“开发者选项”里找到“USB 调试”设置有一个“撤销 USB 调试授权”的按钮点掉以后重新插数据线系统会再次弹窗。如果还是不弹执行adb kill-server adb start-server让 server 重新发起握手。现象设备状态是offline但序列号能看到。原因物理链路不稳定是最大来源包括劣质的数据线、前置 USB 面板供电不足、USB Hub 转接造成的信号衰减。另一个常见原因是旧版 adb server 接到了新版 adbd握手失败导致设备一直维持在 offline。解决先换线、换主板上直连的 USB 口排除硬件因素。再执行adb kill-server后手动点击adb start-server让 server 重新初始化。如果依然 offline把 platform-tools 升级到最新版问题通常止步于此。现象Linux 下执行 adb 报no permissions (user in plugdev group; are your udev rules wrong?)。原因udev 规则没有允许当前用户访问 USB 设备。这不是 adb 本身的问题而是系统权限配置问题。解决把当前用户加入plugdev组并为设备的 VendorID 写一条 udev 规则重载udevadm control --reload-rules。具体 vendor ID 可以用lsusb查看不同厂商数值不同搜索“设备型号 adb udev”能直接找到现成规则。5.2 环境与端口类翻车5037 占用、命令找不到、版本错乱现象任何 adb 命令都输出cannot bind to 127.0.0.1:5037或adb server version mismatch。原因有一个 adb server 已经在 5037 上运行但它的代码路径是另一份 adb 发起的比如 Android Studio 自带 SDK 里的 adb或者某个模拟器安装包捆绑的旧版本。新 client 接管失败就会报版本不一致。解决用第 2 章的netstat -ano | findstr 5037找到占用进程确认是 adb.exe 后全部结束再跑adb kill-server adb start-server。更彻底的方案是把系统环境变量 PATH 里所有包含 platform-tools 的路径整理成一条避免两份 adb 共存。我还在 Windows 上遇到一次是手机助手类的工具占着端口停用后问题立刻消失。现象敲adb提示“不是内部或外部命令”。原因环境变量没有配置或者配置完没有新开终端。通常不是 adb 程序本身缺失。解决检查压缩包解压目录下有没有 adb.exe确认路径后把该目录加入 PATH。临时验证可以先cd /d C:\platform-tools再执行adb version。这里有个容易被忽略的点Windows 环境变量设置界面里的 Path 是一个列表编辑时不要删掉其他项否则可能影响其他工具。5.3 文件、安装与输出类问题截图损坏、安装失败、logcat 乱码现象adb shell screencap -p screen.png在 Windows 上生成的图片打不开。原因adb shell走的是一个 pseudo terminal 通道Windows 命令行会把输出里的\n自动替换为\r\nPNG 文件的二进制流被破坏。这是平台特性不是命令写错。解决改用adb exec-out screencap -p screen.pngexec-out会跳过 terminal 层直接输出原始字节。这个坑同样适用于读取 sqlite 数据库文件、导出二进制日志等场景。现象adb install报INSTALL_FAILED_UPDATE_INCOMPATIBLE或INSTALL_FAILED_VERSION_DOWNGRADE。原因前者通常是包名相同但签名不同Android 不允许静默覆盖签名不一致的应用“签名不一致”最典型的场景是测试包用 debug 签名生产包用 release 签名。后者是要安装的版本号低于已安装版本且没有权限降级。解决对签名不一致先adb uninstall com.example.app卸载旧包再装新包。注意卸载会清空应用数据如果只是日常测试问题不大。对版本降级给 install 加-d参数或者把项目的 versionCode 调高重新打包。如果两个包是同一个开发者在不同电脑上出单检查一下各自的 keystore签名对齐才是根因。现象adb logcat在 Windows 下中文乱码。原因logcat 输出是 UTF-8但 Windows 控制台默认使用本地代码页GBK。解决先执行chcp 65001切换代码页再运行 logcat。如果还乱就把输出重定向到文件用支持 UTF-8 的编辑器打开。或者直接用adb exec-out logcat配合文件重定向同样能避开代码页转换。这五类问题基本覆盖了我日常被问到的大部分情况。ADB 的内部逻辑并不复杂出问题时先看状态、再查端口、最后排除驱动和环境按这个顺序来大部分问题都能十分钟内找到答案。6. 一个能直接落地的进阶技巧用 adb 工具包做设备巡检报告如果你已经能熟练操作单台设备下一步就是把 adb 命令组合成自动化脚本。我每周都会在测试机上跑一次“设备巡检”批量收集电池、存储、前台应用等信息汇总成文本报告。脚本先枚举所有设备然后逐台抓关键状态#!/bin/bash for device in $(adb devices | awk NR1 $2device {print $1}); do echo $device adb -s $device shell dumpsys battery | grep -E level|status adb -s $device shell getprop ro.product.model adb -s $device shell dumpsys activity activities | grep -m1 topResumedActivity adb -s $device shell df /data | awk NR2{print $4} done第一行从adb devices的输出里挑出状态为 device 的序列号后面每条命令都用-s指定设备。grep -m1只取第一行避免 dumpsys 输出太长df /data的第二行是数据分区剩余空间用 awk 把第四列容量摘出来。如果其中某台设备无响应整个脚本会卡住所以我习惯把每个 shell 命令包一层超时timeout 10 adb -s $device shell dumpsys batterytimeout 10的意思是超过 10 秒还没返回就强制结束避免一台离线设备把全部巡检卡死。这个习惯来自一次线上跟进某台设备系统服务假死我的脚本在第三台设备上停了十五分钟最后被超时机制救了。现在我的基线脚本都会在循环开头加上adb kill-server让 server 以干净状态巡检结果会更稳定。像这样的巡检逻辑还能继续扩展成“检查磁盘剩余不足 1GB 时自动清理缓存”的告警脚本门槛不高但价值很实在。如果你刚开始接触 adb工具包我建议先不要急着追求复杂的自动化而是把前面章节里的每一条命令亲手在设备上跑一遍尤其是exec-out screencap和logcat -v threadtime这两条。等你对设备“听话”的感觉建立了再往脚本和批量方向走会更顺。希望帮到你。本文还有配套的精品资源点击获取