OTA制作及升级过程笔记

浅浅的花香味﹌ 2022-03-30 07:40 698阅读 0赞

# 1、概述 #

### 1.1   文档概要 ###

前段时间学习了AndroidRecovery模式及OTA升级过程，为加深理解和防止以后遗忘，所以写这篇文档进行一个总结和梳理，以便日后查阅回顾。文档主要包括两部分，第一部分为OTA升级包的制作过程分析，第二部分为Recovery模式下OTA升级包安装过程的分析，其中包括Recovery模式分析及服务流程。

### 1.2   参考文献 ###

《Recovery 开发指导》

[《Android系统Recovery工作原理之使用update.zip升级过程分析》][Android_Recovery_update.zip]

[《OTA本质与实现流程分析》][OTA]

《Android系统启动过程分析》

## 2、OTA升级包制作工程 ##

### 2.1  OTA升级简介 ###

所谓OTA（Over-the-AirTechnology）是指手机终端通过无线网络下载远程服务器上的升级包，对系统或应用进行升级的技术。有关网络部分不做过多讨论，本文重点放在系统升级这一概念上。

![20130608143749187][]

图1 某android手机存储设备结构图

以PC机进行类比，假设计算机操作系统装在C盘，当加电启动时，引导程序会将C盘的系统程序装入内存并运行，而系统升级或重装系统，则是将C盘中原来的系统文件部分或全部重写。对于手机及其上的Android系统而言，同样如此，需要一个存储系统文件的“硬盘”。

图1 是某款手机的存储设备结构图，其存储区（红色框图部分）分为四部分：SRAM、Nand Flash、SDRAM及外设地址空间。其中Nand Flash中存储着全部系统数据（通过专门的烧写工具将编译后的映象文件download到Nand Flash中，工具由IC厂商提供），包括boot.img、system.img、recovery.img等，因此Nand Flash即是上文所说的手机上的“硬盘”。图1最右部分（图中绿色框图部分）是Nand Flash存储区更详细的划分，我们将主要关注system分区（蓝色框图），因为OTA升级主要是对这部分系统数据的重写（当然boot分区也可升级）。除此之外，蓝黑色区域标示的misc分区也应值得注意，它在OTA升级中发挥着重要的作用。

OK，一言以蔽之，所谓OTA就是将升级包（zip压缩包）写入到系统存储区，因此我们需要考虑两个问题：1、升级包是如何生成的？2、升级包是如何写入到system分区的？

## 2.2  OTA升级包update.zip结构 ##

### 2.2.1、 update.zip包的目录结构 ###

|----boot.img

|----system/

|----recovery/

\`|----recovery-from-boot.p

\`|----etc/  
                       \`|----install-recovery.sh

|---META-INF/

\`|CERT.RSA

\`|CERT.SF

\`|MANIFEST.MF

\`|----com/

\`|----google/

\`|----android/

\`|----update-binary

\`|----updater-script

\`|----android/

\`|----metadata

### 2.2.2、 update.zip包目录结构详解 ###

以上是我们用命令makeotapackage 制作的update.zip包的标准目录结构。（和实际的略有不同）

1、boot.img是更新boot分区所需要的文件。这个boot.img主要包括kernel+ramdisk，包括应用会用到的一些库等等。可以将Android源码编译out/target/product/ xxxx /system/中的所有文件拷贝到这个目录来代替。

2、system/目录的内容在升级后会放在系统的system分区。主要用来更新系统的一些应用或则应用会用到的一些库等等。可以将Android源码编译out/target/product/xxxx/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/xxxx/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  -Xmx2048m -jar out/host/linux/framework/signapk.jar –w  build/target/product/security/testkey.x509.pem       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中所描述的是否一致。

12、在做的MTK平台的项目（如8670、9976），需要增加与项目强相关的适配文件（scatter.txt、SEC\_VER.txt、type.txt），scatter.txt分散加载文件，将可执行映像文件分散加载到不同的内存段（文件内容：指定不同内存段的起始地址）。

type.txt是build升级包过程生成的，里面的值1代表FullOTA，0代表DiffOTA，android的上层的update流程中会check这个值。

scatter.txt也是build升级包过程生成的，里面的内容来自于/mediatek/misc/ota\_scatter.txt。具体code可见脚本ota\_from\_target\_files。而mediatek/misc/ota\_scatter.txt是在build full ota时会产生。该文件主要用于在升级的时候check升级前后parition layout是否有改变。

SEC\_VER.TXT是在编译时从alps\\mediatek\\custom\\$PROJECT\\security\\recovery下copy过来的，用于在打开SUPPORT\_SBOOT\_UPDATE之后会使用，具体可以参考\[FAQ05739\] SD或者OTA升级secutiry device和non-security device的区别。

在./mk new时，会执行ptgen，执行ptgen会依赖OTA\_SCATTER\_FILE，见mediatek/build/libs/pregen.mk：218，然后再build/tools/makeMtk.mk中的142以及 692会生成ota\_scatter.txt。

## 2.3  OTA升级包制作工程分析 ##

升级包有整包与差分包之分。顾名思义，所谓整包即包含整个system分区中的数据文件；而差分包则仅包含两个版本之间改动的部分。利用整包升级好比对电脑进行重作系统，格式化系统分区，并将新系统数据写入分区；而利用差分包升级不会格式化system分区，只是对其中部分存储段的内容进行重写。除升级包之外，制作过程中还会涉及到另一种zip包，代码中称之为8675-cota-target\_files-xxx.zip，我称之为差分资源包。首先阐述下整包的制作过程。

### 2.3.1  整包的制作 ###

系统经过整编后，执行make otapackage命令，即可完成整包的制作，而此命令可分为两个阶段进行。首先执行./build/core/Makefile中的代码：

#-----------------------------------------------------------------
    # OTA update package
     
    name := $(TARGET_PRODUCT)
    ifeq ($(TARGET_BUILD_TYPE),debug)
      name :=$(name)_debug
    endif
    name := $(name)-ota-$(FILE_NAME_TAG)
     
    INTERNAL_OTA_PACKAGE_TARGET:= $(PRODUCT_OUT)/$(name).zip
    $(INTERNAL_OTA_PACKAGE_TARGET): KEY_CERT_PAIR :=$(DEFAULT_KEY_CERT_PAIR)
    $(INTERNAL_OTA_PACKAGE_TARGET):$(BUILT_TARGET_FILES_PACKAGE) $(OTATOOLS)
            @echo"Package OTA: $@"
            $(hide) ./build/tools/releasetools/ota_from_target_files-v \
               -n \
               -p$(HOST_OUT) \
               -k$(KEY_CERT_PAIR) \
              $(ota_extra_flag) \
              $(BUILT_TARGET_FILES_PACKAGE) $@
    .PHONY: otapackage
    otapackage: $(INTERNAL_OTA_PACKAGE_TARGET)
    #-----------------------------------------------------------------

代码段1 make otapackage目标代码

如上代码是Makefile文件中目标otapackage的执行代码 。首先，make otapackage命令会执行Makefile(./build/core/Makefile)中otapackage的目标代码(如代码1所示)。由代码可知，otapackage目标的执行只依赖于$(INTERNAL\_OTA\_PACKAGE\_TARGET)，而不存在任何规则(根据Makefile语法，规则必须以TAB键开始，而目标otapackage的定义之后却是变量name的声明，因此不存在规则)，因此只需要关注目标$(INTERNAL\_OTA\_PACKAGE\_TARGET)的生成。显然，此目标的生成依赖于目标文件：$(BUILT\_TARGET\_FILES\_PACKAGE)和$(OTATOOLS)，且其执行的命令为./build/tools/releasetools/ota\_from\_target\_files。也就是说，make otapackage所完成的功能全是通过这两个目标文件和执行的命令完成的，我们将分别对这三个关键点进行分析。

a)     $(OTATOOLS)

目标文件OTATOOLS的编译规则如下所示

1.   OTATOOLS :=  $(HOST_OUT_EXECUTABLES)/minigzip \  
    2.         $(HOST_OUT_EXECUTABLES)/mkbootfs \  
    3.         $(HOST_OUT_EXECUTABLES)/mkbootimg \  
    4.         $(HOST_OUT_EXECUTABLES)/fs_config \  
    5.         $(HOST_OUT_EXECUTABLES)/mkyaffs2image \  
    6.         $(HOST_OUT_EXECUTABLES)/zipalign \  
    7.         $(HOST_OUT_EXECUTABLES)/aapt \  
    8.         $(HOST_OUT_EXECUTABLES)/bsdiff \  
    9.         $(HOST_OUT_EXECUTABLES)/imgdiff \  
    10.        $(HOST_OUT_JAVA_LIBRARIES)/dumpkey.jar \  
    11.        $(HOST_OUT_JAVA_LIBRARIES)/signapk.jar \  
    12.        $(HOST_OUT_EXECUTABLES)/mkuserimg.sh \  
    13.        $(HOST_OUT_EXECUTABLES)/genext2fs \  
    14.        $(HOST_OUT_EXECUTABLES)/tune2fs \  
    15.        $(HOST_OUT_EXECUTABLES)/e2fsck \  
    16.        $(HOST_OUT_EXECUTABLES)/make_ext4fs  
    17.    
    18.  .PHONY: otatools  
    19.  otatools: $(OTATOOLS)

可以看出变量OTATOOLS为系统中一系列文件的集合。那么这些文件又有什么用处呢？ 事实上，这些文件用于压缩(minigzip：用于gzip文件；make\_ext4fs：将文件转换为ext4类型；mkyaffs2image：用于yaffs文件系统；......)、解压缩、差分(bsdiff，imgdiff)、签名(singapk.jar)等功能，结合代码段1可得到如下结论：目标$(INTERNAL\_OTA\_PACKAGE\_TARGET)的执行依赖于这一系列系统工具－－仅此而已。也就是说，目标文件$(OTATOOLS)仅仅指定了命令执行所需要的工具，并未执行任何操作。

注：变量$(HOST\_OUT\_EXECUTABLES)指代的是out/host/linux-x86/bin目录，而变量$(HOST\_OUT\_JAVA\_LIBRARIES)/表示的是out/host/linux-x86/framework目录，这意味着我们可以从此目录下找到上述工具，并为我们所用。

b)        $(BUILT\_TARGET\_FILES\_PACKAGE)

目标OTATOOLS指明了执行makeotapackage命令所需要的系统工具，而目标$(BUILT\_TARGE\_FILES\_PACKAGE)的生成则完成了两件事：重新打包system.img文件和生成差分资源包。$(BUILT\_TARGE\_FILES\_PACKAGE)的编译规则如下所示：

1. # -----------------------------------------------------------------  
    2. # A zip of the directories that map to the target filesystem.  
    3. # This zip can be used to create an OTA package or filesystem image  
    4. # as a post-build step.  
    5. #  
    6. name := $(TARGET_PRODUCT)  
    7. ifeq ($(TARGET_BUILD_TYPE),debug)  
    8.   name := $(name)_debug  
    9. endif  
    10.name := $(name)-target_files-$(FILE_NAME_TAG)  
    11.  
    12.intermediates := $(call intermediates-dir-for,PACKAGING,target_files)  
    13.BUILT_TARGET_FILES_PACKAGE := $(intermediates)/$(name).zip  
    14.$(BUILT_TARGET_FILES_PACKAGE): intermediates := $(intermediates)  
    15.$(BUILT_TARGET_FILES_PACKAGE): \  
    16.        zip_root := $(intermediates)/$(name)  
    17.  
    18.# $(1): Directory to copy  
    19.# $(2): Location to copy it to  
    20.# The "ls -A" is to prevent "acp s/* d" from failing if s is empty.  
    21.define package_files-copy-root  
    22.  if [ -d "$(strip $(1))" -a "$$(ls -A $(1))" ]; then \  
    23.    mkdir -p $(2) && \  
    24.    $(ACP) -rd $(strip $(1))/* $(2); \  
    25.  fi  
    26.endef  
    27.  
    28.built_ota_tools := \  
    29.    $(call intermediates-dir-for,EXECUTABLES,applypatch)/applypatch \  
    30.    $(call intermediates-dir-for,EXECUTABLES,applypatch_static)/applypatch_static \  
    31.    $(call intermediates-dir-for,EXECUTABLES,check_prereq)/check_prereq \  
    32.    $(call intermediates-dir-for,EXECUTABLES,sqlite3)/sqlite3 \  
    33.    $(call intermediates-dir-for,EXECUTABLES,updater)/updater  
    34.$(BUILT_TARGET_FILES_PACKAGE): PRIVATE_OTA_TOOLS := $(built_ota_tools)  
    35.  
    36.$(BUILT_TARGET_FILES_PACKAGE): PRIVATE_RECOVERY_API_VERSION := $(RECOVERY_API_VERSION)  
    37.  
    38.ifeq ($(TARGET_RELEASETOOLS_EXTENSIONS),)  
    39.# default to common dir for device vendor  
    40.$(BUILT_TARGET_FILES_PACKAGE): tool_extensions := $(TARGET_DEVICE_DIR)/../common  
    41.else  
    42.$(BUILT_TARGET_FILES_PACKAGE): tool_extensions := $(TARGET_RELEASETOOLS_EXTENSIONS)  
    43.endif  
    44.  
    45.# Depending on the various images guarantees that the underlying  
    46.# directories are up-to-date.  
    47.  
    48.ifeq ($(TARGET_USERIMAGES_USE_EXT4),true)  
    49.$(BUILT_TARGET_FILES_PACKAGE): $(INSTALLED_CACHEIMAGE_TARGET)  
    50.endif  
    51.  
    52.$(BUILT_TARGET_FILES_PACKAGE): \  
    53.        $(INSTALLED_BOOTIMAGE_TARGET) \  
    54.        $(INSTALLED_RADIOIMAGE_TARGET) \  
    55.        $(INSTALLED_RECOVERYIMAGE_TARGET) \  
    56.        $(INSTALLED_FACTORYIMAGE_TARGET) \  
    57.        $(INSTALLED_SYSTEMIMAGE) \  
    58.        $(INSTALLED_CACHEIMAGE_TARGET) \  
    59.        $(INSTALLED_USERDATAIMAGE_TARGET) \  
    60.        $(INSTALLED_SECROIMAGE_TARGET) \  
    61.        $(INSTALLED_ANDROID_INFO_TXT_TARGET) \  
    62.        $(built_ota_tools) \  
    63.        $(APKCERTS_FILE) \  
    64.        $(HOST_OUT_EXECUTABLES)/fs_config \  
    65.        | $(ACP)  
    66.     @echo "Package target files: $@"  
    67.    $(hide) rm -rf $@ $(zip_root)  
    68.    $(hide) mkdir -p $(dir $@) $(zip_root)  
    69.     @# Components of the recovery image  
    70.    $(hide) mkdir -p $(zip_root)/RECOVERY  
    71.    $(hide) $(call package_files-copy-root, \  
    72.        $(TARGET_RECOVERY_ROOT_OUT),$(zip_root)/RECOVERY/RAMDISK)  
    73.ifdef INSTALLED_KERNEL_TARGET  
    74.    $(hide) $(ACP) $(INSTALLED_KERNEL_TARGET) $(zip_root)/RECOVERY/kernel  
    75.    $(hide) $(ACP) $(recovery_ramdisk) $(zip_root)/RECOVERY/ramdisk  
    76.endif  
    77.ifdef INSTALLED_2NDBOOTLOADER_TARGET  
    78.    $(hide) $(ACP) \  
    79.        $(INSTALLED_2NDBOOTLOADER_TARGET) $(zip_root)/RECOVERY/second  
    80.endif  
    81.ifdef BOARD_KERNEL_CMDLINE  
    82.    $(hide) echo "$(BOARD_KERNEL_CMDLINE)" > $(zip_root)/RECOVERY/cmdline  
    83.endif  
    84.ifdef BOARD_KERNEL_BASE  
    85.    $(hide) echo "$(BOARD_KERNEL_BASE)" > $(zip_root)/RECOVERY/base  
    86.endif  
    87.     @# Components of the factory image  
    88.    $(hide) mkdir -p $(zip_root)/FACTORY  
    89.    $(hide) $(call package_files-copy-root, \  
    90.        $(TARGET_FACTORY_ROOT_OUT),$(zip_root)/FACTORY/RAMDISK)  
    91.ifdef INSTALLED_KERNEL_TARGET  
    92.    $(hide) $(ACP) $(INSTALLED_KERNEL_TARGET) $(zip_root)/FACTORY/kernel  
    93.endif  
    94.ifdef BOARD_KERNEL_PAGESIZE  
    95.    $(hide) echo "$(BOARD_KERNEL_PAGESIZE)" > $(zip_root)/RECOVERY/pagesize  
    96.endif  
    97.ifdef INSTALLED_2NDBOOTLOADER_TARGET  
    98.    $(hide) $(ACP) \  
    99.        $(INSTALLED_2NDBOOTLOADER_TARGET) $(zip_root)/FACTORY/second  
    100.endif  
    101.ifdef BOARD_KERNEL_CMDLINE  
    102.    $(hide) echo "$(BOARD_KERNEL_CMDLINE)" > $(zip_root)/FACTORY/cmdline  
    103.endif  
    104.ifdef BOARD_KERNEL_BASE  
    105.    $(hide) echo "$(BOARD_KERNEL_BASE)" > $(zip_root)/FACTORY/base  
    106.endif  
    107.    @# Components of the boot image  
    108.    $(hide) mkdir -p $(zip_root)/BOOT  
    109.    $(hide) $(call package_files-copy-root, \  
    110.        $(TARGET_ROOT_OUT),$(zip_root)/BOOT/RAMDISK)  
    111.ifdef INSTALLED_KERNEL_TARGET  
    112.    $(hide) $(ACP) $(INSTALLED_KERNEL_TARGET) $(zip_root)/BOOT/kernel  
    113.    $(hide) $(ACP) $(INSTALLED_RAMDISK_TARGET) $(zip_root)/BOOT/ramdisk  
    114.endif  
    115.ifdef INSTALLED_2NDBOOTLOADER_TARGET  
    116.    $(hide) $(ACP) \  
    117.        $(INSTALLED_2NDBOOTLOADER_TARGET) $(zip_root)/BOOT/second  
    118.endif  
    119.ifdef BOARD_KERNEL_CMDLINE  
    120.    $(hide) echo "$(BOARD_KERNEL_CMDLINE)" > $(zip_root)/BOOT/cmdline  
    121.endif  
    122.ifdef BOARD_KERNEL_BASE  
    123.    $(hide) echo "$(BOARD_KERNEL_BASE)" > $(zip_root)/BOOT/base  
    124.endif  
    125.ifdef BOARD_KERNEL_PAGESIZE  
    126.    $(hide) echo "$(BOARD_KERNEL_PAGESIZE)" > $(zip_root)/BOOT/pagesize  
    127.endif  
    128.#wschen  
    129.ifneq "" "$(CUSTOM_BUILD_VERNO)"  
    130.    $(hide) echo "$(CUSTOM_BUILD_VERNO)" > $(zip_root)/BOOT/board  
    131.endif  
    132.  
    133.#[eton begin]: added by LiuDekuan for u-boot update  
    134.    $(hide) $(ACP) $(PRODUCT_OUT)/uboot_eyang77_ics2.bin $(zip_root)/uboot.bin  
    135.#[eton end]  
    136.  
    137.    $(hide) $(foreach t,$(INSTALLED_RADIOIMAGE_TARGET),\  
    138.                mkdir -p $(zip_root)/RADIO; \  
    139.                $(ACP) $(t) $(zip_root)/RADIO/$(notdir $(t));)  
    140.    @# Contents of the system image  
    141.    $(hide) $(call package_files-copy-root, \  
    142.        $(SYSTEMIMAGE_SOURCE_DIR),$(zip_root)/SYSTEM)  
    143.    @# Contents of the data image  
    144.    $(hide) $(call package_files-copy-root, \  
    145.        $(TARGET_OUT_DATA),$(zip_root)/DATA)  
    146.    @# Extra contents of the OTA package  
    147.    $(hide) mkdir -p $(zip_root)/OTA/bin  
    148.    $(hide) $(ACP) $(INSTALLED_ANDROID_INFO_TXT_TARGET) $(zip_root)/OTA/  
    149.    $(hide) $(ACP) $(PRIVATE_OTA_TOOLS) $(zip_root)/OTA/bin/  
    150.    @# Security information of the OTA package  
    151.    @echo "[SEC OTA] Adding Security information to OTA package"  
    152.    @echo "[SEC OTA] path : mediatek/custom/$(MTK_PROJECT)/security/recovery/SEC_VER.txt"  
    153.    $(hide) $(ACP) mediatek/custom/$(MTK_PROJECT)/security/recovery/SEC_VER.txt $(zip_root)/OTA/  
    154.    @# Files that do not end up in any images, but are necessary to  
    155.    @# build them.  
    156.    $(hide) mkdir -p $(zip_root)/META  
    157.    $(hide) $(ACP) $(APKCERTS_FILE) $(zip_root)/META/apkcerts.txt  
    158.    $(hide) echo "$(PRODUCT_OTA_PUBLIC_KEYS)" > $(zip_root)/META/otakeys.txt  
    159.    $(hide) echo "recovery_api_version=$(PRIVATE_RECOVERY_API_VERSION)" > $(zip_root)/META/misc_info.txt  
    160.ifdef BOARD_FLASH_BLOCK_SIZE  
    161.    $(hide) echo "blocksize=$(BOARD_FLASH_BLOCK_SIZE)" >> $(zip_root)/META/misc_info.txt  
    162.endif  
    163.ifdef BOARD_BOOTIMAGE_PARTITION_SIZE  
    164.    $(hide) echo "boot_size=$(BOARD_BOOTIMAGE_PARTITION_SIZE)" >> $(zip_root)/META/misc_info.txt  
    165.endif  
    166.ifdef BOARD_RECOVERYIMAGE_PARTITION_SIZE  
    167.    $(hide) echo "recovery_size=$(BOARD_RECOVERYIMAGE_PARTITION_SIZE)" >> $(zip_root)/META/misc_info.txt  
    168.endif  
    169.ifdef BOARD_SYSTEMIMAGE_PARTITION_SIZE  
    170.    $(hide) echo "system_size=$(BOARD_SYSTEMIMAGE_PARTITION_SIZE)" >> $(zip_root)/META/misc_info.txt  
    171.endif  
    172.ifdef BOARD_SECROIMAGE_PARTITION_SIZE  
    173.    $(hide) echo "secro_size=$(BOARD_SECROIMAGE_PARTITION_SIZE)" >> $(zip_root)/META/misc_info.txt  
    174.endif  
    175.ifdef BOARD_CACHEIMAGE_PARTITION_SIZE  
    176.    $(hide) echo "cache_size=$(BOARD_CACHEIMAGE_PARTITION_SIZE)" >> $(zip_root)/META/misc_info.txt  
    177.endif  
    178.ifdef BOARD_USERDATAIMAGE_PARTITION_SIZE  
    179.    $(hide) echo "userdata_size=$(BOARD_USERDATAIMAGE_PARTITION_SIZE)" >> $(zip_root)/META/misc_info.txt  
    180.endif  
    181.    $(hide) echo "tool_extensions=$(tool_extensions)" >> $(zip_root)/META/misc_info.txt  
    182.ifdef mkyaffs2_extra_flags  
    183.    $(hide) echo "mkyaffs2_extra_flags=$(mkyaffs2_extra_flags)" >> $(zip_root)/META/misc_info.txt  
    184.endif  
    185.ifdef INTERNAL_USERIMAGES_SPARSE_EXT_FLAG  
    186.    $(hide) echo "extfs_sparse_flag=$(INTERNAL_USERIMAGES_SPARSE_EXT_FLAG)" >> $(zip_root)/META/misc_info.txt  
    187.endif  
    188.    $(hide) echo "default_system_dev_certificate=$(DEFAULT_KEY_CERT_PAIR)" >> $(zip_root)/META/misc_info.txt  
    189.ifdef PRODUCT_EXTRA_RECOVERY_KEYS  
    190.    $(hide) echo "extra_recovery_keys=$(PRODUCT_EXTRA_RECOVERY_KEYS)" >> $(zip_root)/META/misc_info.txt  
    191.endif  
    192.     @# Zip everything up, preserving symlinks  
    193.    $(hide) (cd $(zip_root) && zip -qry ../$(notdir $@) .)  
    194.    @# Run fs_config on all the system, boot ramdisk, and recovery ramdisk files in the zip, and save the output  
    195.    $(hide) zipinfo -1 $@ | awk 'BEGIN { FS="SYSTEM/" } /^SYSTEM\// {print "system/" $$2}' | $(HOST_OUT_EXECUTABLES)/fs_config > $(zip_root)/META/filesystem_config.txt  
    196.    $(hide) zipinfo -1 $@ | awk 'BEGIN { FS="BOOT/RAMDISK/" } /^BOOT\/RAMDISK\// {print $$2}' | $(HOST_OUT_EXECUTABLES)/fs_config > $(zip_root)/META/boot_filesystem_config.txt  
    197.    $(hide) zipinfo -1 $@ | awk 'BEGIN { FS="RECOVERY/RAMDISK/" } /^RECOVERY\/RAMDISK\// {print $$2}' | $(HOST_OUT_EXECUTABLES)/fs_config > $(zip_root)/META/recovery_filesystem_config.txt  
    198.    $(hide) (cd $(zip_root) && zip -q ../$(notdir $@) META/*filesystem_config.txt)  
      
    199.target-files-package: $(BUILT_TARGET_FILES_PACKAGE)  
      
    200.ifneq ($(TARGET_PRODUCT),sdk)  
    201.ifeq ($(filter generic%,$(TARGET_DEVICE)),)  
    202.ifneq ($(TARGET_NO_KERNEL),true)  
    203.ifneq ($(recovery_fstab),)

system.img文件的重新打包是通过$(BUILT\_TARGE\_FILES\_PACKAGE)的依赖条件$(INSTALLED\_SYSTEMIMAGE)目标文件的编译来完成的，而$(BUILT\_TARGE\_FILES\_PACKAGE)所有的执行命令(代码第66行至最后)都只为完成一件事，生成差分资源包所对应的目录并将其打包为ZIP包。具体的操作包括：

·        创建$(zip\_root)目录(代码第66~68行)，$(zip\_root)即out/target/product/<product-name>/obj/PACKAGING/target\_files\_from\_intermedias/<product-name>-target\_files-<version-name>；

·        创建/$(zip\_root)/RECOVERY目录并将COPY相关文件(代码69~86)；

·        创建/$(zip\_root)/FACTORY目录并将COPY相关文件(代码87~106)；

·        创建/$(zip\_root)/BOOT目录并将COPY相关文件(代码107~131)；

·        创建其他目录并COPY文件(代码132~191)；

·        将$(zip\_root)目录压缩为资源差分包(代码192~198)等。

经过目标文件$(BUILT\_TARGE\_FILES\_PACKAGE)的执行后，system.img已经被重新打包，且差分资源包也已经生成，剩下的工作就是将差分资源包（即target-files zipfile，下文将统一使用“差分资源包”这一概念）传递给ota\_ from \_target \_files代码，由它来生成OTA整包。

总之，前述代码的作用就在于将系统资源（包括system、recovery、boot等目录）重新打包，生成差分资源包。我们可以看下差分资源包中的文件结构，如下：

![20130608145211015][]

图2 target-files zipfile目录结构

其中，OTA目录值得关注，因为在此目录下存在着一个至关重要的文件：OTA/bin/updater（后文会有详述）。生成的差分资源包被传递给./build/tools/releasetools/

ota\_from\_target\_files执行第二阶段的操作：制作升级包。

![20130608145716125][]

图3./build/tools/releasetools目录下的文件

图3是./build/tools/releasetools目录下所包含的文件，这组文件是Google提供的用来制作升级包的代码工具，核心文件为：ota\_from\_target\_files和img\_from\_target\_files。其中，前者用来制作recovery模式下的升级包；后者则用来制作fastboot下的升级包（fastboot貌似是一种更底层的刷机操作，不太懂）。其他文件则是为此二者提供服务的，比如，common.py中包含有制作升级包所需操作的代码,各种工具类,参数处理/META文件处理/image生成/signcertification/patch file 操作等等；edify\_generator.py则用于生成recovery模式下升级的脚本文件：<升级包>.zip/META-INF/com/google/android/updater-script。

文件ota\_from\_target\_files是本文所关注的重点，其中定义了两个主要的方法：WriteFullOTAPackage和WriteIncrementalOTAPackage。前者用于生成整包，后者用来生成差分包。接着上文，当Makefile调用ota\_from\_target\_files，并将差分资源包传递进来时，会执行WriteFullOTAPackage。此方法完成的工作包括：（1）将system目录，boot.img等文件添加到整包中；（2）生成升级包中的脚本文件：<升级包>.zip/META-INF/com/google/android/updater-script；（3）将上文提到的可执行文件：OTA/bin/updater添加到升级包中：META-INF/com/google/android/updater-binary。摘取部分代码片段如下：

1.   script.FormatPartition("/system")  
    2.     script. FormatPartition ("/system")  
    3.     script.UnpackPackageDir("recovery", "/system")  
    4.     script.UnpackPackageDir("system", "/system")  
    5.     (symlinks, retouch_files) = CopySystemFiles(input_zip, output_zip)  
    6.     script.MakeSymlinks(symlinks)  
    7.     if OPTIONS.aslr_mode:  
    8.       script.RetouchBinaries(retouch_files)  
    9.     else:  
    10.     script.UndoRetouchBinaries(retouch_files)

代码2 WriteFullOTAPackage代码片段

其中的script为edify\_generator对象，其FormatPartition、UnpackPackageDir等方法分别是向脚本文件update-script中写入格式化分区、解压包等指令

1.  def AddToZip(self, input_zip, output_zip, input_path=None):  
    2.      """Write the accumulated script to the output_zip file.  input_zip 
    3.      is used as the source for the 'updater' binary needed to run 
    4.      script.  If input_path is not None, it will be used as a local 
    5.      path for the binary instead of input_zip."""  
    6.    
    7.      self.UnmountAll()  
    8.        common.ZipWriteStr(output_zip, "META-INF/com/google/android/updater-script",  
    9.                         "\n".join(self.script) + "\n")  
    10.       if input_path is None:  
    11.       data = input_zip.read("OTA/bin/updater")  
    12.     else:  
    13.       data = open(os.path.join(input_path, "updater")).read()  
    14.     common.ZipWriteStr(output_zip, "META-INF/com/google/android/update-binary",  
    15.                        data, perms=0755)

代码段3   edify\_generator中的AddToZip方法

WriteFullOTAPackage执行的最后会调用此方法。将资源差分包中OTA/bin/updater文件copy到升级包中META-INF/com/google/android/update-binary。此文件是OTA升级的关键，其将在recovery模式下被执行，用来将代码段2中生成的指令转换为相应的函数去执行，从而完成对系统数据的重写。

### 2.3.2  差分包的制作 ###

生成差分包调用的是文件./build/tools/releasetools/ota\_from\_target\_files中的WriteIncrementalOTA方法，调用时需要将两个版本的差分资源包作为参数传进来，形如：./build/tools/releasetools/ota\_from\_target\_files–n –i ota\_v1.zip ota\_v2.zip update.zip

其中，参数n表示忽略时间戳；i表示生成增量包（即差分包）；ota\_v1.zip与ota\_v2.zip分别代表前后两个版本的差分资源包；而update.zip则表示最终生成的差分包。WriteIncrementalOTA函数会计算输入的两个差分资源包中版本的差异，并将其写入到差分包中；同时，将updater及生成脚本文件udpate-script添加到升级包中。

制作完升级包后，之后便是将其写入到相应存储区中，这部分工作是在recovery模式下完成的。在这先简单描述一下这个过程。recovery模式下通过创建一个新的进程读取并执行脚本文件META-INF/com/google/android/updater-script。见如下代码：

1.   const char** args = (const char**)malloc(sizeof(char*) * 5);  
    2.   args[0] = binary;  
    3.   args[1] = EXPAND(RECOVERY_API_VERSION);   // defined in Android.mk  
    4.   char* temp = (char*)malloc(10);  
    5.   sprintf(temp, "%d", pipefd[1]);  
    6.   args[2] = temp;  
    7.   args[3] = (char*)path;  
    8.   args[4] = NULL;  
    9.     
    10.  pid_t pid = fork();  
    11.  if (pid == 0) {  
    12.      close(pipefd[0]);  
    13.      execv(binary, (char* const*)args);  
    14.      _exit(-1);  
    15.  }  
    16.  close(pipefd[1]);

代码段4   创建新进程安装升级包

分析代码之前，首先介绍linux中函数fork与execv的用法。

pid\_t fork( void)用于创建新的进程，fork调用的一个奇妙之处就是它仅仅被调用一次，却能够返回两次，它可能有三种不同的返回值：

1)在父进程中，fork返回新创建子进程的进程ID;

2)在子进程中，fork返回0;

3)如果出现错误，fork返回一个负值;

在fork函数执行完毕后，如果创建新进程成功，则出现两个进程，一个是子进程，一个是父进程。在子进程中，fork函数返回0，在父进程中，fork返回新创建子进程的进程ID。我们可以通过fork返回的值来判断当前进程是子进程还是父进程。

int execv(const char \*progname, char \*constargv\[\])

execv会停止执行当前的进程，并且以progname应用进程替换被停止执行的进程，进程ID没有改变。progname:被执行的应用程序。argv: 传递给应用程序的参数列表， 注意，这个数组的第一个参数应该是应用程序名字本身，并且最后一个参数应该为NULL，不参将多个参数合并为一个参数放入数组。

代码4见于bootable/recovery/install.c的try\_update\_binary函数中，是OTA升级的核心代码之一。通过对fork及execv函数的介绍可知，代码4创建了一个新的进程并在新进程中运行升级包中的META-INF/com/google/android/updater-binary文件（参数binary已在此前赋值），此文件将按照META-INF/com/google/android/updater-script中的指令将升级包里的数据写入到存储区中。OK，我们来看下META-INF/com/google/android/updater-binary文件的来历。

在源代码的./bootable/recovery/updater目录下，存在着如下几个文件：

通过查看Android.mk代码可知，文件install.c、updater.c将会被编译为可执行文件updater存放到目录out/target/product/<product-name>/obj/EXECUTABLES/updater\_intermediates/中；而在生成差分资源包（target-fileszipfile）时，会将此文件添加到压缩包中。

1.   built_ota_tools := \  
    2.       $(call intermediates-dir-for,EXECUTABLES,applypatch)/applypatch \  
    3.       $(call intermediates-dir-for,EXECUTABLES,applypatch_static)/applypatch_static \  
    4.       $(call intermediates-dir-for,EXECUTABLES,check_prereq)/check_prereq \  
    5.       $(call intermediates-dir-for,EXECUTABLES,sqlite3)/sqlite3 \  
    6.        $(call intermediates-dir-for,EXECUTABLES,updater)/updater  
    7.        $(hide) mkdir -p $(zip_root)/OTA/bin  
    8.       $(hide) $(ACP) $(INSTALLED_ANDROID_INFO_TXT_TARGET) $(zip_root)/OTA/  
    9.       $(hide) $(ACP) $(PRIVATE_OTA_TOOLS) $(zip_root)/OTA/bin/

代码段5 Makefile中定义的变量built\_ota\_tools

如代码段5，Makefile中定义了执行OTA所需要的一组工具（built\_ota\_tools），其中便包括由图4中文件编译而成的文件updater；而在生成差分资源包时，会将这组工具拷贝到差分资源包的OTA/bin目录中（见代码段6）；在生成升级包时（无论是执行WriteFullOTAPackage还是WriteIncrementalOTAPackage），最后都会调用edify\_generator的AddToZip方法，将updater添加到升级包中（更名为"META-INF/com/google/android/update-binary"）；最终在recovery模式下被执行，这便是其来龙去脉。而关于updater的执行，也大致的描述下吧。

由前文可知，updater主要由bootable/recovery/updater目录下的install.c和updater.c编译而成，主函数位于updater.c。其中，在install.c中定义了读写系统存储区的操作函数（这才是重写系统数据的真正代码）并将这些函数与updater-script中的指令映射起来。而在updater.c会首先装载install.c定义的函数，之后便解析升级脚本updater-script，执行其对应的操作命令。与此同时，执行updater的进程还会与父进程通信，通知父进程进行UI的相关操作（代码见bootable/recovery/install.c中的try\_update\_binary函数）。

# 3、OTA升级过程分析 #

## 3.1  Recovery模式简介 ##

所谓 Recovery 是智能手机的一种特殊工作模式，有点类似于 Windows 下的 DOS 工具箱，系统进入到这种模式下时，可以通过按键选择相应的操作菜单，从而实现相应的功能，比如 android 系统数据区的快速格式化（即恢复出厂设置）；通过 SD 卡进行OTA系统升级及固件（firmware）升级等。我们公司的手机一般进入 recovery 模式的方法是电源键加音量上键。后面会详细分析系统进入Recovery模式的过程以及在Recovery模式下进行OTA升级的过程。

设置模块中进行恢复出厂设置，OTA升级，patch升级及firmware升级等操作，系统一共做了两件事：

1. 往 /cache/recovery/command 文件中写入命令字段；

2. 重启系统

重启系统后必须进入Recovery模式，接下来分析进入Recovery模式的流程。

## 3.2  Recovery模式解析 ##

### 3.2.1  如何进入Recovery模式 ###

手机开机后，硬件系统上电，首先是完成一系列的初始化过程，如 CPU、串口、中断、timer、DDR 等硬件设备，然后接着加载 bootloader，为后面内核的加载作好准备。在一些系统启动必要的初始完成之后，系统会通过检测三个条件来判断要进入何种工作模式，流程如图。这一部分代码的源文件在\\bootable\\bootloader\\lk\\app\\aboot\\aboot.c 文件的aboot\_init()函数中:

从源代码中可以看出，开机时按住HOME键或音量上键（不同手机对此会有修改），会进入Recovery模式；按着返回键或音量下键会进入fastboot模式。如果没有组合键（代码中成为magic key）按下，则会检测SMEM中reboot\_mode变量的值，代码如下：

reboot\_mode可取的值为RECOVERY\_MODE和FASTBOOT\_MODE的宏定义，分别为：

reboot\_mode的取值由check\_reboot\_mode()函数返回，接下来我们看该函数在\\bootable\\bootloader\\lk\\target\\msm8660\_surf\\init.c中的定义：

可以看到该函数先读取地址restart\_reason\_addr处的值，最后返回該值，restart\_reason\_addr地址定义为0x2A05F65C，从此处读完值后会向改地址写入0x00，即将其内容擦除，这样做是为了防止下次进入时又进入Recovery模式。

如果restart\_reason\_addr处没有值被读到，则会继续读取MISC分区的BCB段进行判断，调用的函数为recovery\_init()。这里解释一下BCB（BootloaderControl Block），BCB 是 bootloader 与 Recovery 的通信接口，也是 Bootloader 与 Main system 之间的通信接口。存储在flash 中的 MISC 分区，占用三个 page，其本身就是一个结构体，具体成员以及各成员含义如下：

**command 字段**：该字段的值会在 Android系统需要进入 recovery模式的时候被 Android 更新。另外在固件更新成功时，也会被更新，以进入 recovery 模式来做一些收尾的清理工作。在更新成功后结束 Recovery时，会清除这个字段的值，防止重启时再次进入 Recovery 模式。

**status 字段**：在完成"update-radio"  或者  "update-hboot"更新后，bootloader会将执行结果写入到这个字段。

**recovery 字段**：仅可以被 Main System写入，用来向 recovery发送消息。该文件的内容格式为：

recovery\\n

<recovery command>\\n

该文件存储的是一个字符串，必须以“recovery\\n”开头，否则这个字段的所有内容域会被忽略。“recovery\\n”之后的部分，是/cache/recovery/command文件支持的命令。可以将其理解为 Recovery操作过程中对命令操作的备份。 Recovery会先读取 BCB,然后读取/cache/recovery/command，然后将二者重新写回 BCB，这样在进入 Mainsystem 之前，确保操作被执行。在操作之后进入 Main system 之前，Recovery 又会清空 BCB 的 command 域和 recovery 域，这样确保重启后不再进入 Recovery 模式。

解释完BCB字段的内容，我们再回过头来，调用recovery\_init()的代码如下：

该函数的定义在bootloader\\lk\\app\\aboot\\recovery.c中。

recovery\_init()函数会先通过get\_recovery\_message(&msg)函数把BCB段的内容读取到recovery\_message结构体中，再读取其command字段，如果字段是boot-recovery，则进入recovery模式；如果是update-radio，则进入固件升级流程。get\_recovery\_message(&msg)函数的代码如下。

系统判断进入哪种工作模式的流程如下图所示。如果以上条件皆不满足，则进入正常启动序列，系统会加载 boot.img 文件，然后加载 kernel，在内核加载完成之后，会根据内核的传递参数寻找 android 的第一个用户态进程，即 init 进程，该进程根据 init.rc以及 init.$(hardware).rc 脚本文件来启动 android 的必要的服务，直到完成 android 系统的启动。

当进入 recovery 模式时，系统加载的是recovery.img 文件，该文件内容与 boot.img 类似，也包含了标准的内核和根文件系统。但是 recovery.img 为了具有恢复系统的能力，比普通的 boot.img 目录结构中：

1、多了/res/images 目录，在这个目录下的图片是恢复时我们看到的背景画面。

2、多了/sbin/recovery 二进制程序，这个就是恢复用的程序。

3、/sbin/adbd 不一样，recovery 模式下的 adbd 不支持 shell。

4、初始化程序（init）和初始化配置文件（init.rc）都不一样。这就是系统没有进入图形界面而进入了类似文本界面，并可以通过简单的组合键进行恢复的原因。与正常启动系统类似，也是启动内核，然后启动文件系统。在进入文件系统后会执行/init，init 的配置文件就是  /init.rc。这个配置文件位于bootable/recovery/etc/init.rc。查看这个文件我们可以看到它做的事情很简单：

1)  设置环境变量。

2)  建立 etc 连接。

3)  新建目录，备用。

4)  挂载文件系统。

5)  启动 recovery（/sbin/recovery）服务。

6)  启动 adbd 服务(用于调试)。

上文所提到的fastboot 模式，即命令或 SD 卡烧写模式，不加载内核及文件系统，此处可以进行工厂模式的烧写。

综上所述，有三种进入recovery 模式的方法，分别是开机时按组合键，写 SMEM 中的 reboot\_mode变量值，以及写位于 MISC 分区的 BCB 中的 command 字段。

### 3.2.2 Recovery模式的三个组成部分 ###

Recovery 的工作需要整个软件平台的配合，从通信架构上来看，主要有以下三个部分：

1. Main System：即上面提到的正常启动模式（BCB 中无命令），是用 boot.img 启动的系统， Android的正常工作模式。更新时，在这种模式中我们的上层操作就是使用 OTA 或则从 SD 卡中升级 update.zip升级包。

2. Recovery：系统进入 Recovery 模式后会装载 Recovery 分区，该分区包含 recovery.img （同 boot.img相同，包含了标准的内核和根文件系统）。进入该模式后主要是运行 Recovery 服务（/sbin/recovery）来做相应的操作。

3. Bootloader：除了正常的加载启动系统之外，还会通过读取 MISC 分区（BCB）获得来自 Main System和 Recovery 的消息。

这三个实体之间的通信是必不可少的，他们相互之间有如下两个通信接口：一个是通过 CACHE 分区中的三个文件（command、log、intent）；另一个是前面提到的MISC分区的BCB段。

Recovery 的服务内容主要有三类：

①FACTORYRESET，恢复出厂设置。

②OTA INSTALL，即我们的update.zip 包升级。

③ENCRYPTEDFILE SYSTEM ENABLE/DISABLE，使能/关闭加密文件系统。

本文主要关心OTA升级的流程，所以下面的内容主要解释从上层应用点击进行OTA升级到重启进入Recovery模式进行升级包安装的过程。

我们只看从MainSystem如何进入Recovery模式，其他的通信暂不讨论。先从Main System开始看，当我们在Main System使用update.zip包进行升级时，系统会重启并进入Recovery模式。在系统重启之前，我们可以看到，Main System一定会向BCB中的command域写入boot-recovery(粉红色线)，用来告知Bootloader重启后进入recovery模式。这一步是必须的。至于Main System是否向recovery域写入值我们在源码中不能肯定这一点。即便如此，重启进入Recovery模式后Bootloader会从/cache/recovery/command中读取值并放入到BCB的recovery域。而MainSystem在重启之前肯定会向/cache/recovery/command中写入Recovery将要进行的操作命令。

### 3.2.3  从上层进入Recovery服务流程细节 ###

**Ø  从SystemUpdate到Reboot**

假设我们进入系统更新应用后，已下载完OTA包到SD卡，会弹出一个对话框，提示已有update.zip包是否现在更新，我们从这个地方跟踪。这个对话框的源码是SystemUpdateInstallDialog.java。

①   在mNowButton按钮的监听事件里，会调用mService.rebootAndUpdate（new File(mFile)）。这个mService就是SystemUpdateService的实例。这个类所在的源码文件是SystemUpdateService.java。这个函数的参数是一个文件。它肯定就是我们的update.zip包了。我们可以证实一下这个猜想。

②mFile的值：在SystemUpdateInstallDialog.java中的ServiceConnection中我们可以看到这个mFile的值有两个来源。

**来源一：**

mFile的一个来源是这个是否立即更新提示框接受的上一个Activity以“file”标记传来的值。这个Activity就是SystemUpdate.java。它是一个PreferenceActivity类型的。在其onPreferenceChange函数中定义了向下一个Activity传送的值，这个值是根据我们不同的选择而定的。如果我们在之前选择了从SD卡安装，则这个传下去的“file”值为“/sdcard/update.zip”。如果选择了从NAND安装，则对应的值为“/nand/update.zip”。

**来源二：**

另个一来源是从mService.getInstallFile()获得。我们进一步跟踪就可发现上面这个函数获得的值就是“/cache”+mUpdateFileURL.getFile();这就是OTA在线下载后对应的文件路径。不论参数mFile的来源如何，我们可以发现在mNowButton按钮的监听事件里是将整个文件，也就是我们的update.zip包作为参数往rebootAndUpdate（）中传递的。

③rebootAndUpdate:在这个函数中MainSystem做了重启前的准备。继续跟踪下去会发现，在SystemUpdateService.java中的**rebootAndUpdate函数中新建了一个线程，在这个线程中最后调用的就是RecoverySystem.installPackage(mContext,mFile)**，我们的update.zip包也被传递进来了。

④RecoverySystem类：RecoverySystem类的源码所在文件路径为： \*\*\*\*\*/frameworks/base/core/java/android/os/RecoverySystem.java。我们关心的是**installPackage**(Contextcontext,FilepackageFile)函数。这个函数首先根据我们传过来的包文件，获取这个包文件的绝对路径filename。然后将其拼成arg=“--update\_package=”+filename。它最终会被写入到BCB中。这个就是重启进入Recovery模式后，Recovery服务要进行的操作。它被传递到函数bootCommand(context,arg)。

⑤bootCommand()：在这个函数中才是MainSystem在重启前真正做的准备。主要做了以下事情，首先创建/cache/recovery/目录，删除这个目录下的command和log（可能不存在）文件在sqlite数据库中的备份。然后将上面④步中的arg命令写入到/cache/recovery/command文件中。下一步就是真正重启了。接下来看一下在重启函数reboot中所做的事情。

⑥pm.reboot()：重启之前先获得了PowerManager（电源管理）并进一步获得其系统服务。然后调用了pm.reboot(“recovery”)函数。该函数最后找到是E:\\MTK6592(Original)\\alps\\system\\core\\libcutils\\android\_reboot.c中的reboot函数。这个函数实际上是一个系统调用，即\_\_reboot(LINUX\_REBOOT\_MAGIC1,LINUX\_REBOOT\_MAGIC2,LINUX\_REBOOT\_CMD\_RESTART2, arg);从这个函数我们可以看出前两个参数就代表了我们的组合键，LINUX\_REBOOT\_CMD\_RESTART2就是我们传过来的“recovery”。再进一步跟踪就到了汇编代码了，我们无法直接查看它的具体实现细节。但可以肯定的是这个函数只将“recovery”参数传递过去了，之后将“boot-recovery”写入到了MISC分区的BCB数据块的command域中。这样在重启之后Bootloader才知道要进入Recovery模式。

在这里我们无法肯定MainSystem在重启之前对BCB的recovery域是否进行了操作。其实在重启前是否更新BCB的recovery域是不重要的，因为进入Recovery服务后，Recovery会自动去/cache/recovery/command中读取要进行的操作然后写入到BCB的recovery域中。

至此，MainSystem就开始重启并进入Recovery模式。在这之前Main System做的最实质的就是两件事，一是将“boot-recovery”写入BCB的command域，二是将--update\_package=/cache/update.zip”或则“--update\_package=/sdcard/update.zip”写入/cache/recovery/command文件中。下面的部分就开始重启并进入Recovery服务了。

**Ø  从reboot到Recovery服务**

这个过程我们在上文（对照第一个图）已经讲过了。从Bootloader开始如果没有组合键按下，就从MISC分区读取BCB块的command域（在主系统时已经将“boot-recovery”写入）。然后就以Recovery模式开始启动。与正常启动不同的是Recovery模式下加载的镜像是recovery.img。这个镜像同boot.img类似，也包含了标准的内核和根文件系统。其后就与正常的启动系统类似，也是启动内核，然后启动文件系统。在进入文件系统后会执行/init，init的配置文件就是/init.rc。这个配置文件来自bootable/recovery/etc/init.rc。查看这个文件我们可以看到它做的事情很简单：

①设置环境变量。

②建立etc连接。

③新建目录，备用。

④挂载/tmp为内存文件系统tmpfs

⑤启动recovery（/sbin/recovery）服务。

⑥启动adbd服务(用于调试)。

当然，init主程序还会装载属性配置文件 /default.prop, 它包含了很多系统属性设置，比如，ro.build.\*， 等等。这里最重要的就是当然就recovery服务了。在Recovery服务中将要完成我们的升级工作。

## 3.3  Recovery服务流程细节 ##

从/bootable/recovery/recovery.c的代码注释中我们可以看到Recovery的服务内容主要有三类：

①  FACTORY RESET，恢复出厂设置。

②  OTA INSTALL，即我们的update.zip包升级。

③  ENCRYPTED FILE SYSTEMENABLE/DISABLE，使能/关闭加密文件系统。

具体的每一类服务的大概工作流程，注释中都有，下文中会详细说下OTA INSTALL的工作流程。这三类服务的大概的流程都是通用的，只是不同操作体现与不同的操作细节。下面我们看Recovery服务的通用流程。

本文中会以OTA  INSTALL的流程为例具体分析，相关函数的调用过程如下图所示。我们顺着流程图分析，从recovery.c的main函数开始：

1.    ui\_init()：Recovery服务使用了一个基于framebuffer的简单ui（miniui）系统。这个函数对其进行了简单的初始化。在Recovery服务的过程中主要用于显示一个背景图片（正在安装或安装失败）和一个进度条（用于显示进度）。另外还启动了两个线程，一个用于处理进度条的显示（progress\_thread），另一个用于响应用户的按键（input\_thread）。

2.    get\_arg()：这个函数主要做了上图中get\_arg()往右往下直到parsearg/v的工作。我们对照着流程一个一个看。

①get\_bootloader\_message()：主要工作是根据分区的文件格式类型（mtd或emmc）从MISC分区中读取BCB数据块到一个临时的变量中。

②然后开始判断Recovery服务是否有带命令行的参数（/sbin/recovery，根据现有的逻辑是没有的），若没有就从BCB中读取recovery域。如果读取失败则从/cache/recovery/command中读取然后。这样这个BCB的临时变量中的recovery域就被更新了。在将这个BCB的临时变量写回真实的BCB之前，又更新的这个BCB临时变量的command域为“boot-recovery”。这样做的目的是如果在升级失败（比如升级还未结束就断电了）时，系统在重启之后还会进入Recovery模式，直到升级完成。

③在这个BCB临时变量的各个域都更新完成后使用set\_bootloader\_message()写回到真正的BCB块中。

这个过程可以用一个简单的图来概括，这样更清晰：

3.     parserargc/argv：解析我们获得参数。注册所解析的命令（register\_update\_command），在下面的操作中会根据这一步解析的值进行一步步的判断，然后进行相应的操作。

4.    if(update\_package)：判断update\_package是否有值，若有就表示需要升级更新包，此时就会调用install\_package()（即图中红色的第二个阶段）。在这一步中将要完成安装实际的升级包。这是最为复杂，也是升级update.zip包最为核心的部分。我们在下一节详细分析这一过程。为从宏观上理解Recovery服务的框架，我们将这一步先略过，假设已经安装完成了。我们接着往下走，看安装完成后Recovery怎样一步步结束服务，并重启到新的主系统的。

5.    if(wipe\_data/wipe\_cache)：这一步判断实际是两步，在源码中是先判断是否擦除data分区（用户数据部分）的，然后再判断是否擦除cache分区。值得注意的是在擦除data分区的时候必须连带擦除cache分区。在只擦除cache分区的情形下可以不擦除data分区。

6.    maybe\_install\_firmware\_update()：如果升级包中包含/radio/hbootfirmware的更新，则会调用这个函数。查看源码发现，在注释中（OTA INSTALL）有这一个流程。但是main函数中并没有显示调用这个函数。目前尚未发现到底是在什么地方处理。但是其流程还是向上面的图示一样。即，① 先向BCB中写入“boot-recovery”和“—wipe\_cache”之后将cache分区格式化，然后将firmwareimage 写入原始的cache分区中。②将命令“update-radio/hboot”和“—wipe\_cache”写入BCB中，然后开始重新安装firmware并刷新firmware。③之后又会进入图示中的末尾，即finish\_recovery()。

7.    prompt\_and\_wait()：这个函数是在一个判断中被调用的。其意义是如果安装失败（update.zip包错误或验证签名失败），则等待用户的输入处理（如通过组合键reboot等）。

8.    finish\_recovery()：这是Recovery关闭并进入MainSystem的必经之路。其大体流程如下：

① 将intent（字符串）的内容作为参数传进finish\_recovery中。如果有intent需要告知Main System，则将其写入/cache/recovery/intent中。这个intent的作用尚不知有何用。

② 将内存文件系统中的Recovery服务的日志（/tmp/recovery.log）拷贝到cache（/cache/recovery/log）分区中，以便告知重启后的Main System发生过什么。

③ 擦除MISC分区中的BCB数据块的内容，以便系统重启后不在进入Recovery模式而是进入更新后的主系统。

④ 删除/cache/recovery/command文件。这一步也是很重要的，因为重启后Bootloader会自动检索这个文件，如果未删除的话又会进入Recovery模式。原理在上面已经讲的很清楚了。

9.    reboot()：这是一个系统调用。在这一步Recovery完成其服务重启并进入Main System。这次重启和在主系统中重启进入Recovery模式调用的函数是一样的，但是其方向是不一样的。所以参数也就不一样。查看源码发现，其重启模式是RB\_AUTOBOOT。这是一个系统的宏。

至此，我们对Recovery服务的整个流程框架已有了大概的认识。下面就是升级update.zip包时特有的也是Recovery服务中关于安装升级包最核心的第二个阶段。即我们图例中的红色2的那个分支。

## 3.4  OTA升级过程分析（install\_package） ##

### 3.4.1  OTA升级包安装过程 ###

安装升级包所调用的函数为install\_package()，源码位于/bootable/recovery/install.cpp。该函数调用really\_install\_package(path,wipe\_cache)，该函数的流程为：

根据源代码和上面的流程图总结有如下步骤：

①ensure\_path\_mount()：先判断所传的update.zip包路径所在的分区是否已经挂载。如果没有则先挂载。

②load\_keys()：加载公钥源文件，路径位于/res/keys。这个文件在Recovery镜像的根文件系统中。

③verify\_file()：对升级包update.zip包进行签名验证。

④mzOpenZipArchive()：打开升级包，并将相关的信息拷贝到一个临时的ZipArchinve变量中。这一步并未对我们的update.zip包解压。

⑤try\_update\_binary()：在这个函数中才是对我们的update.zip升级的地方。这个函数一开始先根据我们上一步获得的zip包信息，以及升级包的绝对路径将update\_binary文件拷贝到内存文件系统的/tmp/update\_binary中。以便后面使用。

⑥pipe()：创建管道，用于下面的子进程和父进程之间的通信。

⑦fork()：创建子进程。其中的子进程主要负责执行binary（execv(binary,args)，即执行我们的安装命令脚本），父进程负责接受子进程发送的命令去更新ui显示（显示当前的进度）。子父进程间通信依靠管道。

⑧其中，在创建子进程后，父进程有两个作用。一是通过管道接受子进程发送的命令来更新UI显示。二是等待子进程退出并返回INSTALLSUCCESS。其中子进程在解析执行安装脚本的同时所发送的命令有以下几种：

progress  <frac> <secs>：根据第二个参数secs（秒）来设置进度条。

set\_progress  <frac>：直接设置进度条，frac取值在0.0到0.1之间。

firmware<”hboot”|”radio”><filename>：升级firmware时使用，在API  V3中不再使用。

ui\_print <string>：在屏幕上显示字符串，即打印更新过程。

execv(binary,args)的作用就是调用META-INF/com/google/android路径下的可执行文件：update-binary，这个程序的实质就是去解析update.zip包中的updater-script脚本中的命令并执行。由此，Recovery服务就进入了实际安装update.zip包的过程。

上述的子进程所执行的程序binary实际上就是update.zip包中的update-binary。实际上Recovery服务在做这一部分工作的时候是先将包中update-binary拷贝到内存文件系统中的/tmp/update\_binary，然后再执行的。升级包中update-binary的在升级包制作那一小节中已有说明。

通过install.c源码来分析下update-binary程序的执行过程：

①函数参数以及版本的检查：当前updater binary API所支持的版本号有1，2，3这三个。

②获取管道并打开：在执行此程序的过程中向该管道写入命令，用于通知其父进程根据命令去更新UI显示。

③读取updater-script脚本：从update.zip包中将updater-script脚本读到一块动态内存中，供后面执行。

④Configureedify’s functions：注册脚本中的语句处理函数，即识别脚本中命令的函数。主要有以下几类 RegisterBuiltins()：注册程序中控制流程的语句，如ifelse、assert、abort、stdout等。RegisterInstallFunctions()：实际安装过程中安装所需的功能函数，比如mount、format、set\_progress、set\_perm等等。RegisterDeviceExtensions()：与设备相关的额外添加項，在源码中并没有任何实现。 FinishRegistration()：结束注册。

⑤Parsethescript：调用yy\*库函数解析脚本，并将解析后的内容存放到一个Expr类型的python类中。主要函数是yy\_scan\_string()和yyparse()。

⑥执行脚本：核心函数是Evaluate（），它会调用其他的callback函数，而这些callback函数又会去调用Evaluate去解析不同的脚本片段，从而实现一个简单的脚本解释器。

⑦错误信息提示：最后就是根据Evaluate（）执行后的返回值，给出一些打印信息。这一执行过程非常简单，最主要的函数就是Evaluate。它负责最终执行解析的脚本命令。而安装过程中的命令就是updater-script。

### 3.4.2 update-script脚本语法简介 ###

常用修改权限的命令：

Set\_perm 0 0 0600 ×××(只有所有者有读和写的权限)

Set\_perm 0 0 0644 ×××(所有者有读和写的权限，组用户只有读的权限)

Set\_perm 0 0 0700 ×××(只有所有者有读和写以及执行的权限)

Set\_perm 0 0 0666 ×××(每个人都有读和写的权限)

Set\_perm 0 0 0777 ×××(每个人都有读和写以及执行的权限)

1.copy\_dir

语法：copy\_dir <src-dir><dst-dir> \[<times\*\*p>\]

<src-dir>表示原文件夹，<dst-dir>表示目的文件夹，\[<times\*\*p>\]表示时间戳

作 用：将<src-dir>文件夹中的内容复制到<dst-dir>文件夹中。<dst-dir>文件夹中的原始内容 将会保存不变，除非<src-dir>文件夹中有相同的内容，这样<dst-dir>中的内容将被覆盖

举例：copy\_dir PACKAGE:system SYSTEM:（将升级包中的system文件夹复制到手机中）

2.format

语法：format <root>

<root>表示要格式化的分区

作用：格式化一个分区

举例：format SYSTEM:（将手机/system分区完全格式化）

注意：格式化之后的数据是不可以恢复的

3.delete

语法：delete <file1> \[... <fileN>\]

<file1> \[... <fileN>\]表示要格式化的文件，可以是多个文件用空格隔开

作用：删除文件1，2到n

举例：delete SYSTEM:app/Calculator.apk（删除手机systen文件夹中app中的Calculator.apk文件）

4.delete\_recursive

语法：delete\_recursive <file-or-dir1> \[... <file-or-dirN>\]

<file-or-dir1> \[... <file-or-dirN>\]表示要删除的文件或文件夹，可以使多个，中间用空格隔开

作用：删除文件或者目录，删除目录时会将目录中的所有内容全部删除

举例：delete\_recursive DATA:dalvik-cache（删除/data/dalvik-cache文件夹下的所有内容）

5.run\_program

语法：run\_program <program-file> \[<args> ...\]

<program-file>表示要运行的程序，\[<args> ...\]表示运行程序所加的参数

作用：运行终端程序

举例：run\_program PACKAGE:install\_busybox.sh（执行升级包中的install\_busybox.sh脚本）

6.set\_perm

语法：set\_perm <uid> <gid> <mode> <path> \[...<pathN>\]

<uid>表示用户名称，<gid>表示用户组名称，<mode>，表示权限模式，<path>\[... <pathN>\]表示文件路径，可以使多个，用空格隔开

作用：设置单个文件或目录的所有者和权限，像linux中的chmod、chown或chgrp命令一样，只是集中在了一个命令当中

举 例：set\_perm 0 2000 0550 SYSTEM:etc/init.goldfish.sh（设置手机system中的etc/init.goldfish.sh的用户为root，用户组为shell，所有者以及所属用户组成员可以进行读取和执行操作，其他用户无操作权限）

7.set\_perm\_recursive

语法：set\_perm\_recursive <uid> <gid> <dir-mode><file-mode> <path> \[... <pathN>\]

<uid> 表示用户，<gid>表示用户组，<dir-mode>表示文件夹的权限，<file-mode>表示文件的权限，<path> \[... <pathN>\]表示文件夹的路径，可以多个，用空格分开

作用：设置文件夹及文件夹中的文件的所有者和用户组

举 例：set\_perm\_recursive 0 0 0755 0644 SYSTEM:app（设置手机system/app文件夹及其中文件的用户为root，用户组为root，app文件夹权限为所有者可以进行读、写、执行操作，其他用户可以进行读取和执行操作，其中的文件的权限为所有者可以进行读写操作，其他用户可以进行读取操作）

8.show\_progress

语法：show\_progress <fraction> <duration>

<表示一个小部分> <表示一个小部分的持续时间>

作用：为下面进行的程序操作显示进度条，进度条会根据<duration>进行前进，当操作时间是确定的时候会更快

举例：show\_progress 0.1 0（显示进度条当操作完成后前进10%）

9.symlink

语法：symlink <link-target> <link-path>

作 用：相当于linux中的ln命令，将<link-target>在<link-path>处创建一个软链 接，<link-target>的格式应为绝对路径（或许相对路径也可以），<link-path>为“根目录：路径”的形式

举例：symlink /system/bin/su SYSTEM:xbin/su（在手机中system中的xbin中建立一个/system/bin/su的快捷方式）

10.assert

语法：assert <boolexpr>

作用：此命令用来判断表达式boolexpr的正确与否，当表达式错误时程序终止执行※此作用有待验证

11.package\_extract\_file/dir语法：package\_extract\_file(file/dir,file/dir)

作用：提取包中文件/路径

举例：package\_extract\_dir("system", "/system");

package\_extract\_file("system/bin/modelid\_cfg.sh","/tmp/modelid\_cfg.sh");

12.write\_radio\_image

语法：write\_radio\_image<src-image>

作用：将基带部分的镜像写入手机，<src-image>表示镜像文件

举例：write\_radio\_imagePACKAGE:radio.img

13.write\_hboot\_image

语法：write\_hboot\_image<src-image>

作用：将系统bootloader镜像写入手机，<src-image>表示镜像位置，此命令在直到在所有的程序安装结束之后才会起作用

举例：write\_hboot\_imagePACKAGE:hboot.img

14.write\_raw\_image语法：write\_raw\_image<src-image> <dest-root>

作用：将boot.img写入手机，里面包含了内核和ram盘

举例：write\_raw\_image PACKAGE:boot.img BOOT:

15.函数名称: apply\_patch

函数语法: apply\_patch(srcfile, tgtfile, tgtsha1,tgtsize, sha1\_1, patch\_1, ..., sha1\_x, patch1\_x)

参数详解:srcfile-------------------字符串，要打补丁的源文件(要读入的文件)

Tgtfile-------------------字符串，补丁文件要写入的目标文件

tgtsha1-----------------字符串，写入补丁文件的目标文件的sha1哈希值

sha1\_x------------------字符串，要写入目标文件的补丁数据的sha1哈希值patch1\_x----------------字符串，实际上应用到目标文件的补丁

作用解释: 这个函数是用来打补丁到文件。

16.函数名称: apply\_patch\_check

函数语法: apply\_patch\_check(file, sha1\_1, ..., sha1\_x)

参数详解:file----------------------字符串，要检查的文件

sha1\_x------------------要检查的哈希值

作用解释: 检查文件是否已经被打补丁，或者能不能被打补丁。需要检查“applypatch\_check ”函数调用的源代码。

17.函数名称: apply\_patch\_space

函数语法: apply\_patch\_space(bytes)

参数详解:bytes-------------------检查的字节的数字

作用解释: 检查缓存来确定是否有足够的空间来写入补丁文件并返回一些数据。

18.函数名称: read\_file

函数语法: read\_file(filename)

参数详解: filename----------------字符串，要读取内容的文件名

作用解释: 这个函数返回文件的内容

19.函数名称: sha1\_check

函数语法: sha1\_check(data) 或 sha1\_check(data, sha1\_hex, ..., sha1\_hexN)

参数详解:data------要计算sha1哈希值的文件的内容-必须是只读文件格式；

sha1\_hexN------文件数据要匹配的特定的十六进制sha1\_hex哈希值字符串

作用解释: 如果只指定data参数，这个函数返回data参数的十六进制sha1\_hex哈希值字符串。其他参数用来确认你检查的文件是不是列表中的哈希值的一个，它返回匹配的哈希值，或者在没有匹配任何哈希值时返回空。

### 3.4.3 update-script脚本执行流程 ###

OTA升级包中有两个非常重要的脚本，分别是：

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 recoveryimage\_\_From Simba..."

applypatchEMMC:/dev/block/mmcblk0p1:3870720:aee24fadd281e9e2bd4883ee9962a86fc345dcabEMMC:/dev/block/mmcblk0p2 c125924fef5a1351c9041ac9e1d6fd1f9738ff77 4642816aee24fadd281e9e2bd4883ee9962a86fc345dcab:/system/recovery-from-boot.p

else

log -t recovery "Recovery image alreadyinstalled\_\_From Simba..."

\-------------------------------------------

执行 make otapackage命令时，编译脚本(ota\_from\_target\_files)比较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升级流程，我们自己添加的分区可以参考以上几种方式实现。自定义的分区采用何种升级方式需要细细考量，关系到升级包的内容结构和签名过程。

### 3.4.4 升级相关编译的命令 ###

**recovery编译**：make recoveryimage  -j12  ->生成recovery.img, 包含dtb kernel ramdisk.img

**target包编译**: make target-files-package  -j12 ->生成target包，主要是由build/core/Makfile中定义的目标规则生成，是生成ota升级包的中间状态包

**ota包编译**: make otapackage -j12   -> 生成board-ota-xxxx.zip包, 主要是先生成target包，然后把target包转换为ota包，把target包转换为ota包，主要实现是在build/tools/releasetools/ota\_from\_target\_files完成。

**target包转换为ota包**:  ./build/tools/releasetools/ota\_from\_target\_files -v -p out/host/linux-x86 -k build/target/product/security/testkey  board-target\_files-xxxx.zip   board-ota-xxxx.zip

**ota包重新签名**:  java -Xmx2048m -jar out/host/linux-x86/framework/signapk.jar -w build/target/product/security/testkey.x509.pem build/target/product/security/testkey.pk8  no\_signed\_ota.zip   signed\_ota.zip

**target制作差分ota包**:  ./build/tools/releasetools/ota\_from\_target\_files -v -i  board-target\_files-xxx1.zip board-target\_files-xxx2.zip  increase\_update.zip

### 3.4.5 关于在已使能secure boot上OTA升级 ###

在已使能secure boot 的板子上，在make otapackage 后生成的升级包ota.zip后，还需对其进行加密签名操作，具体流程：解压ota.zip-> 使用与板子中efuse里一致的秘钥加密bootloader/ boot.img / recovery.img / dtb.img,等 ->重新打包ota.zip-> 使用ota签名工具（signapk.jar）重新签名。

# 4、总结 #

本文档参考了CSDN上和参考文献中关于Recovery模式及OTA升级的博客和文档，按照自己的理解思路重新梳理，可能会有很多理解的偏差，欢迎大家批评指正。基本的思路就是从OTA包的制作到下载后点击升级如何进入Recovery模式以及在Recovery模式下是怎样实现OTA包的安装升级的。

# 5、OTA升级常见问题 #

**问题现象**：在进行 OTA 升级测试时，下载成功了升级包，在点击立即更新后，手机一直处于提示“正在更新中”，没能重启进行升级。

**问题分析**：经过分析发现，因为OTA 应用不具备系统权限。导致其无法在目录/cache/recovery 中创建command 文件并在该文件中写入命令，从而导致 OTA 应用无法通过这种预定的方式重启机器并进入recovery 模式，无法实现正常 OTA 升级。

**解决方案**：通过在 init.rc 文件中增加 mkdircache/recovery 命令，使该目录默认具备写权限，确保 OTA应用可以正常进行系统升级。

**问题现象**： 下载完升级包后，进入 recovery 模式进行升级时， 系统提示升级失败，手机无法成功升级。

**问题分析**：通过分析日志，升级失败系在对系统文件进行校验时无法通过校验。跟踪编译流程，发现生成的版本文件和用于生成 OTA 升级包的目录文件不一致。根本原因是在生成版本文件后的编译目标文件的过程中，许多模块重新进行了编译。从而导致版本文件和目标文件中存在有着差异的文件。从而导致升级因校验失败而无法正常升级。

**解决方案**：针对这种情况，在编译完目标文件后重新打包生成版本文件，就可以解决两者不一致的问题。

**问题现象**：差分包签名校验失败，报错提示：signature verification failed，Installation aborted。

**解决方案**：（有三种情况）：

1.  差分包签名和版本中签名不一致。开发流版本使用 google 原生签名，故差分包也必须使用

google 原生签名。集成流和发布流版本使用公司签名，故差分包也必须使用公司签名。

2.  差分包导入到 sd卡时，有时会出现导入失败，原因是从命令提示符中看到已经导入成功，实际上差分包的部分数据还在缓存中，没有完全导入 SD卡，所以会出现 SD卡的数据不完整而校验失败，解决方法：将升级包(update.zip包)导入 SD卡后，需要执行 adb shell sync。

3.  在制作差分包过程中，差分包的压缩文件损坏，CRC 校验失败。验证方法：将差分包解压，此时会提示解压失败，正常的差分包应该是能正常解压的。

**问题现象**：升级过程中失败，报错提示：assert failed: getprop("ro.product.device")

问题分析：由于升级过程中需要校验ro.product.device，若新版本中修改了该属性值，则使用前向版本升级时，由于 ro.product.device 不一致，则将会导致升级认为机器手机类型不同而升级失败。

**解决方案**：将assert(getprop("ro.product.device")的脚本语句屏蔽。

**问题现象**：版本号不对应，报错提示：assertfailed: file\_getprop("/system/build.prop", "ro.build.fingerprint")

**问题分析**：由于差分包是基于前后两个版本进行差分后升级，若使用的源版本不对应，便会导致差分包不匹配而升级失败。在开发板上可使用getprop ro.product.device查看现在的是什么值

**解决方案**： 进入系统设置，查看手机版本是否与差分包的ro.build.fingerprint 对应，重新使用正确的版本进行升级。

**问题现象**：版本的文件被手动修改，报错提示：script aborted: assert failed: apply\_patch\_check

**问题分析**： 可能开发人员或中试人员对源版本获取了root 权限，对手机中的文件进行了修改，而升级中刚好会升级这些文件，便会出现升级被改动文件失败的情况。

**解决方案**： 获取手机版本中 system 目录所有文件和用于制作差分包的源版本包中的文件进行比对，找出该文件为何被修改的原因。如果是版本集成问题，需要重新编译版本。

**问题现象**：cache 分区空间不足，报错提示：scriptaborted: assert failed: apply\_patch\_space

**问题分析**：由于差分包升级过程中是需要将需差分包的文件放置在 cache分区下，若需差分的最大文件容量大于 cache 分区的最大容量，则会导致无法放置而升级失败。

**解决方案**：查看差分包中updater-script 脚本中的以下语句：assert(apply\_patch\_space(number))，通过计算 cache 分区容量<number>，则是原因版本中某个被修改的文件很大，该大文件一般是版本中的 iso影像，因此在项目中若产品量产后，是不允许修改 iso 影像的。

**问题现象**：内核升级失败，报错提示：scriptaborted: assert failed: apply\_patch("EMMC:…

**问题分析**：多种情况下都可能导致内核升级失败：

1.  由于版本中若修改了内核的起始地址，将会导致制作出来的差分包在校验内核时 sha 校验失败。

2.  在制作差分包时，若需要升级modem 文件，其正确顺序为先做 AP 侧的差分包和整包，然后把要升级的 MP 侧文件放进去，再签名。若顺序反了：如先放置 MP 侧文件，再制作 AP 侧的差分包和整包，这种也会导致升级内核失败。

**解决方案**：对于第一种情况，则对内核不能使用差分的形式，而要使用整体的形式进行升级，即将对内核的 apply\_patch 语句去除，而使用以下方法。emmc 文件系统：package\_extract\_file("boot.img","/dev/block/mmcblk0p8")或 MTD 文件系统：assert(package\_extract\_file("boot.img","/tmp/boot.img"),write\_raw\_image("/tmp/boot.img","boot"),delete("/tmp/boot.img"));

**问题现象**：升级 boot.img 时，拔电池重启后，会一直进入 recovery 模式，并且不能正常升级。

**问题分析**：由于差分包升级过程中是需要校验的，恢复到一半的时候断电，会导致差分包与源文件对不上号而导致升级失败。

**解决方案**：升级中提示用户不能拔电池，或者使用整包升级而不是差分升级包

笔记：[关于ota的文章1][ota_1]

[关于ota的文章2][ota_2]

[Android OTA升级原理及流程分析（一至八）][Android OTA]

[OTA和Recovery系统升级流程介绍][OTA_Recovery]

[OTA升级签名校验简析][OTA 1]

本文基于[此文][Link 1]修改

[Android_Recovery_update.zip]: https://blog.csdn.net/kevinx_xu/article/details/8589853
[OTA]: https://blog.csdn.net/qq_31811537/article/details/85846680#comments
[20130608143749187]: /images/20220330/1ee639d395fa48b68d55702509cc1a1a.png
[20130608145211015]: /images/20220330/1218879c869149768164e74453623d70.png
[20130608145716125]: /images/20220330/8cde794b8ec445b7b8dd563dd1fd42d2.png
[ota_1]: https://blog.csdn.net/huangyabin001/article/category/2703721/
[ota_2]: https://blog.csdn.net/yexiangcsdn/article/category/7430187
[Android OTA]: http://www.360doc.com/content/15/0820/13/2036337_493624899.shtml
[OTA_Recovery]: https://blog.csdn.net/zhangshuaizaxia/article/details/50580383
[OTA 1]: https://segmentfault.com/a/1190000014662178
[Link 1]: https://blog.csdn.net/teliduxing1029/article/details/51536560