Android 4.0 OTA 升级过程概述

分析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
`-- xbin

66 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 + ramdisk

show_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.p
else
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升级流程，我们自己添加的分区可以参考以上几种方式实现。自定义的分区采用何种升级方式需要细细考量，关系到升级包的内容结构和签名过程。