Android 4.0 OTA update process overview

Analyze the recovery process and start with analyzing the upgrade package.
The upgrade package can be generated by the make otapackage command, which is generated by makefile and the packaging script (Python.
The generation rules are complex, including the signature process, which has no details and focuses on its content.
After the upgrade package is decompressed, the structure is as follows:

/home/simba/update_zip|-- boot.img|-- Manifest.xml|-- META-INF|   |-- CERT.RSA|   |-- CERT.SF|   |-- com|   |   |-- android|   |   |   `-- metadata|   |   `-- google|   |       `-- android|   |           |-- update-binary|   |           `-- updater-script|   `-- MANIFEST.MF|-- recovery|   |-- etc|   |   `-- install-recovery.sh|   `-- recovery-from-boot.p`-- system    |-- app    |-- bin    |-- build.prop    |-- etc    |-- fonts    |-- framework    |-- lib    |-- media    |-- usr    `-- xbin66 directories, 1025 files

Many entries are omitted in the above structure, which are files and directories under the system directory.
Important script files include:

• META-INF/COM/Google/Android/Updater-script
• Recovery/etc/install-recovery.sh

Source file for upgrade:

• Boot. img
• /System
• Recovery/recovery-from-boot.p

Another important file is/etc/recovery. fstab, which is determined by the emmc partition solution.

-------- /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--------------------------------------------

The otgpackage compilation script fills the Updater-script according to the file, which will be displayed later.
This file exists in the recovery partition. after entering the recovery mode, you can access it.

There are many ways to enter the recovery mode, but each method requires the combination of bootloader.
After entering the recovery mode, the upgrade package will be verified. if the process is not shown, the update package will fail to exit.
After entering the recovery process, I mainly care about the work of Updater-script.
The first is Updater-script, which can easily analyze the workflow in the Code, as follows:

--------- Updater-script ----------------.... // omit several formats ("ext4", "emmc", "/dev/block/mmcblk0p5", "0"); mount ("ext4", "emmc ", "/dev/block/mmcblk0p5", "/system"); // mount the system partition. Here there is a ing between "/dev/block/mmcblk0p5" and "/system", from the recovery. fstab mentioned above. Package_extract_dir ("recovery", "/system"); // extract the recovery directory in the zip package to the system/system directory for use in future upgrades to the recovery partition (install-recovery.sh, recovery-from-boot.p) package_extract_dir ("system", "/system"); // decompress the system directory in the zip package to the system/system directory to upgrade the system partition ...... // omit several symlinks ("mksh", "/system/bin/sh"); symlink ("toolbox ", "/system/bin/cat ",....); // create a soft link and omit several retouch_binaries ("/system/lib/libbluedroid. so ",.....); // touch various dynamic libraries and omit some set_pe Rm_recursive (0, 0, 0755,064 4, "/system ");...... // modify the permission and omit several show_progress (0.200000, 0); // display the upgrade progress ...... // modify the permission. Some package_extract_file ("boot. IMG ","/dev/block/mmcblk0p1 "); // set boot. decompress IMG to the block device to upgrade the boot partition. The boot partition contains kernel + ramdiskshow_progress (0.100000, 0); unmount ("/system"); // uninstall the system partition ---------------------------------------------

After the system partition and boot upgrade are completed, restart and enter the normal system.
The normal startup system init. RC defines a service used to burn the recovery partition, that is, to execute the install-recovery.sh, which is executed once at each startup.

----- /init.rc ------...service flash_recovery /system/etc/install-recovery.sh    class main    oneshot...--------------------

The install-recovery.sh is extracted from the Updater-script in recovery mode with the following content:

------- /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 recovery image__From Simba..."  applypatch EMMC:/dev/block/mmcblk0p1:3870720:aee24fadd281e9e2bd4883ee9962a86fc345dcab EMMC:/dev/block/mmcblk0p2 c125924fef5a1351c9041ac9e1d6fd1f9738ff77 4642816 aee24fadd281e9e2bd4883ee9962a86fc345dcab:/system/recovery-from-boot.pelse  log -t recovery "Recovery image already installed__From Simba..."fi-------------------------------------------

When you execute the make otapackage command, compile the script to compare boot. IMG and recovery. IMG to get the patch file recovery-from-boot.p.

The recovery-from-boot.p is also extracting Updater-script to the system directory in recovery mode.

The install-recovery.sh script adds the boot partition with this patch to update the recovery partition.

Before a patch is applied, the install-recovery.sh calculates the sha1 of the current recovery partition.

If the calculation result is the same as that recorded in the script (c125924fef5a1351c9041ac9e1d6fd1f9738ff77), it indicates that it has been updated and will not be operated any more.
This completes the upgrade of the/system directory, boot partition (kernel + ramdisk), and recovery partition (kernel + ramdisk-recovery.

The above is the standard Android upgrade process. We can add partitions by referring to the above methods. The content structure and signature process of the upgrade package need to be carefully considered.