Android OTA升级原理和流程分析（一） --update.zip包的制作

Android OTA升级原理和流程分析（一）–update.zip包的制作

  这篇及以后的篇幅将通过分析update.zip包在具体Android系统升级的过程，来理解Android系统中Recovery模式服务的工作原理。我们先从update.zip包的制作开始，然后是Android系统的启动模式分析，Recovery工作原理，如何从我们上层开始选择system update到重启到Recovery服务，以及在Recovery服务中具体怎样处理update.zip包升级的，我们的安装脚本updater-script怎样被解析并执行的等一系列问题。分析过程中所用的Android源码是MT8167O平台，公司今年主要是开发Android8.1系统，因此主要平台是这个。这是在工作中总结的文档，当然在网上参考了不少内容，如有雷同纯属巧合吧，在分析过程中也存在很多未解决的问题，也希望大家不吝指教。

一、 update.zip包的目录结构，主要研究的是OTA差分包，与Full OTA 包类似
|—-META-INF
   |—-com
|—-patch
   |—-boot.img.p
|—-lk.img
|—-odmdtbo.img
|—-scatter.txt
|—-system.new.dat
|—-system.patch.dat
|—-system.transfer.list
|—-tee.img
|—-type.txt
|—-vendor.new.dat
|—-vendor.patch.dat
|—-vendor.transfer.list

二、 update.zip包目录结构详解
  以上是我们用命令make otapackage 制作的update.zip包的标准目录结构。
  差分包的命令： ./build/tools/releasetools/ota_from_target_files -s ./vendor/mediatek/proprietary/scripts/releasetools/mt_ota_from_target_files.py –block -i OLDMID_PACKAGE.zip MID_PACKAGE.zip OTA_PACKAGE_NAME.zip
  1、boot.img是更新boot分区所需要的文件。这个boot.img主要包括kernel+ramdisk。
   2、system/目录的内容在升级后会放在系统的system分区。主要用来更新系统的一些应用或则应用会用到的一些库等等。可以将Android源码编译out/target/product/tcc8800/system/中的所有文件拷贝到这个目录来代替。
  3、recovery/目录中的recovery-from-boot.p是boot.img和recovery.img的补丁(patch),主要用来更新recovery分区，其中etc/目录下的install-recovery.sh是更新脚本。
  4、update-binary是一个二进制文件，相当于一个脚本解释器，能够识别updater-script中描述的操作。该文件在Android源码编译后out/target/product/tcc8800/system bin/updater生成，可将updater重命名为update-binary得到。
  该文件在具体的更新包中的名字由源码中bootable/recovery/install.c中的宏ASSUMED_UPDATE_BINARY_NAME的值而定。
   5、updater-script：此文件是一个脚本文件，具体描述了更新过程。我们可以根据具体情况编写该脚本来适应我们的具体需求。该文件的命名由源码中bootable/recovery/updater/updater.c文件中的宏SCRIPT_NAME的值而定。
  6、 metadata文件是描述设备信息及环境变量的元数据。主要包括一些编译选项，签名公钥，时间戳以及设备型号等。
  7、我们还可以在包中添加userdata目录，来更新系统中的用户数据部分。这部分内容在更新后会存放在系统的/data目录下。
   8、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 。

   我们用命令make otapackage制作生成的update.zip包是已签过名的，如果自己做update.zip包时必须手动对其签名。

具体的加密方法：$ java –jar gingerbread/out/host/linux/framework/signapk.jar –w gingerbread/build/target/product/security/testkey.x509.pem gingerbread/build/target/product/security/testkey.pk8 update.zip update_signed.zip
   以上命令在update.zip包所在的路径下执行，其中signapk.jar testkey.x509.pem以及testkey.pk8文件的引用使用绝对路径。update.zip 是我们已经打好的包，update_signed.zip包是命令执行完生成的已经签过名的包。
   9、MANIFEST.MF：这个manifest文件定义了与包的组成结构相关的数据。类似Android应用的mainfest.xml文件。
  10、CERT.RSA：与签名文件相关联的签名程序块文件，它存储了用于签名JAR文件的公共签名。
  11、CERT.SF：这是JAR文件的签名文件，其中前缀CERT代表签名者。
另外，在具体升级时，对update.zip包检查时大致会分三步：①检验SF文件与RSA文件是否匹配。②检验MANIFEST.MF与签名文件中的digest是否一致。③检验包中的文件与MANIFEST中所描述的是否一致。
三、 Android升级包update.zip的生成过程分析
  1) 对于update.zip包的制作有两种方式，即手动制作和命令生成。

第一种手动制作：即按照update.zip的目录结构手动创建我们需要的目录。然后将对应的文件拷贝到相应的目录下，比如我们向系统中新加一个应用程序。可以将新增的应用拷贝到我们新建的update/system/app/下（system目录是事先拷贝编译源码后生成的system目录），打包并签名后，拷贝到SD卡就可以使用了。这种方式在实际的tcc8800开发板中未测试成功。签名部分未通过，可能与具体的开发板相关。

第二种制作方式：命令制作。Android源码系统中为我们提供了制作update.zip刷机包的命令，即make otapackage。该命令在编译源码完成后并在源码根目录下执行。 具体操作方式：在源码根目录下执行

            ①$ . build/envsetup.sh。 

            ②$ lunch 然后选择你需要的配置(如17)。

            ③$ make otapackage。

在编译完源码后最好再执行一遍上面的①、②步防止执行③时出现未找到对应规则的错误提示。命令执行完成后生成的升级包所在位置在out/target/product/full_tcc8800_evm_target_files-eng.mumu.20120309.111059.zip将这个包重新命名为update.zip，并拷贝到SD卡中即可使用。

这种方式(即完全升级)在tcc8800开发板中已测试成功。

2) 使用make otapackage命令生成update.zip的过程分析。
在源码根目录下执行make otapackage命令生成update.zip包主要分为两步，第一步是根据Makefile执行编译生成一个update原包（zip格式）。第二步是运行一个python脚本，并以上一步准备的zip包作为输入，最终生成我们需要的升级包。下面进一步分析这两个过程。
第一步：编译Makefile。对应的Makefile文件所在位置：build/core/Makefile。从该文件的884行（tcc8800,gingerbread0919）开始会生成一个zip包，这个包最后会用来制作OTA package 或者filesystem image。先将这部分的对应的Makefile贴出来如下：