在讲解recovery升级前先介绍几个相关概念
Recovery： Recovery首先可以指Android的Recovery分区，同时也可以说是一种可以对安卓机内部的数据或系统进行修改的模式，进入该模式可以升级新的Android
OTA: Over－the－Air Technology，即空中下载技术，是 Android 系统提供的标准软件升级方式。 它功能强大，提供了完全升级、增量升级模式，可以通过 SD 卡升级，也可以通过网络升级。不管是哪种方式，都有几个过程：生成升级包、下载升级包、安装升级包。
RecoveryFs：是Recovery对应挂载的文件系统，该文件系统内部实现了一个工具类，它提供了几个重要的API供Android应用层使用，用于实现OTA包校验、升级以及恢复出厂设置（格式化数据和缓存）。
System：即是根文件系统，是进入正常启动模式时挂载的系统，即Android正常开机所进入的Android系统
Bootloader：Bootloader是嵌入式系统在加电后执行的第一段代码，在它完成CPU和相关硬件的初始化之后，再将操作系统映像或固化的嵌入式应用程序装在到内存中然后跳转到操作系统所在的空间，启动操作系统运行。
Misc： Android存放启动控制信息块(Bootloader Control Block)，从代码上看，就是一个结构体。
应用层进入Recovery升级模式流程：
在应用层升级下载升级包后，将升级包拷贝到/cache/下，然后往 /cache/recovery/command 写入ota升级包存放路径“--update_package=/cache/update_ota.zip”，最后通过reboot recovery即进入recovery升级模式，开始安装升级包。
在Recovery安装升级包流程：
1. get_args(&argc, &argv)
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函数核心代码如下：
static void get_args(int *argc, char ***argv) {
struct bootloader_message boot;
memset(&boot, 0, sizeof(boot));
//解析BCB模块
get_bootloader_message(&boot); // this may fail, leaving a zeroed structure
......
// --- if that doesn't work, try the command file
if (*argc <= 1) {
FILE *fp = fopen_path(COMMAND_FILE, "r");//COMMAND_FILE指/cache/recovery/command
if (fp != NULL) {
char *argv0 = (*argv)[0];
*argv = (char **) malloc(sizeof(char *) * MAX_ARGS);
(*argv)[0] = argv0; // use the same program name
char buf[MAX_ARG_LENGTH];
for (*argc = 1; *argc < MAX_ARGS; ++*argc) {
if (!fgets(buf, sizeof(buf), fp)) break;
(*argv)[*argc] = strdup(strtok(buf, "\r\n")); // Strip newline.
}
check_and_fclose(fp, COMMAND_FILE);
LOGI("Got arguments from %s\n", COMMAND_FILE);
}
}
......
set_bootloader_message(&boot); //回写BCB
这里需要说一下“BCB”，即bootloader control block, 中文可以呼之为“启动控制模信息块”，位于/misc分区，从代码上看，就是一个struct 结构体 :
struct bootloader_message {
char command[32];
char status[32];
char recovery[1024];
}; bootloader_message 结构体包含三个字段，具体含义如下：
command 字段中存储的是命令，它有以下几个可能值：
* boot-recovery：系统将启动进入Recovery模式
* update-radia 或者 update-hboot：系统将启动进入更新firmware的模式，这个更新过程由bootloader完成
* NULL：空值，系统将启动进入Main System主系统，正常启动。
status 字段存储的是更新的结果。更新结束后，由Recovery或者Bootloader将更新结果写入到这个字段中。
recovery 字段存放的是recovry模块的启动参数，一般包括升级包路径。其存储结构如下：第一行存放字符串“recovery”,第二行存放路径信息“–update_package=/mnt/sdcard/update.zip”等。 因此，参数之间是以“\n”分割的。
2. update_package
ota升级包的存放路径，从BCB或者/cache/recovery/command里面解析得到的，升级包一般下载后存放在cache或sdcard分区，当然，也有一些是存放到U盘之类的外接存储设备中的。一般赋值格式如下：
--update_package=/mnt/sdcard/update.zip 或 --update_package=CACHE:update.zip3. int install_package (const char* path, int* wipe_cache, const char* install_file)
install_package函数所实现的功能为：调用really_install_package函数进行ota升级，并将升级结果写入到文件install_file（/cache/recovery/last_install）中。当升级完成后进入main system，可以通过此文件读取升级结果，并给出用户相应的提示：比如升级成功或失败。
int install_package(const char* path, int* wipe_cache, const char* install_file)
{
//install_file 为 /cache/recovery/last_install
FILE* install_log = fopen_path(install_file, "w");
if (install_log) {
fputs(path, install_log);
fputc('\n', install_log);
} else {
LOGE("failed to open last_install: %s\n", strerror(errno));
}
int result = really_install_package(path, wipe_cache);
if (install_log) {
fputc(result == INSTALL_SUCCESS ? '1' : '0', install_log);
fputc('\n', install_log);
fclose(install_log);
}
return result;
}
4. static int really_install_package(const char path, int wipe_cache)
really_install_package函数在install_package函数中被调用，函数的主要作用是调用ensure_path_mounted确保升级包所在的分区已经挂载，另外，还会对升级包进行一系列的校验，
在具体升级时，对update.zip包检查时大致会分三步：
检验SF文件与RSA文件是否匹配；
检验MANIFEST.MF与签名文件中的digest是否一致；
检验包中的文件与MANIFEST中所描述的是否一致
通过校验后，调用try_update_binary函数去实现真正的升级。
5. static int try_update_binary(const char path, ZipArchive *zip, int wipe_cache)
try_update_binary是真正实现对升级包进行升级的函数：
static int try_update_binary(const char *path, ZipArchive *zip, int* wipe_cache) {
const ZipEntry* binary_entry = mzFindZipEntry(zip, ASSUMED_UPDATE_BINARY_NAME);
......
const char* binary = "/tmp/update_binary";
unlink(binary);
int fd = creat(binary, 0755);
.....
//将升级包里面的update_binary解压到/tmp/update_binary
bool ok = mzExtractZipEntryToFile(zip, binary_entry, fd);
close(fd);
mzCloseZipArchive(zip);
......
int pipefd[2];
pipe(pipefd);
const char** args = (const char**)malloc(sizeof(char*) * 5);
args[0] = binary; //update_binary存放路径
args[1] = EXPAND(RECOVERY_API_VERSION); // Recovery版本号
char* temp = (char*)malloc(10);
sprintf(temp, "%d", pipefd[1]);
args[2] = temp;
args[3] = (char*)path; //升级包存放路径
args[4] = NULL;
pid_t pid = fork();//fork一个子进程
if (pid == 0) {
close(pipefd[0]);
//子进程调用update-binary执行升级操作
execv(binary, (char* const*)args);
fprintf(stdout, "E:Can't run %s (%s)\n", binary, strerror(errno));
_exit(-1);
}
......
int status;
waitpid(pid, &status, 0);
if (!WIFEXITED(status) || WEXITSTATUS(status) != 0) {
//安装失败，返回INSTALL_ERROR
return INSTALL_ERROR;
}
//安装成功，返回INSTALL_SUCCESS
return INSTALL_SUCCESS;
}总的来说，try_update_binary主要做了以下几个操作：
（1）mzOpenZipArchive（）：打开升级包，并将相关的信息拷贝到一个临时的ZipArchinve变量中。注意这一步并未对我们的update.zip包解压。
（2）mzExtractZipEntryToFile（）： 解压升级包特定文件，将升级包里面的META-INF/com/google/android/update-binary 解压到内存文件系统的/tmp/update_binary中。
（3）fork创建一个子进程 ， 使用系统调用函数execv( ) 去执行/tmp/update-binary程序，
（4）update-binary： 这个是Recovery OTA升级的核心程序，是一个二进制文件，实现代码位于系统源码bootable/recovery/updater。其实质是相当于一个脚本解释器，能够识别updater-script中描述的操作并执行。
（5）updater-script：updater-script是我们升级时所具体使用到的脚本文件，具体描述了更新过程，它主要用以控制升级流程的主要逻辑。具体位置位于升级包中/META-INF/com/google/android/update-script，在我们制作升级包的时候产生。在升级的时候，由update_binary程序从升级包里面解压到内存文件系统的/tmp/update_script中，并按照update_script里面的命令，对系统进行升级。比如，一个完整包升级的update_script的内容大致如下所示：
assert(getprop("ro.product.device") == "rk31sdk" ||
getprop("ro.build.product") == "rk301dk");
show_progress(0.500000, 0);
format("ext4", "EMMC", "/dev/block/mtd/by-name/system", "0", "/system");
mount("ext4", "EMMC", "/dev/block/mtd/by-name/system", "/system");
package_extract_dir("recovery", "/system");
package_extract_dir("system", "/system");
symlink("Roboto-Bold.ttf", "/system/fonts/DroidSans-Bold.ttf");
symlink("mksh", "/system/bin/sh");
......
set_perm_recursive(0, 0, 0755, 0644, "/system");
set_perm_recursive(0, 2000, 0755, 0755, "/system/bin");
......
set_perm(0, 0, 06755, "/system/xbin/su");
set_perm(0, 0, 06755, "/system/xbin/tcpdump");
show_progress(0.200000, 0);
show_progress(0.200000, 10);
write_raw_image(package_extract_file("boot.img"), "boot");
show_progress(0.100000, 0);
clear_misc_command();
unmount("/system");
因此，根据上面的升级脚本，可以知道，升级包的大致升级流程如下：
判断是不是升级包是否适用于该设备，如果不适用，则停止升级，否则继续。
显示进度条
格式化system分区
挂载system分区
将ota升级包里面的system、recovery目录解压到system分区
建立一些软链接，升级过程需要用到
设置部分文件权限
将升级包里面的boot.img写入到/boot分区
清空misc分区，即BCB块置为NULL
卸载system分区
6. wipe data/cache
main函数，在执行完install_package后，会根据传入的wipe_data/wipe_cache，决定是否执行/data和/cache分区的清空操作。
7. prompt_and_wait
这个函数的作用就是一直在等待用户输入，是一个不断的循环，可以选择Recovery模式下的一些选项进行操作，包括恢复出厂设置和重启等。如果升级失败， prompt_and_wait会显示错误，并等待用户响应。
8. finish_recovery
OTA升级成功，清空misc分区（BCB置零），并将保存到内存系统的升级日志/tmp/recovery.log保存到/cache/recovery/last_log。重启设备进入Main System，升级完成。
9. install-recovery.sh
从上面的流程中，可以知道，Recovery模式下的OTA升级成功，只是更新了/system和/boot两个最核心的分区，而本身用来升级的Recovery自身并没有在那个时候得到更新。Recovery分区的更新，是在重启进入主系统的时候，由install-recovery.sh来更新的。这样可以保证，即使升级失败，Recovery模式也不会受到影响，仍然可以手动进入Recovery模式执行升级或擦除数据操作。
在Recovery升级的时候，有一句：
package_extract_dir("recovery", "/system");这条命令就是将升级包里面的recovery目录的内容，解压到/system分区
recovery目录下的文件，主要有install-recovery.sh和 recovery-from-boot.p，目录结构如下所示：
├── bin
│ └── install-recovery.sh
└── recovery-from-boot.p
其中：
recovery-from-boot.p 是boot.img和recovery.img的补丁(patch)
install-recovery.sh 则是来用安装recovery-from-boot.p的升级脚本, 主要是利用android系统的 applypatch 工具来打补丁。
至此，一个完整的OTA包升级就正式完成了！
