OTA升级包制作工具处理过程分析

OTA升级包制作工具处理过程分析

1、概述
OTA升级包制作工具是一个用python实现的命令行工具。工具位于source_root/ \build\tools\releasetools目录下，入口文件是ota_from_target_files。此工具可对编译生成的源或目标软件版本包进行处理，生成最终的OAT完整升级包（默认），或通过参数-i控制，生成OTA增量升级包（差分包）。
源或目标软件版本包的来源是通过向版本编译配置文件main.mk中添加编译OTA版本编译选项$(INTERNAL_OTA_PACKAGE_TARGET)来完成的。这个不在本文档中不做详细说明。
位置：
# Build files and then package it into the rom formats
# add to output $INTERNAL_OTA_PACKAGE_TARGET
.PHONY: droidcore
droidcore: files \
systemimage \
$(INSTALLED_BOOTIMAGE_TARGET) \
$(INSTALLED_RECOVERYIMAGE_TARGET) \
$(INSTALLED_USERDATAIMAGE_TARGET) \
$(INSTALLED_CACHEIMAGE_TARGET) \
$(INSTALLED_VENDORIMAGE_TARGET) \
$(INSTALLED_SYSTEMOTHERIMAGE_TARGET) \
$(INSTALLED_FILES_FILE) \
$(INSTALLED_FILES_FILE_VENDOR) \
$(INSTALLED_FILES_FILE_SYSTEMOTHER) \
$(INTERNAL_OTA_PACKAGE_TARGET)


2、运行环境
工具直接提供了python源码，需要在执行环境上安装python解析器（python运行环境，类似于java的JRE）。工具对python的版本做了要求，需要在2.4或更高以上的python版本上执行，否则可能会在处理过程中出错。
3、命令行参数
工具的命令行参数因版本不同有微小的变化，现列举一些常见参数说明：
-b  (--board_config)  <file>
在代码中用pass处理这一参数匹配，不做处理。
-k (--package_key) <key>
指定签名用的密钥。如果缺省，会从指定的源或目标版本包的META/misc_info.txt文件中获取，或使用"build/target/product/security/testkey"。对于制作增量升级包，默认的密钥是基于源版本包文件META/misc_info.txt中的指定的路径下的密钥对，而不是从目标版本包里的文件中获取，这点应该注意到。
-i  (--incremental_from)  <file>
-i参数后指定的zip将作为差分包制作的源版本包处理
-w  (--wipe_user_data)
生成在安装时擦除user date分区的升级包
-n  (--no_prereq)
忽略时间戳检查，用于开发过程中的OTA包的经常升降级
-e  (--extra_script)  <file>
在制作的升级包中的升级脚本中插入外部的脚本。
-a  (--aslr_mode)  <on|off>
指定是否打开升级包的aslr模式，默认为on状态
-p  (--path)  <dir>
指定一个路径，作为工具在运行过程中搜索二进制可执行文件的路径。在升级包制作中，我们一般指定/out/host/linux-x86目录，作为搜索签名工具的路径。
-f  (--fota) <fota>
指定是否使用 fota升级方式，默认为不使用。
4、制作增量或完整升级包
制作升级包时，需要在产品代码编译环境上进行。需要指定签名工具和密钥文件所在路径。其中，签名工具所在路径用参数-p指定，这个路径是/out/host/linux-x86。密钥文件所在路径可以不指定，这样会采用默认值，由工具自动从新旧升级包中的文件解析出来。
4.1 制作增量升级包
$Source_root/build/tools/releasetools/ota_from_target_files –p $soure_root/out/host/linux-x86 –i $old_OTA_zip $new_OTA_zip $Out_diff.zip
其中，-p $soure_root/out/host/linux-x86指定一个path,是工具处理过程中对签名工具的搜索范围目录
-I $old_OTA_zip $new_OTA_zip指定从$old_OTA_zip文件到$new_OTA_zip的增量升级包制作
最后的$Out_diff.zip指定输出的增量升级包文件路径和名称。
4.2 制作完整升级包
$Source_root/build/tools/releasetools/ota_from_target_files –p $soure_root/out/host/linux-x86 $new_OTA_zip $Out_full.zip
其中，只需要指定签名工具的搜索范围、新的版本包zip文件和输出的完整升级包的文件路径和名称。
5、工具处理过程
用文本编辑器或ecliipe等集成开发环境打开工具入口ota_from_target_files文件，可以看到，工具导入了和其在同一目录的其它两个模块common.py和edify_generator.py。其中，common.py中包含一些工具的通用处理过程，edify_generator.py放置recovery模式的脚本生成处理过程。
转跳到文件的末尾，if __name__ == ‘__main__’是代码入口，如下：

5.1 平台差异处理
首先调用Common.py模块中的common.CloseInheritedPipes()进行平台差异处理。由于在Mac OS上有file descriptor (PIPE) 泄露情况，所以先进行预处理。此过程对Windows或Linux平台不做处理，处理过程如下：
  if platform.system() != "Darwin":
    return
5.2 入参传递
main(sys.argv[1:])
在运行平台差异化处理后，调用main(sys.argv[1:])进入制作OAT包的处理过程。其中，main(sys.argv[1:])接受从命令行传入的所有参数。
5.3 参数解析处理
option_handler()、common.ParseOptions()
对命令行传入的参数分析处理，存储到OPTIONS.的全局变量中。如果参数个数不为2，将直接输出工具的文档字串，然后退出，如下：

5.4 载入外部脚本（参数-e处理）
如果有入参指定了外部脚本，则首先打开外部脚本待用。外部脚本文件将附加到增量升级包或完整升级包的安装脚本末尾。如下：

5.5 源或目标版本zip包解析
不管是进入增量升级包处理流程，还是完整升级包处理流程，都是先对目标版本包 (new_zip)进行解析，这是符合合理处理过程的流程。如果用户指定了-i参数，再对源版本包（old_zip）进行解析。
版本包解析后，会将结果存到变量OPTIONS. info_dict或OPTIONS. source_info_dictk中。这个数据结构体中存储的数据参考如下：

附 解析的OPTIONS. info_dict参考：

5.6 WriteFullOTAPackage()完整升级包处理过程
5.6.1 完整升级包处理假定
完整升级包的生成处理，存在一个问题：不确定上一版本的recovery_api_version，有可能很早。所以就假定recovery_api_version不会经常变动，否则将会影响正常升级。这一点在增量升级机制中是不存在的。
5.6.2 增量升级包中文件生成原则
包中其它文件生成过程是一个复制文件的和打包的过程：将system/下文件复制过输出zip包，获取boot.img,recovery.img打包的过程。
5.6.3 其它处理过程
包括生成完整升级包的安装脚本，文件大小超限判断等。升级脚本位于完整升级包zip文件\META-INF\com\google\androi\updater-script。
根据版本zip解析出的OPTIONS. info_dict里fstab/yaffs2，判断boot.img大小是否超限。
5.7 WriteIncrementalOTAPackage()增量升级包处理过程
5.7.1增量升级包处理

解压source 版本包，解析zip包中文件，将结果在存储到变量，此过程请参考5.5节。
5.7.2 相关参数处理
OPTIONS.package_key：获得密钥文件路径，如果用户不指定-k参数，将默认从source_zip包中的文件里提取。
OPTIONS.verbose：处理过程可见到STD_OUT。
5.7.3 增量升级包处理封装
WriteIncrementalOTAPackage(input_zip, source_zip, output_zip, OPTIONS.fota)
其中，Input_zip、source_zip、out_zip分别传入target_zip，source_zip和输出zip包对像的ID/地址，OPTIONS.fota指定fota模式的ture或false。
1、判断从源版本zip包中获得到的recovery_api_version值，如果为0，给出warning指示：

2、装载源和目标版本zip包中的system/目录下文件到内存文件对像待处理。


3、比较源和目标版本中的文件，分类处理，代码如下：

verbatim_targets = [] #存储不需要处理或必须原封不动地包含和保留的文件列表，这些需要保护的或不需要保护的文件在代码中可以指定，如下：

如果在此过程中，碰到需要保护的文件，就原封不动地添加到输出zip文件中。
diffs = [] #存储差异文件的列表，通过比较file.sha1值。如果sha1值不同，就附加到差异文件列表中，待后续处理。如果sha1值相同，则认为源版本zip中的此文件和目标版本zip中的相应文件是完全相同的。
4、计算上述差异列表中的文件之间的差异，生成并最终的差异文件（patch），这些文件都是以.p后缀名结尾的文件。这个封装里还会统计出生成patch的时候，patch文件与原文件的百分比大小，并将这些信息输出到STD_OUT上供用户参考。
差异文件处理入口：

差分文件生成封装：

输出到STD_OUT效果：

5、差异文件添加到增量升级包规则，如下：

如果差异文件不存在（None）即新增，或差异文件的与原文件相差不大（一定比例%95的阈值为判断标准），那这个文件将不做处理，也直接添加到将到生成的增量升级包中。
6、进入后续的其它处理，主要是增量升级脚本生成。最终生成的升级脚本可参考增量升级zip包\META-INF\com\google\android\updater-script。
5.8 关闭输出zip包和签名输出
关闭打开状态的输出增量升级包或完整升级，然后对其签名，输出到args[1]定义的目录位置。签名key位置由全局变量OPTIONS.package_key定义。处理过程下：


5.9 清理环境
清理在处理过程中用到的，生成的临时目录。
5.10 Done

OTA分析之updater

升级包里的updater-binary
1、OTA升级包中的updater-binary
2、Android_4.4/build/tools/releasetools/edify_generator.py中第283行

3、update-binary作为update-script的解析器，升级执行的实现

Recovery接受升级包简要流程：

1、进入到OTA ——手动通过recovery UI指定OTA升级包
   ——通过/cache/recovery/command入口文件指定OTA包
2、Recovery接受外部参数：recovery  --update-zip =/cache/update.zip –locale=lz_CN
3、Recovery进程进入升级包安装处理
4、Recovery进程从1022行开始处理update包

5、Recovery中安装逻辑开始之后的跳转
Recovery.cpp 1023：
status = install_package(update_package, &wipe_cache, TEMPORARY_INSTALL_FILE);
install.cpp 244:
result = really_install_package(path, wipe_cache);
install.cpp 226
return try_update_binary(path, &zip, wipe_cache);
install.cpp 48 真正执行update-binary解析update-script文件的时候
// If the package contains an update binary, extract it and run it.
static int
try_update_binary(const char *path, ZipArchive *zip, int* wipe_cache) {