Analysis of the Processing Process of OTA Upgrade Package Creation Tool
1. Overview
OTA upgrade package creation tool is a command line tool implemented in python. The tool is located in the source_root/ \build\tools\releasetools directory, and the entry file is ota_from_target_files. This tool can process the source or target software version package generated by compilation to generate the final OAT complete upgrade package (default), or through the parameter -i control, generate an OTA incremental upgrade package (differential package).
Source or target software version packages are sourced by adding the compile OTA version compile option $(INTERNAL_OTA_PACKAGE_TARGET) to the version build configuration file main.mk. This is not described in detail in this document.
Location:
# Build files and then package it into the rom formats
# add to output $INTERNAL_OTA_PACKAGE_TARGET
: 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. The running environment
tool directly provides the python source code, you need to install the python parser on the execution environment (python running environment, similar to java's JRE) . The tool requires the version of python and needs to be executed on the version of python 2.4 or higher, otherwise an error may occur during processing.
3.
The command line parameters of the command line parameter tool have slight changes due to different versions. Here are some common parameter descriptions:
-b (--board_config) <file> Use
pass to process this parameter match in the code, and do not process it.
-k (--package_key) <key>
Specifies the key used for signing. By default, it will be obtained from the META/misc_info.txt file of the specified source or target version package, or use "build/target/product/security/testkey". For making an incremental upgrade package, the default key is based on the key pair in the specified path in the source version package file META/misc_info.txt, rather than obtained from the file in the target version package, it should be noted that .
-i (--incremental_from) <file>
The zip specified after the -i parameter will be processed as the source version package made by the differential package
-w (--wipe_user_data)
Generate upgrade packages that wipe user date partitions at install time
-n (--no_prereq)
ignore timestamp checks for frequent upgrades and upgrades of OTA packages during development
-e (--extra_script) <file>
upgrades in production Insert an external script into the upgrade script in the package.
-a (--aslr_mode) <on|off>
Specifies whether to open the aslr mode of the upgrade package, the default is on state
-p (--path) <dir>
Specify a path as a tool to search for binary executable files during operation route of. In the upgrade package production, we generally specify the /out/host/linux-x86 directory as the path to search for the signature tool.
-f (--fota) <fota>
Specifies whether to use the fota upgrade method. The default is not to use it.
4. Making an incremental or complete upgrade package
When making an upgrade package, it needs to be done in the product code compilation environment. You need to specify the path where the signature tool and key file are located. Among them, the path where the signature tool is located is specified with the parameter -p, and this path is /out/host/linux-x86. The path where the key file is located can be left unspecified, so the default value will be used, and the tool will automatically parse it from the files in the old and new upgrade packages.
4.1 Make incremental upgrade package
$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
Among them, -p $soure_root/out/host/linux-x86 specifies a path, which is the search range directory for the signature tool during tool processing
-I $old_OTA_zip $new_OTA_zip specifies the incremental upgrade package production from $old_OTA_zip file to $new_OTA_zip
The final $Out_diff.zip specifies the path and name of the output incremental upgrade package file.
4.2 Make a complete upgrade package
$Source_root/build/tools/releasetools/ota_from_target_files –p $soure_root/out/host/linux-x86 $new_OTA_zip $Out_full.zip
Among them, only need to specify the search scope of the signature tool and the new version package zip file and the file path and name of the output full upgrade package.
5. Tool processing process
Open the tool entry ota_from_target_files file with an integrated development environment such as a text editor or eclipe. You can see that the tool has imported two other modules common.py and edify_generator.py in the same directory. Among them, common.py contains the general processing procedures of some tools, and edify_generator.py places the script generation processing procedures of recovery mode.
Jump to the end of the file, if __name__ == '__main__' is the code entry, as follows:
5.1 Platform difference processing
First call common.CloseInheritedPipes() in the Common.py module for platform difference processing. Due to file descriptor (PIPE) leaks on Mac OS, preprocessing is performed first. This process does not deal with Windows or Linux platforms. The processing process is as follows:
if platform.system() != "Darwin":
return
5.2 The
main(sys.argv[1:]) is passed as parameter.
After running the platform differentiation process, Call main(sys.argv[1:]) to enter the process of making the OAT package. Among them, main(sys.argv[1:]) accepts all parameters passed in from the command line.
5.3 Parameter parsing and processing
option_handler(), common.ParseOptions()
analyze and process the parameters passed in from the command line, and store them in the global variable of OPTIONS. If the number of parameters is not 2, it will directly output the document string of the tool, and then exit, as follows:
5.4 Loading an external script (parameter -e processing)
If an external script is specified by an input parameter, first open the external script for use. The external script file will be appended to the end of the installation script of the incremental upgrade package or the full upgrade package. As follows:
5.5 Source or target version zip package analysis
Whether entering the incremental upgrade package processing process or the complete upgrade package processing process, the target version package (new_zip) is parsed first, which is in line with the reasonable processing process. If the user specifies the -i parameter, the source version package (old_zip) is parsed.
After the version package is parsed, the result will be stored in the variable OPTIONS.info_dict or OPTIONS.source_info_dictk. The data stored in this data structure is referenced as follows:
OPTIONS.info_dict with parsed reference:
5.6 WriteFullOTAPackage() complete upgrade package
processing
A version of recovery_api_version, possibly very early. So it is assumed that recovery_api_version will not change frequently, otherwise it will affect the normal upgrade. This does not exist in the incremental upgrade mechanism.
5.6.2 Principles of file generation in incremental upgrade package The
process of generating other files in the package is a process of copying and packaging files: copying the files under system/ and outputting the zip package, and obtaining the packaging process of boot.img and recovery.img.
5.6.3 Other processing procedures
include generating the installation script of the complete upgrade package, and judging if the file size exceeds the limit. The upgrade script is located in the full upgrade package zip file\META-INF\com\google\androi\updater-script.
According to fstab/yaffs2 in OPTIONS.info_dict parsed by version zip, determine whether the size of boot.img exceeds the limit.
5.7 WriteIncrementalOTAPackage() Incremental Upgrade Package Processing Process
5.7.1 Incremental Upgrade Package Processing
Decompresses the source version package, parses the files in the zip package, and stores the result in a variable. Please refer to Section 5.5 for this process.
5.7.2 Related parameter processing
OPTIONS.package_key: Get the key file path. If the user does not specify the -k parameter, it will be extracted from the file in the source_zip package by default.
OPTIONS.verbose: The processing is visible to STD_OUT. 5.7.3 WriteIncrementalOTAPackage(input_zip, source_zip, output_zip, OPTIONS.fota) for incremental
upgrade package processing true or false of the mode. 1. Determine the recovery_api_version value obtained from the zip package of the source version. If it is 0, give a warning indication: 2. Load the files in the system/ directory in the zip package of the source and target versions into the memory file object to be processed. 3. Compare the files in the source and target versions, classify and process them, and the code is as follows: verbatim_targets = [] #Store the list of files that do not need to be processed or must be included and retained intact. These files that need to be protected or do not need to be protected are stored in The code can be specified as follows: If a file that needs to be protected is encountered during this process, it will be added to the output zip file intact. diffs = [] #Store a list of diff files by comparing file.sha1 values. If the sha1 value is different, it will be appended to the difference file list for subsequent processing. This file in the source zip and the corresponding file in the target zip are considered identical if the sha1 values are the same.
4. Calculate the difference between the files in the above difference list, generate and finalize the difference file (patch), these files are all files ending with .p suffix. This package also counts the percentage size of the patch file and the original file when the patch is generated, and outputs this information to STD_OUT for user reference.
Differential file processing entry:
Differential file generation and packaging:
output to STD_OUT Effect:
5. The difference file is added to the incremental upgrade package rules, as follows:
If the difference file does not exist (None), it will be added, or the difference file is the same as the original file. If it is large (the threshold of a certain percentage of %95 is the judgment standard), then this file will not be processed and will be directly added to the incremental upgrade package that will be generated.
6. Enter other subsequent processing, mainly the generation of incremental upgrade scripts. For the final generated upgrade script, please refer to the incremental upgrade zip package\META-INF\com\google\android\updater-script.
5.8 Turn off the output zip package and signature output
Turn off the output incremental upgrade package or complete upgrade in the open state, then sign it, and output it to the directory location defined by args[1]. The signature key location is defined by the global variable OPTIONS.package_key. Under the processing procedure:
5.9 Clean up the environment
Clean up the temporary directory generated during the processing.
5.10 Done
OTA analysis updater
updater-binary
1 in the upgrade package, updater-binary 2 in the OTA upgrade package,
line 283 in Android_4.4/build/tools/releasetools/edify_generator.py
3, update-binary as the parser of update-script, upgrade implementation of execution
Recovery accepts the upgrade package brief process:
1. Enter OTA - manually specify the OTA upgrade package through the recovery UI
- specify the OTA package through the /cache/recovery/command entry file
2. Recovery accepts external parameters: recovery --update-zip =/cache/update.zip – locale=lz_CN
3. The Recovery process enters the upgrade package installation process
4. The Recovery process starts processing the update package from line 1022
5. The jump after the installation logic in Recovery starts
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 When the update-binary is really executed to parse the update-script file
// 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) {