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



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

    1、概述 
    OTA升级包制作工具是一个用python实现的命令行工具。工具位于source_root/ uild ools eleasetools目录下,入口文件是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-INFcomgoogleandroiupdater-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-INFcomgoogleandroidupdater-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) { 
  • 相关阅读:
    LifeRay学习记录
    jQuery选择器
    JavaScript中for..in循环陷阱
    Python课程回顾(day18)
    Python课程回顾(day17)
    Python课程回顾(day15)
    Python课程回顾(day14)
    Python课程回顾(day13)
    Python课程回顾(day12)
    Python课程回顾(day11)
  • 原文地址:https://www.cnblogs.com/pengmn/p/7259680.html
Copyright © 2020-2023  润新知