1. 课程导入

Android Recovery 是 Android 设备中独立于主系统运行的一个轻量级恢复环境。它既承担 OTA 升级、恢复出厂设置、清除缓存等基础职责，也是设备变砖后最后的软件救援通道。对于系统开发与移植工程师而言，Recovery 不是“刷机工具”这么简单，而是一套涉及启动链、分区布局、内核驱动、图形显示、升级脚本与安全校验的完整子系统。本课程的目标，是带你从“会用 Recovery”进阶到“能改、能移、能调、能量产”。

一、学习目标：从使用者到移植者

完成本课程后，你应当具备以下能力：

• 理解 Recovery 在 Android 启动链中的位置，能说清 BootROM、Preloader、Bootloader、Kernel、Recovery、System 之间的加载关系。
• 掌握 Recovery 镜像的组成结构，包括内核、ramdisk、recovery 二进制、资源文件与升级脚本。
• 能够为一块新板卡配置分区表、编译 Recovery、烧录并进入 Recovery 界面。
• 能够修改 Recovery 的 UI、按键映射、菜单项与升级逻辑，适配不同屏幕与输入设备。
• 能够分析 OTA 升级失败、挂载失败、签名校验失败等常见问题，并给出可复现的排查路径。
• 理解 A/B 无缝升级与 Recovery 升级的差异，能根据产品形态选择合适方案。

二、核心概念：Recovery 的五个关键维度

Recovery 的知识点看似零散，实际上可以收敛到五个维度：启动链、分区、镜像、升级包、交互界面。启动链决定 Recovery 如何被加载；分区决定它从哪里读取数据；镜像决定它包含哪些组件；升级包决定它执行什么动作；交互界面决定用户如何触发这些动作。理解这五者的关系，后续章节就不会变成零散命令的堆砌。

其中最容易混淆的是 recovery 与 boot 的关系。两者共用同一个内核，但 ramdisk 不同：boot 的 ramdisk 启动 init 并进入 Android 系统，recovery 的 ramdisk 启动 recovery 二进制并进入恢复菜单。因此，移植 Recovery 时，内核驱动往往可以复用，真正需要适配的是 ramdisk 中的初始化脚本、fstab、图形与输入配置。

三、整体知识框架与实战路线图

下图给出本课程的整体知识框架。左侧是启动与分区基础，中间是 Recovery 镜像与升级机制，右侧是移植、调试与量产落地。箭头表示学习与工程实践的推进方向。

四、方法流程：一次完整的 Recovery 工程闭环

无论你面对的是高通、联发科还是瑞芯微平台，Recovery 的工程闭环都可以抽象为以下步骤：

1. 确认启动方式：设备如何进入 Recovery？是组合键、adb reboot recovery，还是 misc 分区写入命令。
2. 确认分区布局：recovery、boot、misc、cache、userdata 的偏移与大小，是否使用 A/B 槽位。
3. 准备镜像：从源码编译或从官方固件提取 recovery.img，确认内核与 ramdisk 匹配。
4. 烧录与验证：通过 fastboot、SP Flash Tool 或厂商工具写入，观察串口日志是否进入 recovery 模式。
5. 功能验证：挂载分区、执行 OTA、清除数据、查看日志，确认核心路径可用。
6. 定制与回归：修改 UI、按键、脚本后，重新执行升级与恢复测试，形成可重复的验证清单。

下面是一段典型的进入 Recovery 与查看日志的命令示例：

adb reboot recovery
# 或从 bootloader 进入
fastboot reboot recovery

# 进入后通过 adb 查看 recovery 日志
adb shell cat /tmp/recovery.log
adb shell dmesg | grep -i "recovery\|mount\|mmc"

五、案例场景：新板卡第一次点亮 Recovery

假设你拿到一块新板卡，系统尚未跑通，但 Bootloader 和 fastboot 可用。此时不要急着改 UI，而应按“最小可用”原则推进：先确认 recovery 分区可写，再烧入一个与内核匹配的 recovery.img，观察是否能显示菜单。若黑屏但串口有 recovery 日志，说明二进制已启动，问题在显示或 framebuffer；若串口停在内核启动阶段，则优先检查设备树、存储驱动与 cmdline。这个场景会贯穿后续多个章节，也是移植工程师最常见的起点。

六、常见误区与复盘