第1章 Recovery模式概述

1. Recovery模式概述：Recovery模式是什么、Recovery模式的工作原理、Recovery模式在Android系统中的位置

1.1 Recovery模式到底是什么？

说实话，很多刚入行的Android开发对Recovery模式的理解，就停留在「手机进不去系统时按音量键+电源键的那个界面」。嗯，这个理解没错，但太浅了。

我个人的理解是——Recovery模式是Android系统的一个独立的小型操作系统。它不依赖你手机里那个完整的Android系统，自己有一套独立的Linux内核、文件系统和核心服务。

你想想看，如果主系统都崩溃了，你还能指望它自己修复自己吗？显然不能。所以Google设计了一个「备份方案」——Recovery模式。它就像医院的急诊室，主系统挂了，它还能干活。

核心定义：Recovery模式是一个运行在独立分区（recovery分区）上的轻量级Linux系统，用于执行系统恢复、固件升级、数据擦除等底层操作。

我在项目中遇到过一件事：有个客户反馈手机OTA升级后变砖了。我第一反应就是进Recovery模式看看。结果发现Recovery本身也被刷坏了……嗯，那才是真正的噩梦。所以后来我特别强调：Recovery分区一定要有保护机制。

1.2 Recovery模式的工作原理

说白了，Recovery模式的工作流程就三步：启动 → 执行脚本 → 重启。但每一步背后都有不少门道。

1.2.1 启动流程

手机按下电源键后，Bootloader（引导加载程序）会先启动。它会检查一个叫BCB（Bootloader Control Block）的东西。这个BCB里记录了系统下次启动要干什么。

// BCB结构体（简化版）
struct bootloader_message {
    char command[32];      // 启动命令，如"boot-recovery"
    char status[32];       // 状态信息
    char recovery[1024];   // Recovery参数
};

如果BCB里的命令是boot-recovery，Bootloader就会加载recovery分区，而不是正常的boot分区。这就是Recovery模式的启动原理。

我的经验：调试Recovery启动问题时，第一步就是检查BCB内容。我曾经花了两天时间排查一个Recovery进不去的问题，最后发现是BCB被意外清空了。用cat /misc看看BCB内容，往往能快速定位问题。

1.2.2 核心执行逻辑

Recovery模式启动后，会做以下几件事：

挂载分区——把/system、/data、/cache等分区挂载起来
读取命令——从/cache/recovery/command文件或BCB中读取要执行的操作
执行操作——根据命令执行升级、擦除、备份等任务
写入日志——把执行结果写到/cache/recovery/last_log
重启系统——完成后清除BCB，重启进入主系统

为什么会这样设计？因为Recovery模式本身不能长时间运行，它就是个「临时工」。干完活就走，不拖泥带水。

1.2.3 升级流程详解

以OTA升级为例，Recoory模式的工作流程是这样的：

步骤	操作	说明
1	校验升级包	检查签名、哈希值，防止篡改
2	解压升级包	把payload.bin解压到临时目录
3	执行升级脚本	按updater-script的指令逐个分区写入
4	更新BCB	标记升级状态，防止断电后变砖
5	重启	进入新系统

注意：升级过程中如果断电，Recovery模式会通过BCB记录当前进度。下次启动时继续执行，而不是从头开始。这个机制叫「断点续传」，我曾在某款低端机上遇到过BCB实现有bug，导致每次断电都从头刷……那体验，别提了。

1.3 Recovery模式在Android系统中的位置

从分区布局来看，Recovery模式占据一个独立的分区。典型的Android分区布局是这样的：

分区布局（按启动顺序）：
+------------------+
| bootloader       |  ← 引导加载程序
+------------------+
| boot             |  ← 内核 + ramdisk（主系统）
+------------------+
| recovery         |  ← 内核 + ramdisk（Recovery系统）
+------------------+
| system           |  ← Android系统文件
+------------------+
| data             |  ← 用户数据
+------------------+
| cache            |  ← 缓存和升级包存放
+------------------+
| misc             |  ← BCB存储区
+------------------+

你看，recovery分区和boot分区是平级的。它们都包含一个Linux内核和一个ramdisk文件系统。区别在于：

boot分区：启动完整的Android系统，包含init进程、Zygote、SystemServer等
recovery分区：启动精简的Recovery系统，只包含recovery程序、minui、minadbd等

我个人的习惯是，把Recovery模式看作Android系统的「第三层」：

第一层：Bootloader——硬件初始化，选择启动哪个分区
第二层：Recovery——系统维护和修复
第三层：Android——用户日常使用的完整系统

这三层是递进关系。上一层挂了，下一层还能救。但Recovery模式如果也挂了……嗯，那就只能上刷机工具或者售后了。

避坑指南：我曾经在定制Recovery时，不小心把内核编译错了，导致Recovery分区无法启动。结果手机变砖，只能拆机用SP Flash Tool重刷。所以我的建议是——在修改Recovery之前，先用dd命令备份原始recovery分区：

adb shell
su
dd if=/dev/block/by-name/recovery of=/sdcard/recovery_backup.img

这个习惯救过我很多次。

1.4 小结

Recovery模式说白了就是Android系统的「安全网」。它独立于主系统运行，负责执行那些主系统不能或不敢做的操作——比如擦除数据、刷写固件、修复系统。

理解Recovery模式的工作原理，关键要抓住三点：

独立分区——recovery分区和boot分区平级，互不依赖
BCB驱动——通过misc分区的BCB与Bootloader通信
脚本驱动——所有操作由updater-script控制，可编程可定制

📚 课程目录

1. Recovery模式概述：Recovery模式是什么、Recovery模式的工作原理、Recovery模式在Android系统中的位置

1.1 Recovery模式到底是什么？

1.2 Recovery模式的工作原理

1.2.1 启动流程

1.2.2 核心执行逻辑

1.2.3 升级流程详解

1.3 Recovery模式在Android系统中的位置

1.4 小结