Recovery模式指的是一种可以对安卓机内部的数据或系统进行修改的模式（类似于windows PE或DOS）。也可以称之为安卓的恢复模式，在这个所谓的恢复模式下，我们可以刷入新的安卓系统，或者对已有的系统进行备份或升级，也可以在此恢复出厂设置（格式化数据和缓存）。

• Recovery： Recovery模式指的是一种可以对安卓机内部的数据或系统进行修改的模式，也指Android的Recovery分区
• OTA: Over－the－Air Technology，即空中下载技术，是 Android 系统提供的标准软件升级方式。 它功能强大，提供了完全升级、增量升级模式，可以通过 SD 卡升级，也可以通过网络升级。不管是哪种方式，都有几个过程：生成升级包、下载升级包、安装升级包。
• Recoverysystem：Android系统内部实现的一个工具类，Android应用层操作Recovery模式的一个重要途径，它提供了几个重要的API，用于实现OTA包校验、升级以及恢复出厂设置（格式化数据和缓存）。
• Main System：主系统模式，即Android正常开机所进入的Android系统
• Bootloader：Bootloader是嵌入式系统在加电后执行的第一段代码，在它完成CPU和相关硬件的初始化之后，再将操作系统映像或固化的嵌入式应用程序装在到内存中然后跳转到操作系统所在的空间，启动操作系统运行。
• BCB：Bootloader Control Block，启动控制信息块，位于misc分区，从代码上看，就是一个结构体。

一般来说，安卓手机和平板一般包括以下标准内部分区：

Boot：包含Linux内核和一个最小的root文件系统（装载到ramdisk中），用于挂载系统和其他的分区，并开始Runtime。正如名字所代表的意思（注：boot的意思是启动），这个分区使Android设备可以启动。如果没有这个分区，Android设备通常无法启动到Android系统。

System：这个分区几乎包含了除kerner和ramdisk之外的整个android操作系统，包括了用户界面、和所有预装的系统应用程序和库文件（AOSP中可以获取到源代码）。在运行的过程中，这个分区是read-only的。当然，一些Android设备，也允许在remount的情况下，对system分区进行读写。 擦除这个分区，相当于删除整个安卓系统，会导致不能进入Main System, 但不会影响到Recovery。因此，可以通过进入Recovery程序或者bootloader程序中，升级安装一个新ROM。

Userdata：用户数据区，用户安装的应用程序会把数据保存在这里，包含了用户的数据：联系人、短信、设置、用户安装的程序。擦除这个分区，本质上等同于手机恢复出厂设置，也就是手机系统第一次启动时的状态，或者是最后一次安装官方或第三方ROM后的状态。在Recovery程序中进行的“data/factory reset ”操作就是在擦除这个分区。正常情况下OTA是不会清除这里的数据的，指定要删除数据的除外。

Cache：系统缓存区，临时的保存应用数据（要把数据保存在这里，需要特地的app permission）, OTA的升级包也可以保存在这里。OTA升级过程可能会清楚这个分区的数据。一般来讲，Android差分包升级也需要依赖此分区存放一些中间文件。

Recovery：包括了一个完整Linux内核和一些特殊的recovery binary，可以读取升级文件用这些文件来更新其他的分区。

Misc：一个非常小的分区，4 MB左右。recovery用这个分区来保存一些关于升级的信息，应对升级过程中的设备掉电重启的状况，Bootloader启动的时候，会读取这个分区里面的信息，以决定系统是否进Recovery System 或 Main System。

以上几个分区是Google官方的标准，对于第三方Android设备厂商来讲，分区的情况可能稍微不一样，比如Rockchip平台，还增加了user分区、kernel分区和backup分区。其中：

kernel：顾名思义，是存放kernel.img镜像的。在boot分区里面的kernel内核镜像损坏的情况下（比如flash损坏），bootloader会尝试加载kerner分区里面的内核镜像。

backup：存放整个系统镜像（update.img）, 可用于恢复设备到出厂ROM。

user: 用户分区，也就是平时我们所说的内置sdcard。另外还有外置的sdcard分区，用于存放用户相片、视频、文档、ROM安装包等。

一般来讲，Android有三种启动模式：Fastboot模式，Recovery System 以及Main System。

• Fastboot：在这种模式下，可以修改手机的硬件，并且允许我们发送一些命令给Bootloader。如使用电脑刷机，则需要进入fastboot模式，通过电脑执行命令将系统镜像刷到通过USB刷到Android设备中中。
• Recovery：Recovery是一个小型的操作系统，并且会加载部分文件系统，这样才能从sdcard中读取升级包。
• Main System: 即我们平时正常开机后所使用的手机操作系统模式

首先说一下，正常启动和进入Recovery的区别，一图以概之：

一般来讲，进入recovery有两种方式，一种是通过组合键进入recovery，按键指引的方式，各个Android平台都不一样，比如三星的手机是在关机状态下同时按住【音量上】、【HOME键】、【电源键】，等待屏幕亮起后即可放开，进入Recovery模式。而Rockchip的机顶盒，则是使用按【Reset键】加【电源键】开机的方式，形式不一。

另一种，则是使用系统命令启动到Recovery模式的，这对绝大部分Android设备是通用的：

reboot recovery 3. Recovery升级原理3.1 应用层升级流程

在Android应用层部分，OTA系统升级流程。大概的流程图如下所示：

以上部分，只介绍了应用层层面的 ota升级包的下载、校验以及最后的发起安装过程。在这里，重要讲解进入Recovery模式后，OTA包的升级过程。

首先，在应用层下载升级包后，会调用RecoverySystem.installPackage(Context context, File packageFile)函数来发起安装过程，这个过程主要的原理，实际上只是往 /cache/recovery/command 写入ota升级包存放路径，然后重启到recovery模式，仅此而已。

public static void installPackage(Context context, File packageFile) throws IOException { String filename = packageFile.getCanonicalPath(); Log.w(TAG, "!!! REBOOTING TO INSTALL " filename " !!!"); final String filenameArg = "--update_package=" filename; final String localeArg = "--locale=" Locale.getDefault().toString(); bootCommand(context, filenameArg, localeArg); } private static void bootCommand(Context context, String... args) throws IOException { RECOVERY_DIR.mkdirs(); // In case we need it COMMAND_FILE.delete(); // In case it's not writable LOG_FILE.delete(); FileWriter command = new FileWriter(COMMAND_FILE); try { for (String arg : args) { if (!TextUtils.isEmpty(arg)) { command.write(arg); command.write("\n"); } } } finally { command.close(); } // Having written the command file, go ahead and reboot PowerManager pm = (PowerManager) context.getSystemService(Context.POWER_SERVICE); pm.reboot(PowerManager.REBOOT_RECOVERY); throw new IOException("Reboot failed (no permissions?)"); }

因此，实质上等同于以下命令：

echo -e "--update_package=/mnt/sdcard/ota/update.zip" > /cache/recovery/command reboot recovery 3.2 OTA升级包的目录结构

OTA升级包的目录结构大致如下所示：

|----boot.img |----system/ |----recovery/ |----recovery-from-boot.p |----etc/ `|----install-recovery.sh |---META-INF/ |CERT.RSA |CERT.SF |MANIFEST.MF |----com/ |----google/ |----android/ |----update-binary |----updater-script |----android/ |----metadata

其中：

• boot.img 是更新boot分区所需要的镜像文件。这个boot.img主要包括kernel、ramdisk。
• system/目录的内容在升级后会放在系统的system分区，主要是系统app,library和binary二进制文件
• update-binary是一个二进制文件，相当于一个脚本解释器，能够识别updater-script中描述的操作。
• updater-script：此文件是一个脚本文件，具体描述了更新过程。
• metadata文件是描述设备信息及环境变量的元数据。主要包括一些编译选项，签名公钥，时间戳以及设备型号等。
• 我们还可以在包中添加userdata目录，来更新系统中的用户数据部分。这部分内容在更新后会存放在系统的/data目录下。
• update.zip包的签名：update.zip更新包在制作完成后需要对其签名，否则在升级时会出现认证失败的错误提示。而且签名要使用和目标板一致的加密公钥。默认的加密公钥及加密需要的三个文件在Android源码编译后生成的具体路径为：

out/host/linux-x86/framework/signapk.jar

build/target/product/security/testkey.x509.pem

build/target/product/security/testkey.pk8

• MANIFEST.MF：这个manifest文件定义了与包的组成结构相关的数据。类似Android应用的mainfest.xml文件。
• CERT.RSA：与签名文件相关联的签名程序块文件，它存储了用于签名JAR文件的公共签名。
• CERT.SF：这是JAR文件的签名文件，其中前缀CERT代表签名者。

进入Recovery模式之后，便开始对下载的升级包进行升级，整体的流程图如下所示：

BCB（Bootloader与Recovery通过BCB（Bootloader Control Block）通信）

这里，详解介绍一下升级流程中的各个模块。

get_args的原理流程图如下所示：

get_args()函数的主要作用是获取系统的启动参数，并回写到bootloader control block（BCB）块中。如果系统在启动recovery时已经传递了启动参数，那么这个函数只是把启动参数的内容复制到函数的参数boot对象中，否则函数会首先通过get_bootloader_message()函数从/misc分区的BCB中获取命令字符串来构建启动参数。如果/misc分区下没有内容，则会尝试解析/cache/recovery/command文件并读取文件的内容来建立启动参数。

接着，会把启动参数的信息通过set_bootloader_message()函数又保存到了BCB块中。这样做的目的是防止一旦升级或擦除数据的过程中发生崩溃或不正常断电，下次重启，Bootloader会依据BCB的指示，引导进入Recovery模式，从/misc分区中读取更新的命令，继续进行更新操作。因此，可以说是一种掉电保护机制。

get_args具体的流程如下图所示：