Seamless Architecture

A/B 槽位：理解现代安卓的“镜像双生”

本规程旨在指导技术人员在不依赖闭源一键工具的前提下，深度剖析 Android 7.0 后引入并在 Android 11 后普及的 Seamless System Updates (无缝更新) 架构，确保在分区表逻辑紊乱时具备底层的槽位审计与强制救砖能力。

“刷机不看槽位，等于盲人开车。理解 A/B 切换逻辑，不仅是解决大部分‘莫名卡米’的终极钥匙，更是玩转 GSI 镜像与 Magisk 内核修补的基础。”

1. 机制演进：从“独立双系统”到“逻辑冗余”

老玩家熟悉的安卓 2.x 到 4.x 时代（如小米 1/2）拥有“真实物理双系统”。那时物理上划分了 System1 和 System2，用户可以独立安装两套完全不同的 ROM。而在现代安卓中，A/B 槽位并不是为了让你安装两套系统，而是为了实现“无缝静默更新”与“失败自动回滚”。

工作逻辑：当你在 A 槽位运行系统时，OTA 更新包会在后台静默刷入 B 槽位。重启后，Bootloader 会将引导指向 B 槽。如果 B 槽因为更新损坏无法进入系统，Bootloader 会在多次尝试失败后自动“滚回” A 槽，确保设备不处于不可用状态。在 Android 11+ 的 Virtual A/B (VAB) 架构中，甚至引入了 Snapshot (快照) 机制，利用 /data 分区的空余空间动态创建 B 槽位的镜像，从而大幅减少了对物理存储空间的占用。

Slot A boot_a / system_a
vendor_boot_a
vbmeta_a
Slot B boot_b / system_b
vendor_boot_b
vbmeta_b

核心审计：Userdata 分区（用户数据）永远只有一份！

Data Partition Is Shared Between Both Slots - Formats Affect Both

2. 状态审计：我在哪个“房间”？

在进行任何 Flash（刷写）或切换操作前，必须首先审计当前活跃槽位及各槽位的“生命体征”。盲目操作是导致设备引导死锁、无限重启（Bootloop）的主因。现代 Bootloader 通过存储在 Misc 分区 中的元数据来决定引导去向。

查询活跃槽位 (Active Slot Index)

fastboot getvar current-slot

# 若返回 "a"，说明当前逻辑指针指向 A 槽，手动执行 fastboot flash boot boot.img 将默认覆盖 boot_a。

进阶：审计槽位健康度 (Slot Health Audit)

fastboot getvar slot-retry-count:a fastboot getvar slot-success:a

# retry-count: 系统尝试引导该槽位的剩余次数（通常初始值为 7 或 3）。若跌至 0，Bootloader 会将其标记为损坏。
# slot-success: 若为 "yes"，表示该槽位曾有过成功进入系统的记录。

底层回滚逻辑 (Rollback Mechanism)

当一个槽位的 retry-count 归零且未被标记为 success 时，Bootloader 会激活 "Unbootable" 标记，并自动切换到另一个槽位。如果你手动修补了 boot 但依然无法启动，通常是因为计数器没有重置，导致 Bootloader 拒绝尝试引导该槽位。

3. 操纵规程：精准刷入与显式指定

这是一个极易翻车的技术细节。当你执行普通的 flash 指令而不带后缀时，其目标具有“隐性指向性”，这完全取决于当前的 current-slot 环境变量。

fastboot flash boot boot.img # 隐性审计逻辑：
# 1. 检查 current-slot -> a
# 2. 自动映射目标 -> boot_a
# 3. 执行写入。如果你在 A 槽刷错了，可能导致 A 槽引导崩溃。

方案 A：双向同步寻址（灾难防御推荐）

如果你想确保无论后续发生何种槽位自动回滚，设备都能正常引导（例如在救砖或修补内核时），建议摒弃隐性指令，执行显式双刷。这种方式可以物理消除 A/B 两个“房间”之间的固件差异：

fastboot flash boot_a boot.img fastboot flash boot_b boot.img

Explicit Slot Targeting - 100% Redundancy

方案 B：强制槽位重定向 (The Failover Command)

如果你在活跃槽位（如 A 槽）刷入了导致无法开机的错误镜像，不要急于执行 Data Wipe（清除数据）。由于 Userdata 是共享的，你只需要强制切换到原本健康的 B 槽位。此时 Bootloader 会修改 Active Bit 标记，直接跳过损坏的分区：

fastboot set_active a # 强制改写元数据，将 A 标记为引导入口 fastboot set_active b # 强制改写元数据，将 B 标记为引导入口

盲区警告：底层“虚无”风险 (The Null Slot Risk)

在采用 Virtual A/B (VAB) 架构的设备上，当系统未处于 OTA 更新挂起状态时，另一槽位的逻辑索引可能是空的。强行通过 set_active 切换到一个从未初始化过的槽位，会导致引导加载程序找不到有效的 GPT 分区表映射，从而直接触发 SoCs 的紧急下载模式（如 Qualcomm 9008）。在切换前，请确保执行过一次完整的底包线刷。

4. 深度审计：Data 分区的“单向加密”陷阱

尽管 A/B 槽位提供了系统层级的镜像冗余，但它们共享唯一的物理 userdata 分区。这引入了一个基于 FBE (File-Based Encryption) 的致命逻辑冲突：Android 安全版本向下兼容性断裂。

密钥版本死锁 (Version-Locked Decryption)

逻辑场景：假设 A 槽已升级至 Android 15，此时系统会使用新的 Keymaster/KMIP 协议对 Data 分区进行密钥索引。如果你此时强制切回残留 Android 13 的 B 槽，旧版内核的加密引擎（TEE/TrustZone）无法解析高版本 Android 创建的加密上下文（Inodes/Tnode）。

核心结果：系统启动后会因无法解密 /data/system/de 导致界面卡死，或抛出“密码错误”弹窗。此时执行任何切换都无法挽回，系统将强制触发 recovery --wipe_data。

5. 进阶避坑：消失的 Recovery 与 FastbootD 逻辑层

在 Android 11+ 的 GKI (通用内核) 架构中，传统的物理 recovery 分区已彻底退出历史舞台。取而代之的是将其集成到了 boot 或 vendor_boot 镜像的 Ramdisk 中。这一改变极大增加了救砖难度，因为“引导故障”与“恢复环境故障”已由于镜像融合而产生物理耦合。

架构级陷阱：引导与恢复的“一损俱损”

如果你在活跃的 A 槽刷入了一个损坏的 boot.img，由于 Recovery 指令集嵌套在 boot 中，此时你不仅进不去系统，物理按键组合进入 Recovery 的路径也将彻底断开。

救砖路径审计：唯一的生还机会是进入 Bootloader (Fastboot) 模式，利用 fastboot set_active b 切到 B 槽。由于 A/B 槽位的 boot 镜像是物理隔离的，B 槽健康的 Recovery 逻辑将作为你修复 A 槽的桥头堡。

死亡红线：禁忌的 FastbootD 操作审计

技术人员必须在生理直觉上严格区分 Bootloader (静态模式) 与 FastbootD (用户态模式)，后者的权限范围受限于虚拟内存挂载状态：

  • 严禁在 FastbootD 模式乱切槽位： FastbootD（界面显示为大蓝字或带有菜单的模式）是运行在 Recovery 临时 Linux 内核之上的。在此模式下执行 set_active 会导致当前的逻辑分区映射 (dm-linear) 与底层物理槽位标识发生冲突，极易造成 Metadata 分区逻辑损坏，导致设备永远卡在 Fastboot 无法寻找分区表。
  • 严禁在 FastbootD 抹除动态分区索引： 执行 erase system 会破坏 Super 分区内的逻辑索引。在 A/B 架构下，一旦 A 槽的元数据受损，整个 UFS 寻址链可能会被系统判定为无效。

黄金准则：切换槽位、刷入引导文件 (Boot/Vendor_boot/Vbmeta) 必须在传统的、由 CPU 原生引导的 Bootloader 模式下执行。只有刷写 System/Vendor/Product 等超大动态分区时，才进入 FastbootD。

6. 结语：冗余是为了最高级别的安全

A/B 槽位的本质不是为了花哨的功能，而是一种基于 原子性（Atomicity） 的系统自愈机制。通过在物理层隔离引导镜像，Android 确保了即便在极端环境下，设备也始终拥有一个“Plan B”。作为开发者或高阶玩家，我们在操作时应时刻利用这种冗余，养成“先备份健康槽位，再折腾活跃槽位”的习惯。每一次手动 set_active，都是在执行一次底层的生命线重定向。

灾难恢复决策建议 (Decision Tree)

  • 1. 卡第一屏/无限重启？ -> 优先尝试 fastboot set_active 切换槽位。
  • 2. 提示密码错误/数据损坏？ -> 说明跨版本切换触发了 FBE 锁死，请切换回原槽位或抹除 Data。
  • 3. 进不去 FastbootD/Recovery？ -> 在静态 Bootloader 下切换槽位，恢复引导链完整性。

System Logic Architecture: Complete

“至此，你已掌握 Android 槽位切换的生存法则。 每一份谨慎，都是在为你的数据买保险。”

下一篇：动态分区逻辑卷与 FastbootD 实战