简介:platform-tools_r22-windows.zip 是 Google 推出的 Android 平台工具包,专门面向 Windows 环境下进行应用调试、固件刷写与性能分析的开发者,也是搭建命令行开发环境的基础组件。压缩包内包含 21 个文件,以 adb.exe、fastboot.exe 等可执行程序为核心,辅以 AdbWinApi.dll 等运行依赖库、systrace 系列分析脚本与 html/css/js 前端展示文件,整体体积仅 1.76MB,轻量且容易部署。当前已有 314 人学习下载,适合刚接触 Android 底层调试的初学者以及需要快速搭建工具链的进阶开发者参考使用。其中 ADB 承担设备连接、文件传输、Shell 命令与安装/卸载应用等日常操作,Fastboot 可在设备关机状态下闪划分区映像,systrace 与 Hprof Converter 分别用于抓取系统级性能数据和转换内存分析文件,帮助定位 CPU、GPU、内存等瓶颈;连同 USB 驱动文件一起,解决了 Windows 设备识别和低层调试的关键问题。解压后将 platform-tools 目录加入系统 PATH,即可在命令行中直接调用这些工具,省去繁琐配置。
1. 一个过时的压缩包,为什么还能救急
某开发者在深夜翻出一台 Android 6.0 的老测试机,插上新版 platform-tools 的 adb,命令行里等半天只回一行 no devices;换上 platform-tools_r22-windows.zip 里的旧 adb,重启服务后一条命令识别成功。这不是玄学,而是版本匹配的问题:r22 是 Android 6.0 时代的平台工具发布包,内含 adb、fastboot 和配套 Windows 动态库,它的协议握手与驱动匹配都针对那个年代的设备设计。这篇文章围绕这个压缩包讲三件事:如何在 Windows 上正确部署它、adb 与 fastboot 的高频用法、以及旧工具在今天系统上必须绕开的坑。适合手里有老设备、做 ROM 维护、或需要在旧环境复现问题的开发者。
2. 部署 r22 platform-tools:解压、PATH 配置与三分钟自检
r22 没有安装向导,解压即用,但正因如此,很多人的第一次翻车发生在部署环节:有人只拷走 adb.exe,有人把 zip 解压进带中文的目录,还有人配完 PATH 后发现 setx 把环境变量截断了。这一章从解压到自检,把部署路径完整走一遍。
2.1 解压之后先看骨架:r22 的关键文件与不能删的依赖
拿到 platform-tools_r22-windows.zip 后,我建议用 PowerShell 而不是右键菜单解压,方便指定目录和覆盖旧文件:
Expand-Archive -Path "platform-tools_r22-windows.zip" -DestinationPath "C:\android-sdk" -Force-Path 指定 zip 的完整路径,-DestinationPath 指定解压目标目录,-Force 在目标已存在同名文件时直接覆盖,省得中途弹窗询问。命令执行后,platform-tools 目录会出现在 C:\android-sdk 下面,完整路径为 C:\android-sdk\platform-tools。
解压后先别急着用,确认这几个文件在不在:adb.exe、fastboot.exe、AdbWinApi.dll、AdbWinUsbApi.dll。前两个是主程序,后两个是 Windows 下 adb 与 USB 驱动通信的桥梁。很多人翻车是把 adb.exe 单独拷贝到桌面用,结果双击闪退、报错找不到 AdbWinUsbApi.dll,就是因为 DLL 没跟着 exe 走。
| 文件 | 作用 | 能否删除 |
|---|---|---|
| adb.exe | Android 调试桥主程序 | 否 |
| fastboot.exe | bootloader 刷机工具 | 否 |
| AdbWinApi.dll | adb 的 Windows API 适配层 | 否 |
| AdbWinUsbApi.dll | adb 的 USB 驱动通信层 | 否 |
| etc1tool.exe / mke2fs.exe 等 | 镜像与文件系统辅助工具 | 是 |
etc1tool、mke2fs 这类辅助工具在普通调试和刷机中用不到,删了不影响 adb 和 fastboot 工作,但保留原样最省事。目录里的 source.properties 记录了 Pkg.Revision 对应的版本元信息,NOTICE.txt 是许可证文本,这两个文件不用管,留着即可。
2.2 让 adb 在任何目录可用:两种 PATH 配置方式
platform-tools 内的 exe 只在当前目录下能直接运行。要实现在任意路径敲 adb 都有响应,得把目录写进环境变量 PATH。推荐优先用图形界面:进入「设置 → 系统 → 关于 → 高级系统设置 → 环境变量」,在用户变量里找到 Path,点编辑新建一行,粘贴 C:\android-sdk\platform-tools,一路确定退出。改完要新开一个终端窗口才生效,旧窗口里的 PATH 不会自动刷新,这是新手最容易误判的地方。
如果只想在当前终端会话临时用,命令行更直接:
set PATH=%PATH%;C:\android-sdk\platform-toolsset 只对当前 cmd 窗口有效,关掉就没了,适合临时验证或切换多版本。要做永久配置,很多人会用 setx,但这里有个坑提前说:setx 对环境变量长度有硬限制,如果原有 PATH 已经很长,这条命令会把 PATH 截断,后果是之前的 Python、JDK 等路径全部失效。我一般不在 PATH 上赌 setx,而是用 PowerShell 的 [Environment]::SetEnvironmentVariable 或直接图形界面编辑,细节放到避坑章讲。
2.3 自检:adb version 的输出说明了什么
部署是否成功,用版本命令最快确认:
adb versionr22 对应的 adb 版本在输出里通常表现为 1.0.32 上下。除了版本号,还要注意输出里有没有出现 cannot open library 或 adb: command not found。前者说明 DLL 缺失,后者说明 PATH 没配上或终端没重开。再顺手验证 fastboot:
fastboot --versionfastboot 的版本输出格式与 adb 不同,但能打印出版本信息,就说明目录、PATH、动态库三层都没问题。也可以加一步 where adb,查看命令实际解析到哪个路径,防止机器里装了别的版本工具干扰判断。
3. adb 调试实战:设备连接、日志抓取与文件管理
这一章全部操作围绕 r22 的 adb.exe 展开。连接是前提,日志是排查手段,文件与包管理是日常高频动作。三节可以独立使用,也可以组合成一条完整调试链路。
3.1 adb devices 状态全解:offline、unauthorized 与 device
确保手机打开「开发者选项 → USB 调试」,用数据线连上电脑。此时不一定会立即进入可用状态,先启动服务并列出设备:
adb kill-server adb start-server adb devices -l这三行是排查一切的起点。kill-server 结束旧的服务进程,如果电脑上之前跑过其他版本工具,残留 server 的协议可能与 r22 不一致,先杀掉再重启最干净;start-server 启动监听 5037 端口的 adb 服务;devices -l 以详细模式列出当前设备。输出里每一行对应一台设备,状态字段决定了下一步能做什么。
| 状态 | 含义 | 处理方向 |
|---|---|---|
| device | 已连接并授权 | 可以直接执行命令 |
| unauthorized | 手机未确认授权 | 在手机上勾选「始终允许」并点确定 |
| offline | 服务端连上了但通信异常 | 检查线材、驱动、端口占用 |
| no devices | 完全没识别到 | 检查 USB 调试开关、换线、装驱动 |
offline 最常见的两个原因:一是数据线只有充电能力没有数据能力,换线能解决一大半;二是电脑上同时跑着多个版本的 adb 服务,互相争抢 5037 端口。我遇到 offline 的固定动作是先 adb kill-server,再拔线重插,三步走下来基本能定位。手机端第一次连接时弹窗里的 RSA 密钥指纹也要点允许,否则永远停在 unauthorized。
3.2 logcat 抓取崩溃日志:时间格式与崩溃过滤参数
设备连上后,取崩溃现场的第一屏命令是这个:
adb logcat -v threadtime -b main -b system -s AndroidRuntime:E *:S-v 指定输出格式,threadtime 会打印线程名、时间和进程号,比默认格式更适合排查崩溃现场。-b 选择缓冲区,main 里是应用日志、system 里是系统日志,两个一起接能同时看到应用层和框架层的输出。-s 是过滤表达式,AndroidRuntime:E 表示只显示 AndroidRuntime 这条标签下 Error 级别以上的日志,*:S 表示其他标签全部静默。组合效果:屏幕上只留下应用崩溃时 Java 栈的关键几行,不会被系统刷屏干扰。
抓完整日志落盘,用 -d 模式直接 dump 后退出:
adb logcat -d -v threadtime > crash.log-d 不会让日志流一直滚动,抓完自动结束,适合在崩溃复现后第一时间把现场完整保存。crash.log 由命令行重定向生成,里面包含从设备启动至今的完整日志,拿它和 -s 过滤的结果对照,能判断崩溃到底来自应用自身还是系统底层。
3.3 文件与应用管理:push、pull、install 的常用组合
老设备调试绕不开三个动作:传文件、取文件、装应用。
adb push theme.mp3 /sdcard/Download/ adb pull /sdcard/DCIM/Camera/IMG_001.jpg . adb install -r app_lite.apkpush 把电脑文件推入设备,目标路径必须是设备上存在的目录,/sdcard/Download 在绝大多数设备都可用;pull 把设备文件拉回电脑,末尾的 . 表示存到当前目录;install -r 带 -r 参数表示覆盖安装并保留数据,测试阶段反复装同一个应用时最常用。这三个命令有一个共性:路径带空格必须加引号,否则命令解释器会把文件名拆成两截。
补充一个实用组合:先 push 再隐式安装。有些应用的清单限制了直接覆盖安装,可以先把 apk 推进设备,再用 pm install 指定完整路径:
adb push app_debug.apk /data/local/tmp/ adb shell pm install -r /data/local/tmp/app_debug.apk/data/local/tmp 是 adb 用户可写的临时目录,放普通 apk 没问题;pm install 是包管理命令,与 adb install 等价但更接近系统层,能看到更完整的安装失败原因,例如 INSTALL_FAILED_VERSION_DOWNGRADE 这类提示,排查签名或版本问题时比 adb install 的输出有用得多。
4. fastboot 刷机实战:解锁、分区烧写与 r22 能力边界
adb 负责系统内的调试,fastboot 负责系统外的刷机。这一章从进入 bootloader 讲起,到分区烧写结束,最后给 r22 的 fastboot 划清能力边界,避免你在不支持的命令上白费时间。
4.1 进入 bootloader:从 adb reboot bootloader 到 fastboot devices
刷机前要把设备重启进 bootloader 模式,最常见做法是:
adb reboot bootloader设备重启后会停在 bootloader 界面,此时 adb 已经不可用,工具切换成 fastboot。先确认电脑能识别设备:
fastboot devices如果输出一行序列号,说明 fastboot 通道正常;如果卡在 waiting for device,多半是驱动问题。fastboot 在 Windows 下走的是独立的 USB 驱动,和 adb 驱动不是同一个,设备管理器里需要单独安装 bootloader 接口驱动,这一点在避坑章会再展开。
老设备还有一种兜底方式:关机状态下同时按住音量下和电源键,靠按键组合进 bootloader,适合 adb 连不上但设备还能开机的情况。fastboot devices 输出为空不代表没识别到设备,先查驱动再查线材,顺序不要反。
4.2 解锁与分区烧写:boot、system 与 data 的擦写顺序
fastboot 模式下刷分区的基本流程分四步:确认变量、解锁、逐个写分区、重启。第一步先看设备信息:
fastboot getvar all这一条会输出一堆关键变量,比如产品名、secure boot 状态、unlocked 状态。unlocked 字段如果显示 no,需要先解锁,否则后续 flash 命令大概率被拒绝:
fastboot flashing unlockr22 同时期的老设备也有厂商走 fastboot oem unlock 这条命令的,两种写法取决于设备年代。解锁会清空全部数据,这一步执行前必须做好备份,没有后悔药。
注意:解锁操作不可逆,部分设备解锁后还会永久降低系统安全等级,刷机前先确认自己是否能接受这些后果。
解锁后按需烧写分区:
fastboot flash boot boot.img fastboot flash recovery recovery.img fastboot flash system system.img fastboot erase userdata fastboot reboot| 分区 | 作用 | 典型场景 |
|---|---|---|
| boot | 内核与 ramdisk | 刷第三方内核、内核补丁工具修改后的 boot 镜像 |
| recovery | 恢复系统 | 刷第三方 recovery 环境 |
| system | 系统文件 | 完整 ROM 刷写 |
| userdata | 用户数据 | erase 会清空全部用户数据 |
flash 后面跟分区名和镜像文件路径。顺序上先写 boot、recovery、system 等系统分区,最后再 erase userdata,避免中途出错导致设备反复重启。全部完成后 fastboot reboot 回到系统。如果中间某条命令报 FAILED,看括号里的具体原因,是分区不存在、镜像不匹配还是未解锁,逐条对症处理。
4.3 r22 版 fastboot 的边界:没有 A/B 插槽,也不认识动态分区
r22 发布在 Android 6.0 时代,那会儿还没有 A/B 无缝升级,也没有动态分区。这套 fastboot 的命令集有明显边界:不支持 --slot、--current-slot 这类插槽参数,不认识 super 分区,也不支持 adb reboot fastboot 进入 fastbootd。把这些参数塞给 r22 的 fastboot,常见报错是 unknown command 或者直接卡在 waiting for device。
这套旧工具的最佳应用场景是 2015 年前后的单分区设备:刷 boot、刷 recovery、刷 system,一条条 flash 都很稳。如果你手头是 Android 10 以上的动态分区设备,r22 的 fastboot 基本干不了活,镜像里根本没有它认识的物理分区名,这时候老老实实用新版工具,别在旧版本上死磕。
5. r22 在 Windows 上的常见问题与避坑指南
这一章把实践里踩过的坑按「现象 → 原因 → 解决」整理成清单。每一条都对应一个真实场景,按顺序排查能省下大量试错时间。
5.1 现象:设备列表里一直是 offline
现象:adb devices -l 输出了设备但状态是 offline,杀进程、重启服务、重插线都不行。 原因:常见有两个,一是电脑上残留了其他版本工具的 adb server,r22 的 adb 启动时被旧 server 占用了 5037 端口,两边协议对不上;二是 USB 数据线只有充电能力,数据脚没接通。 解决:先执行 tasklist | findstr adb 找到残留的 adb 进程,用 taskkill /F /PID 强制结束,再重新插线、依次执行 adb kill-server 和 adb start-server。换数据线时盯紧状态变化,offline 变 device 往往就在换线那一刻发生。
5.2 现象:fastboot 卡在 waiting for device,新设备不识别
现象:fastboot devices 后一直 waiting for device,设备明明停在 bootloader。 原因:r22 时代的 fastboot 对后来新设备的 USB vendor ID 支持不全,加上新系统对驱动签名要求更严,老驱动装不上。 解决:优先尝试系统自带的通用 ADB 接口驱动,在设备管理器里手动更新驱动时选择 bootloader 接口或复合 ADB 接口;救不了的场景直接放弃 r22 的 fastboot,换成新版工具里的 fastboot.exe。老设备用老工具,新设备用新工具,两条腿走路最稳。
5.3 现象:双击 adb.exe 闪退或提示缺少 DLL
现象:单独把 adb.exe 拷到桌面或别的目录,双击闪退,提示找不到 AdbWinApi.dll。 原因:r22 的 adb 在 Windows 上依赖 AdbWinApi.dll 和 AdbWinUsbApi.dll 两个动态库,只搬 exe 不搬 DLL,系统加载器找不到依赖。 解决:整个 platform-tools 目录一起用,或者拷贝时把 exe 和两个 DLL 放进同一目录。这也是不推荐只取 adb.exe 的原因,看起来省空间,实际给自己埋雷。
5.4 现象:杀毒软件把 adb.exe 或两个 DLL 隔离
现象:解压完一运行,安全软件弹窗报风险,之后 adb devices 提示找不到设备或无法读取配置。 原因:adb 作为老牌调试工具,自带端口监听和进程管理能力,启发式扫描容易把这类行为和木马特征混淆;r22 的 exe 签名较旧,更容易触发误报。 解决:把整个 platform-tools 目录加入安全软件的白名单或排除项,再手动恢复被隔离的文件。目录比单个 exe 更合适,因为 DLL 也可能被隔离,只恢复 exe 照样跑不起来。
5.5 现象:setx 配置 PATH 后原有环境变量被截断
现象:用 setx PATH 拼接新路径后,再开新终端发现 java、python 等命令全部失效,PATH 只剩一截。 原因:setx 对环境变量值长度有硬限制,超出部分直接截断,老 PATH 里的路径丢了大半,而且 setx 写入的是展开后的值,污染了变量本身。 解决:别用 setx 改 PATH,改用 PowerShell 的方式或图形界面编辑,图形界面不会截断。补救时打开注册表编辑器,找到当前用户的环境变量项手动恢复原值,或者从系统变量里重新拼接完整路径。
6. 进阶技巧:多版本 platform-tools 并存与批处理自动化
6.1 目录隔离与按需切换:一套机器装两代工具
需要 r22 和最新版共存时,我习惯建两个独立目录,不把它们同时写进 PATH,而是各自保留一份带完整 DLL 的副本。用哪个版本,就在当前终端临时把对应目录加到 PATH 最前面:
set PATH=C:\android-sdk\platform-tools-r22;%PATH%临时 PATH 只在当前窗口生效,不会污染全局配置,切换也直观。要注意的是,切换后第一件事必须 adb kill-server,否则旧 server 还占着 5037 端口,新 adb 客户端连上的是旧服务,行为还是旧工具的,等于白切。
6.2 把重复操作写成 bat:批量安装、批量抓日志、一键刷 boot
老设备调试最烦的是重复劳动。批量安装当前目录下所有 apk:
@echo off for %%f in (*.apk) do ( echo === installing %%f === adb install -r "%%f" ) pause遍历当前目录所有 apk,逐个执行带 -r 的覆盖安装。for 循环里 %%f 是批处理变量,括号内是循环体;pause 让窗口跑完后暂停,方便看最后一条输出。
抓崩溃日志落盘:
@echo off set LOG_FILE=crash_%date:~0,4%%date:~5,2%%date:~8,2%.log adb logcat -d -v threadtime > %LOG_FILE% echo log saved to %LOG_FILE% pause%date% 按当前系统日期生成文件名,避免每次覆盖。把常用命令固化成 bat,不只是省时间,更重要的是输出可复现,哪次刷挂了能直接拿着日志和命令记录复盘,而不是凭记忆猜。
一个长期养成的习惯:刷机前永远先把 getvar all 的输出存一份,再把当前 boot 分区备份到本地,最后才开始 flash。r22 这套工具虽然老,把边界摸清之后,反而比新版工具在老设备上更稳。希望这篇能帮你少踩几个坑,让仓库里吃灰的 platform-tools_r22-windows.zip 物尽其用。
本文还有配套的精品资源,点击获取