☰
platform-tools r22 Windows 部署与 adb/fastboot 实战
2026/10/10 9:37:52 网站建设 项目流程

简介: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.exeAndroid 调试桥主程序否
fastboot.exebootloader 刷机工具否
AdbWinApi.dlladb 的 Windows API 适配层否
AdbWinUsbApi.dlladb 的 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-tools

set 只对当前 cmd 窗口有效,关掉就没了,适合临时验证或切换多版本。要做永久配置,很多人会用 setx,但这里有个坑提前说:setx 对环境变量长度有硬限制,如果原有 PATH 已经很长,这条命令会把 PATH 截断,后果是之前的 Python、JDK 等路径全部失效。我一般不在 PATH 上赌 setx,而是用 PowerShell 的 [Environment]::SetEnvironmentVariable 或直接图形界面编辑,细节放到避坑章讲。

2.3 自检:adb version 的输出说明了什么

部署是否成功,用版本命令最快确认:

adb version

r22 对应的 adb 版本在输出里通常表现为 1.0.32 上下。除了版本号,还要注意输出里有没有出现 cannot open library 或 adb: command not found。前者说明 DLL 缺失,后者说明 PATH 没配上或终端没重开。再顺手验证 fastboot:

fastboot --version

fastboot 的版本输出格式与 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.apk

push 把电脑文件推入设备,目标路径必须是设备上存在的目录,/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 unlock

r22 同时期的老设备也有厂商走 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 物尽其用。

本文还有配套的精品资源,点击获取

需要专业的网站建设服务?

联系我们获取免费的网站建设咨询和方案报价,让我们帮助您实现业务目标

立即咨询