12、Fastboot 与刷机：Fastboot 协议、分区表布局、刷机脚本与工具
刷机这件事，说白了就是给设备换一套系统。你想想看，手机或者嵌入式设备，它的系统是存在闪存里的。我们要做的，就是把新的系统镜像写到对应的存储区域里。而Fastboot，就是Android生态里最常用的底层刷机协议。
我个人习惯把Fastboot看作是设备的“引导加载程序模式”下的一个服务。设备上电后，bootloader会先跑起来，如果检测到特定按键组合或者USB命令，就会进入Fastboot模式。这时候，设备就像一个听话的奴隶，等着主机发号施令。
12.1 Fastboot 协议：主机与设备的对话
Fastboot协议其实很简单。它基于USB bulk传输，是一种命令-响应式的协议。主机发送命令，设备执行并返回结果。命令都是ASCII字符串，以\x00结尾。
常见的命令有：
getvar：获取设备变量，比如getvar:product可以拿到产品名。download：把镜像从主机下载到设备的内存缓冲区。flash：把缓冲区里的数据写到指定分区。boot：直接启动内存中的内核镜像，不写入闪存。reboot：重启设备。
嗯，这里要注意。协议本身是半双工的。主机发一条命令，必须等设备回复 OKAY 或 FAIL 之后，才能发下一条。我在项目中遇到过，有些第三方bootloader实现不标准，回复格式多了个换行符，导致PC端的fastboot工具解析失败。排查了好久才发现是协议兼容性问题。
核心要点：Fastboot协议不负责校验数据完整性。它只保证传输完成。真正的校验，比如哈希检查，需要在上层脚本里做。
12.2 分区表布局：闪存的“房产证”
分区表定义了闪存里每一块区域的用途和大小。没有它，系统就不知道哪里该放什么。Android设备最经典的分区布局，我列在下面了：
| 分区名 | 典型大小 | 用途 |
|---|---|---|
boot |
32-64 MB | 内核 + ramdisk |
system |
1-4 GB | 系统镜像 (只读) |
vendor |
256-512 MB | 硬件厂商专有库 |
userdata |
剩余空间 | 用户数据 (可读写) |
cache |
256-512 MB | OTA缓存 (已逐渐废弃) |
recovery |
32-64 MB | 恢复模式内核 |
misc |
1-2 MB | 启动控制信息 |
vbmeta |
1-2 MB | 验证启动元数据 |
你可能会问，为什么要有这么多分区？其实这是为了安全性和更新灵活性。比如 boot 和 recovery 分开，万一刷坏了系统分区，还能进recovery救砖。我曾经手贱，在调试时把 bootloader 分区写坏了，设备直接变砖。后来只能用JTAG线重新烧写，那叫一个折腾。
警告：千万不要随意修改分区表！尤其是 gpt 或 partition 分区。一旦分区表损坏，设备将无法被系统识别，只能通过底层工具（如ISP）修复。
12.3 刷机脚本：自动化刷机的灵魂
手动一条条敲fastboot命令太累了。所以就有了刷机脚本。最常见的是 flash-all.sh (Linux/macOS) 和 flash-all.bat (Windows)。
一个典型的刷机脚本长这样：
#!/bin/bash
# 刷机脚本示例 - 来自AOSP官方
fastboot flash bootloader bootloader.img
fastboot reboot-bootloader
sleep 5
fastboot flash radio radio.img
fastboot reboot-bootloader
sleep 5
fastboot flash recovery recovery.img
fastboot flash boot boot.img
fastboot flash system system.img
fastboot flash vendor vendor.img
fastboot flash userdata userdata.img
fastboot erase cache
fastboot reboot这里有几个坑，我踩过：
- 顺序很重要：必须先刷bootloader和radio，再刷其他分区。因为新bootloader可能改变了分区布局。
- 加sleep：有些bootloader在重启后需要时间初始化USB，不加sleep可能导致下一行命令失败。
- 擦除cache：虽然现在cache分区用得少了，但OTA升级时如果cache里有残留数据，可能会出问题。我建议顺手擦一下。
小技巧：如果你在写自动化测试脚本，可以用 fastboot getvar all 先获取设备信息，然后根据product变量选择不同的镜像路径。这样一套脚本可以兼容多个设备。
12.4 刷机工具：不只是fastboot
虽然 fastboot 是官方工具，但实际项目中我们还会用到其他工具：
- Heimdall：三星设备的刷机工具，协议和Fastboot不同，但原理类似。
- SP Flash Tool：联发科平台用的，通过 brom 模式刷机。
- QFil / QPST：高通平台用的，用于烧写整个闪存镜像。
我个人习惯，在AOSP编译完成后，直接用 make fastboot 编译出最新的fastboot工具。因为系统自带的版本可能太老，不支持新分区特性（比如 logical partitions）。
12.5 知识体系总览
下面这张图，我把本章的核心逻辑串起来了。你可以看到，从主机到设备，数据是怎么流动的：
从这张图你可以看到，整个刷机流程就是：主机通过Fastboot协议，把镜像文件下载到设备内存，然后设备根据分区表，把数据写入对应的闪存区域。刷机脚本则负责编排这些命令的顺序和参数。
好了，关于Fastboot和刷机，核心内容就这些。记住，刷机有风险，操作需谨慎。尤其是量产阶段，一定要有完善的校验和回滚机制。我在产线上见过因为刷机脚本少写了一个 erase 命令，导致整批设备userdata分区残留旧数据，最后全部返工。嗯，细节决定成败。