1. Production of differential packages
1.1 Directory structure of update.zip package
|----boot.img #boot.img is the file required to update the boot partition. boot.img mainly includes the contents of the kernel+ramdisk
|----system/ #system/ directory and will be placed in the system partition of the system after the upgrade. It is mainly used to update some applications of the system or some libraries that the application will use, etc. You can copy all files in out/target/product/tcc8800/system/ to this directory instead of
|----recovery/
|----recovery-from-boot.p #recovery-from-boot .p is the patch of boot.img and recovery.img, mainly used to update the recovery partition
|----etc/
|----install-recovery.sh #install-recovery.sh in the etc/ directory is the update script
|---META-INF/
|CERT.RSA #Signer block file associated with the signature file, which stores the public signature used to sign the JAR file.
|CERT.SF #Signature file for JAR files, where prefix CERT stands for signer
|MANIFEST.MF #This file defines the data related to the structure of the package. Similar to the mainfest.xml file of an Android application.
|----com/
|----google/
|----android/
|----update-binary #update-binary is a binary file, equivalent to a script interpreter, capable of recognizing updater-script operations described in . This file is generated in out/target/product/tcc8800/system bin/updater after the Android source code is compiled, and can be obtained by renaming updater to update-binary. The name of the file in the specific update package is determined by the value of the macro ASSUMED_UPDATE_BINARY_NAME in bootable/recovery/install.c in the source code.
|----updater-script #This file is a script file that specifically describes the update process. The script can be written on a case-by-case basis to suit specific needs. The name of the file is determined by the value of the macro SCRIPT_NAME in the bootable/recovery/updater/updater.c file in the source code.
|----android/
|----metadata #Describe the metadata of device information and environment variables. It mainly includes some compilation options, signature public key, timestamp and device model, etc.
The userdata directory can be added to the package to update the userdata part of the system. This part of the content will be stored in the /data directory of the system after the update
During the specific upgrade, there are roughly three steps to check the update.zip package: 1. Check whether the SF file matches the RSA file. ②Check whether MANIFEST.MF is consistent with the digest in the signature file. ③ Check whether the files in the package are consistent with those described in MANIFEST.
Projects on the MTK platform
For projects on the MTK platform, it is necessary to add adaptation files (scatter.txt, SEC_VER.txt, type.txt) that are strongly related to the project, scatter.txt scatter-loading files, and scatter-load executable image files into different memory segments ( File content: specify the starting addresses of different memory segments).
type.txt is generated by the build upgrade package process. The value in it is 1 for FullOTA and 0 for DiffOTA. This value will be checked in the update process of the upper layer of android.scatter.txt is also generated during the build upgrade package, and the content in it comes from /mediatek/misc/ota_scatter.txt. mediatek/misc/ota_scatter.txt is generated when building full ota. This file is mainly used to check whether the partition layout has changed before and after the upgrade during the upgrade.
SEC_VER.TXT is copied from alps\mediatek\custom\$PROJECT\security\recovery at compile time, it will be used after opening SUPPORT_SBOOT_UPDATE
Upgrade notes :
1. Signature changes and model changes will lead to upgrade failure;
2. Partition changes cannot be upgraded through OTA;
3. When making OTA differential packages locally, ensure that partitions and signatures are consistent with the produced version.
1.2 Making differential
packages There are two ways to make update.zip package, namely manual making and command generation.
The first manual production: that is, manually create the required directory according to the directory structure of update.zip. Then copy the corresponding file to the corresponding directory, such as adding a new application to the system. You can copy the newly added application to the newly created update/system/app/ (the system directory is the system directory generated after copying and compiling the source code in advance). After packaging and signing, copy it to the SD card and you can use it.
The second production method: command production. The Android source code system provides us with the command to make update.zip flash package, namely make otapackage. This command is executed in the source code root directory after compiling the source code.
Specific operation method: Execute ①$ .build/envsetup.sh in the root directory of the source code
②$ lunch and then select the configuration you need (eg 17).
③ $ make otapackage.
After compiling the source code, it is best to perform the above steps ① and ② to prevent the error message that the corresponding rule is not found when executing ③. The location of the upgrade package generated after the command is executed is out/target/product/full_tcc8800_evm_target_files-eng.mumu.20120309.111059.zip. Rename the package to update.zip, and copy it to the SD card for use.
2) Use the make otapackage command to generate the process analysis of update.zip.
Executing the make otapackage command in the source root directory to generate the update.zip package is mainly divided into two steps. The first step is to compile and generate an update original package (zip format) according to the Makefile. The second step is to run a python script with the zip package prepared in the previous step as input, and finally generate the upgrade package we need . These two processes are further analyzed below.
1. Two incremental packages are required
The incremental package can be downloaded from the server or generated locally. The local generation is generated by using ./mk hq8127_tb_b2b_l a1992[lenovo] otapackage and then /out/target/product/huaqin82_tb_b2d_td/obj/PACKAGING/target_files_intermediates. zip incremental package
(There is an exception at this time:
Modify /usr/lib/python2.7/zipfile.py with administrator privilegesdef __init__(self, file, mode="r", compression=ZIP_STORED, allowZip64=True):
false to true and the compilation succeeds
sudo gedit / usr/lib/python2.7/zipfile.py
)
2. Make a differential package based on two incremental packages./build xxx - k xxx -i old package new package differential package
./build/tools/releasetools/ota_from_target_files -k device/mediatek/common/security/hq8127_tb_b2b_l/releasekey -i old.zip new.zip old_to_new.zip
The signature of the update.zip package: The update.zip update package needs to be signed after it is produced. Otherwise, an error message of authentication failure will appear during the upgrade. And the signature should use the same encryption public key as the target board. The specific path generated after the Android source code is compiled for the encryption public key and the three files required for encryption is:
out/host/linux-x86/framework/signapk.jar
build/target/product/security/testkey.x509.pem
build/target /product/security/testkey.pk8 .
The update.zip package produced by the command make otapackage is already signed. If you make the update.zip package yourself, you must sign it manually. Specific encryption method: $ java –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 The
above command is executed in the path where the update.zip package is located, where the signapk.jar testkey.x509.pem and testkey.pk8 files are referenced using absolute paths. update.zip is the package that has been typed, and the update_signed.zip package is the signed package generated after the command is executed.