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

http://blog.csdn.net/ly890700/article/details/56048815

Android Recovery（30）

1、概述

OTA升级包制作工具是一个用python实现的命令行工具。工具位于source_root/

\build\tools\releasetools目录下，入口文件是ota_from_target_files。此工具可对编译生成的源或目标软件版本包进行处理，生成最终的OAT完整升级包（默认），或通过参数-i控制，生成OTA增量升级包（差分包）。

源或目标软件版本包的来源是通过向版本编译配置文件main.mk中添加编译OTA版本编译选项$(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) {