fastbootd 如何重塑 A/B 分区的刷机体验？
你有没有遇到过这样的场景：OTA 升级进行到一半，手机突然黑屏十几分钟，提示“正在优化应用”？或者想刷个测试镜像，却因为设备分区结构复杂而不敢下手，生怕一不小心就变砖？
在 Android 7.0 引入 A/B 分区（Seamless Updates）后，系统更新的逻辑发生了根本性变化。然而，传统的fastboot模式——那个我们熟悉得不能再熟悉的命令行刷机工具——却逐渐显得力不从心。它运行在 Bootloader 阶段，看不到动态分区，无法与 Recovery 良好协作，更别说支持现代 Android 的高级功能了。
于是，Google 在 Android 10 中悄悄引入了一个关键角色：fastbootd。它不是简单的命令兼容层，而是一次对“刷机”概念本身的重构。今天，我们就来揭开它的面纱，看看它是如何让 A/B 分区的系统更新变得既安全又灵活的。
为什么传统 fastboot 不够用了？
先别急着学新东西，我们得先明白：问题出在哪？
传统的fastboot是 SoC 厂商写在 Boot ROM 或一级引导程序里的一个轻量服务。设备上电后，在操作系统加载前，你按住音量键+电源键，就能进入这个模式。它能做的事情很基础：
- 通过 USB 接收指令
- 直接向物理块设备（如
mmcblk0p42）写入镜像 - 重启设备
听起来挺好用，但到了 A/B + 动态分区时代，这几个“基础操作”开始暴露出严重短板。
1. 它“看不见”动态分区
老设备是静态分区：system是第 37 个分区，vendor是第 38 个，写死在分区表里。但现代 Android 使用super分区，里面打包了system、vendor、product等多个逻辑分区，具体布局由元数据控制，并且可以动态调整。
传统fastboot没有文件系统，没有解析能力，它不知道system_a实际上是super分区里的某个 LUN（逻辑单元）。你让它fastboot flash system_a system.img，它根本无从下手。
2. 它无法安全切换 A/B 槽位
A/B 分区的核心是“无缝切换”。你升级的是另一个槽位，成功后再通过set_active切过去。这个操作必须通过Boot Control HAL（硬件抽象层）完成，以确保符合 AVB（Android Verified Boot）的安全规范。
但 Bootloader 阶段的传统fastboot根本访问不到 HIDL/HwBinder，调不了 HAL 服务。强行修改启动参数或直接写寄存器？风险极高，容易导致设备无法启动。
3. 它缺乏上下文和安全性
Bootloader 是裸金属环境，没有权限管理、没有日志系统、没有网络。你想在刷机前验证镜像签名？做不到。你想记录一次失败的刷写以便调试？也做不到。一旦被恶意利用，后果不堪设想。
fastbootd：把“刷机”搬进 Linux 用户空间
面对这些问题，Google 的解决方案非常巧妙：与其让fastboot死守在 Bootloader，不如把它“请”进 Linux 用户空间。
这就是fastbootd—— 一个运行在Recovery 环境中的守护进程。它长得像fastboot，说话也像fastboot，但内核完全不同。
🔍一句话定义：
fastbootd是一个运行在 Recovery 中的用户态服务，实现了标准 Fastboot 协议，但能访问完整的 Linux 环境，从而支持动态分区、HAL 控制和安全启动链。
你可以把它理解为：“伪 fastboot”模式。设备已经启动了内核，挂载了根文件系统，只是还没进主系统。在这个状态下，fastbootd可以做很多以前做不到的事。
fastbootd 是怎么工作的？
我们来看一个典型的 OTA 更新流程，fastbootd是如何参与其中的。
第一步：OTA 下载完成，准备刷写
update_engine后台下载并验证完 OTA 包后，会通知recovery：“我准备好了，该你上场了。”
设备重启进入 Recovery 模式。
此时，Recovery 并不立刻开始刷写。它先判断：这次更新是否需要跨槽位写入？如果是，那就启动fastbootd。
// system/core/recovery/recovery.cpp if (should_enter_fastbootd()) { android::base::SetProperty("sys.bootmode", "fastboot"); execv("/system/bin/fastbootd", args); // 切换到 fastbootd }注意这里用了execv—— 它不是 fork 子进程，而是直接替换当前进程。这意味着后续所有 Fastboot 命令都由fastbootd处理，而不是回到 Bootloader。
第二步：PC 端发送刷机命令
你在电脑上敲下：
fastboot flash system_b system_new.img fastboot flash vendor_b vendor_new.img这些命令通过 USB 到达设备，被fastbootd接收。接下来才是重头戏。
第三步：fastbootd如何处理“flash”命令？
- 解析分区名：
fastbootd收到system_b，知道这是目标槽位 B 的 system 分区。 - 调用 liblp：通过
liblp（Logical Partition 库）读取当前设备的元数据，找到super分区中system_b对应的 LUN 和偏移。 - 执行写入：使用
libfs_mgr打开块设备，将镜像写入指定位置。 - 保持原子性：整个过程在 Recovery 的受控环境中完成，支持回滚和错误检测。
这一步是传统fastboot完全做不到的。它依赖的是完整的用户空间库和文件系统支持。
第四步：切换启动槽位
刷写完成后，你需要告诉设备下次从 B 槽位启动：
fastboot set_active other这条命令会被fastbootd转发给Boot Control HAL：
// 通过 HwBinder 调用 bootctrl->setActiveBootSlot(slot_id); // 切换到另一槽位HAL 层会更新 NV 存储中的槽位标志，并设置回滚保护。这一切都在 Android Treble 框架的规范下进行，安全可靠。
第五步：重启，完成更新
最后执行：
fastboot reboot设备正常重启，Bootloader 读取最新的活动槽位，加载新的系统。新系统首次启动后调用markBootSuccessful()，确认更新成功，防止自动回滚。
fastbootd 到底强在哪里？
我们不妨做个直观对比：
| 能力 | 传统 fastboot | fastbootd |
|---|---|---|
| 运行环境 | Bootloader（无 OS） | Linux 用户空间（Kernel 已启动） |
| 文件系统 | ❌ 无 | ✅ 支持 ext4/f2fs |
| 动态分区支持 | ❌ 不支持 | ✅ 通过liblp解析 super 分区 |
| 槽位切换 | ⚠️ 手动修改（危险） | ✅ 通过 BootControl HAL 安全切换 |
| 网络访问 | ❌ 无 | ✅ 可选启用（用于在线验证） |
| 安全机制 | 依赖 Bootloader | ✅ 集成 AVB + Verified Boot |
| 调试能力 | ❌ 极弱 | ✅ 可输出日志、检查状态 |
看到区别了吗？fastbootd不再是一个“盲刷”工具，而是一个具备上下文感知能力的智能恢复服务。
它还能做什么？DSU 调试神器了解一下
除了 OTA 更新，fastbootd还解锁了一个开发者最爱的功能：DSU（Dynamic System Update）。
想象一下：你不需要刷机，也不需要擦除数据，就能临时运行一个 GSI（通用系统镜像），测试 Android 新版本或不同厂商 UI。做完测试，重启一下，手机就回到原来的系统。
这就是 DSU 的魔力，而它的实现核心就是fastbootd。
典型流程如下：
# 创建一个名为 system 的逻辑分区，大小 4GB fastboot create-logical-partition system 4294967296 # 将 GSI 镜像刷入这个临时分区 fastboot flash system_gsi gsi.img # 设置下次从这个 DSU 镜像启动 fastboot dsu <gsi_hash> # 重启 fastboot reboot这一切之所以可行，是因为fastbootd能在运行时动态创建和管理逻辑分区。而传统fastboot？连“创建分区”这个概念都没有。
开发者需要注意什么？
如果你是 OEM 工程师或定制 ROM 开发者，启用fastbootd需要在编译配置中明确声明：
# BoardConfig.mk BOARD_USES_RECOVERY_AS_BOOT := true BOARD_HAS_FASTBOOTD := true TARGET_NO_BOOTLOADER := true同时，必须实现IBootControl.hal并确保服务正常注册。否则set_active等关键命令会失败。
另外，建议在调试时使用以下命令确认当前模式：
fastboot getvar is-userspace # 如果返回 yes，说明正在 fastbootd 环境中查看内核日志也能帮助定位问题：
dmesg | grep fastbootd写在最后：从“刷机”到“系统治理”
fastbootd的出现，标志着 Android 系统维护方式的一次跃迁。
它不再是一个孤立的底层工具，而是深度融入了 Android 的启动链、安全模型和分区架构。它让“刷机”这件事变得更安全、更智能、更可编程。
对于普通用户，这意味着更可靠的 OTA 升级体验；
对于开发者，这意味着更高效的调试路径；
对于厂商，这意味着更低的维护成本和更强的系统可控性。
当你下次在终端输入fastboot flash时，不妨想一想：背后是哪一个世界在为你服务？是那个冰冷的 Bootloader，还是一个已经启动了 Linux 内核、正在静静等待指令的fastbootd？
技术的演进，往往藏在这些看似微小的转变之中。
如果你在开发或调试中遇到了
fastbootd相关的问题，欢迎在评论区留言讨论。我们一起拆解现代 Android 的底层逻辑。
