分析Recovery流程，可从分析升级包入手。
升级包可由 make otapackage命令生成，由Makefile和打包脚本(Python)配合生成。
生成规则比较复杂，其中包含了签名过程，细节不表，主要关注它的内容。
升级包解压后结构如下：
/home/simba/update_zip|-- boot.img|-- Manifest.xml|-- META-INF| |-- CERT.RSA| |-- CERT.SF| |-- com| | |-- android| | | `-- metadata| | `-- google| | `-- android| | |-- update-binary| | `-- updater-script| `-- MANIFEST.MF|-- recovery| |-- etc| | `-- install-recovery.sh| `-- recovery-from-boot.p`-- system |-- app |-- bin |-- build.prop |-- etc |-- fonts |-- framework |-- lib |-- media |-- usr `-- xbin66 directories, 1025 files
以上结构图中省略了很多条目，都是system目录下的文件和目录。
其中重要的脚本文件有：
- META-INF/com/google/android/updater-script
- recovery/etc/install-recovery.sh
- boot.img
- /system
- recovery/recovery-from-boot.p
另一个很重要的文件是/etc/recovery.fstab，内容由EMMC分区方案确定。
-------- /etc/recovery.fstab -----------/boot emmc /dev/block/mmcblk0p1/sdcard vfat /dev/block/mmcblk0p4/recovery emmc /dev/block/mmcblk0p2/system ext4 /dev/block/mmcblk0p5/cache ext4 /dev/block/mmcblk0p6/data ext4 /dev/block/mmcblk0p7/misc emmc /dev/block/mmcblk0p9--------------------------------------------
otgpackage编译脚本会根据这个文件填充updater-script，后面可以看到。
这个文件存在于recovery分区中，进入recovery模式后，可以访问到它。
进入recovery模式的方式多种多样，但每种方式都需要bootloader的配合。
进入recovery模式后会对升级包进行验证，过程不表，失败退出。
进入recovery流程后，主要关心updater-script的工作。
首先是updater-script，代码中可以很容易分析出他的工作流程，如下：
--------- updater-script ----------------.... //省略若干format("ext4", "EMMC", "/dev/block/mmcblk0p5", "0");mount("ext4", "EMMC", "/dev/block/mmcblk0p5", "/system"); //挂载system分区。这里有"/dev/block/mmcblk0p5"和"/system"的对应关系，来源于前文提到的recovery.fstab。package_extract_dir("recovery", "/system"); //将zip包中的recovery目录解压到系统/system目录，将来升级recovery分区时使用（install-recovery.sh，recovery-from-boot.p）package_extract_dir("system", "/system"); //将zip包中的system目录解压到系统/system目录，完成system分区的升级...... //省略若干symlink("mksh", "/system/bin/sh");symlink("toolbox", "/system/bin/cat", ....); //创建软链接，省略若干retouch_binaries("/system/lib/libbluedroid.so", .....); //再摸一下各种动态库，省略若干set_perm_recursive(0, 0, 0755, 0644, "/system");...... //修改权限，省略若干show_progress(0.200000, 0); //显示升级进度...... //修改权限，省略若干package_extract_file("boot.img", "/dev/block/mmcblk0p1"); //将boot.img解压到相应block设备，完成boot分区的升级。boot分区包含了kernel + ramdiskshow_progress(0.100000, 0);unmount("/system"); //卸载system分区---------------------------------------------system分区和boot升级完成，接下来重启，进入正常系统。
正常启动的系统init.rc中定义了一个用于烧写recovery分区的服务，也就是执行install-recovery.sh，每次启动都要执行一次。
----- /init.rc ------ ... service flash_recovery /system/etc/install-recovery.sh class main oneshot ...--------------------
install-recovery.sh 是recovery模式中updater-script解压出来的，内容如下：
------- /system/etc/install-recovery.sh ----#!/system/bin/sh log -t recovery "Before sha1.... Simba...."if ! applypatch -c EMMC:/dev/block/mmcblk0p2:4642816:c125924fef5a1351c9041ac9e1d6fd1f9738ff77; then log -t recovery "Installing new recovery image__From Simba..." applypatch EMMC:/dev/block/mmcblk0p1:3870720:aee24fadd281e9e2bd4883ee9962a86fc345dcab EMMC:/dev/block/mmcblk0p2 c125924fef5a1351c9041ac9e1d6fd1f9738ff77 4642816 aee24fadd281e9e2bd4883ee9962a86fc345dcab:/system/recovery-from-boot.pelse log -t recovery "Recovery image already installed__From Simba..."fi-------------------------------------------
执行 make otapackage命令时，编译脚本比较boot.img和recovery.img得出patch文件recovery-from-boot.p。
recovery-from-boot.p也是在recovery模式中updater-script解压到system目录的。
install-recovery.sh脚本就是使用这个patch加上boot分区，更新recovery分区。
应用patch前，install-recovery.sh会计算当前recovery分区的sha1。
若计算结果与脚本中记录的相同（c125924fef5a1351c9041ac9e1d6fd1f9738ff77），说明已经更新过了，不再操作。这样就完成了/system目录，boot分区(kernel + ramdisk)，recovery分区(kernel + ramdisk-recovery)的升级。
以上是标准的Android升级流程，我们自己添加的分区可以参考以上几种方式实现。自定义的分区采用何种升级方式需要细细考量，关系到升级包的内容结构和签名过程。