OTA Update for Android Learning

We need to deal with the update related issues used by some applications. We learned that android build system will use open-source bsdiff to update packages. this article analyzes OTA update in the android system.

First, let's take a look at the overall OTA framework.
Build System Support, used to create the required OTA update image (including all updates and some updates)
Releasetools (build/tools/releasetools /)
Used in combination with build system to generate the corresponding full/incrementalupdate.zip package
Search for the target-files-package keyword in build/core/main. mk and Makefile.
Build/tools/releasetools
── Check_target_files_signatures -- used to check the relationship between the cert and the update package
── Common. py -- various tool classes, parameter processing/META file Processing/image generation/sign certification/patch file operations, etc.
── Edify_generator.py -- used to generate the edify script. For details about edify, refer to readme and tjworld under bootable/recovery/edify,
It mainly provides manufacturer with a simple shell language for necessary recovery operations. Later, we will write an article separately to describe how to use edify.
<Edify for Android learning is a magic horse>
── Img_from_target_files -- the xxx. imgfile used by the fastboot update command to generate the target zip file
── Ota_from_target_files -- generate a TFP update package with various signatures
└ ── Sign_target_files_apks -- used to sign the apk or generate a zip update package. For details, refer to/development/pdk/docs/porting/release_keys.jdhttp: // androidxref.com/source/xref/devel
Converts the test-key to the release key of the OEM.

Use make target-files-packageto compile update.zip. The generated description and image file are
Out/target/product/generic/obj/PACKAGING/apkcerts_intermediates/full-apkcerts-eng.txt
Out/target/product/generic/obj/PACKAGING/target_files_intermediates/full-target_files-eng.zip

Note that the above are for the boot. img generated by the mkimage (system/core/mkbootimg) tool to generate the corresponding recovery and update image.
The appeal tool does not mention boot. interaction between img and update image. Therefore, when creating an update image, you must manually ensure that the update image you created can be installed on a device with a boot image in advance !!!

At the same time, an extended API is provided to the OEM so that the OEM can define some special operations and integrate them into the update process. for details, refer to the following implementation in nexus one in CyanogenMod:
Extended Definition of releasetools in CyanogenMod/device/htc/passion-common/BoardConfigCommon. mk: TARGET_RELEASETOOLS_EXTENSIONS: = device/htc/common
CyanogenMod/device/htc/common/updater/-- is the implementation of the respective updater of the OEM.
CyanogenMod/device/htc/common/releasetools. py -- all of them must implement extension interfaces, such as FullOTA_Assertions ()/FullOTA_InstallEnd ().

Briefly refer to the update.zip Generation Process

Note that re-sign apks replaces the Test signature with the signature of each oem manufacturer for apk security.
The signature is a 2048-bit RSA keys with public exponent 3 generated using openssl.

Related filesystem partition
When talking about Update, I have to mention the android partition (see the configurations of various OEMs)
Boot, which contains the following files: metadata, kernel image, ramdisk, optional 2nd-stage bootloader image, generated by mkbooting (system/core/mkbooting)
For more information about the boot. img format, see system/core/mkbooting/bootimg. h.
[Plain]
/*
** + ----------------- +
** | Boot header | 1 page
** + ----------------- +
** | Kernel | n pages
** + ----------------- +
** | Ramdisk | m pages
** + ----------------- +
** | Second stage | o pages
** + ----------------- +
**
** N = (kernel_size + page_size-1)/page_size
** M = (ramdisk_size + page_size-1)/page_size
** O = (second_size + page_size-1)/page_size
**
** 0. all entities are page_size aligned in flash
** 1. kernel and ramdisk are required (size! = 0)
** 2. second is optional (second_size = 0-> no second)
** 3. load each element (kernel, ramdisk, second)
** The specified physical address (kernel_addr, etc)
** 4. prepare tags at tag_addr. kernel_args [] is
** Appended to the kernel commandline in the tags.
** 5. r0 = 0, r1 = MACHINE_TYPE, r2 = tags_addr
** 6. if second_size! = 0: jump to second_addr
** Else: jump to kernel_addr
*/
This description is useful when you need to customize your rom or burn your compiled kernel to your mobile phone. For more information, see

System, system programs and apk, etc.
Data, user data, will be factory reset clear
Recovery, in order to restore
Misc, including Bootloader Control Block (BCB). the recovery console interacts with bootloader through it.
Cache, used to support the temp partition of update, and used as temp by a specific apk

Another important file, recovery. fstab, is used to provide the file system that can be loaded and the corresponding mount node for the recovery console and releasetools.
The following is the recovery. fstab of nexus one.
[Plain]
# Mount point fstype device [device2]
 
/Boot mtd boot
/Cache yaffs2 cache
/Data yaffs2 userdata
/Misc mtd misc
/Recovery mtd recovery
/Sdcard vfat/dev/block/mmcblk0p1/dev/block/mmcblk0
/System yaffs2 system
/Sd-ext ext4/dev/block/mmcblk0p2

Device Side Support, used to receive update images and update them in recovery mode

All the code is in/bootable/recovery. Of course, the code in CyanogeMod is similar to the real device.
In this case, it is actually a completely independent small system and requires a variety of tool libraries (linux cannot be used, because linux has not started running yet, this is just a simple software-hardware interaction environment ).
We can see many examples of cropping customization.
I will write an article dedicated to analyzing andorid bootloader and recovery. For more information, see <bootloader for Android learning> and <recovery for Android learning>
Recovery Console (RC)
This is the recovery UI interface that is opened by holding down the specified key during startup (often flushed and should be familiar with it)
Is the overall portal for all other recovery work, managing all recovery work and interacting with RecoverySystem in bootloader and framework
From the implementation of nexus one and AOSP, we can see that most vendors provide their own rc ui plugin to make their own recovery UI.
The 26 pages in reference 5 provide a simple way to change the Console UI :)

Bootloader
Used to help the hardware initialize resources and select the RC or Andorid system as required
In addition to interacting with RC, it also accepts reboot notification (register_reboot_notifier () from kenrel through BCB ()).

Misc partition and Its BCB
Communication Environment and commands between RC and bootloader

Updater
It is included in the OTA update.zip file and is controlled by the recovery console to perform specific update actions (including verification, decompression, and installation)
The Extension Mechanism of plugin is also provided, allowing various vendors to customize some additional updater actions.

SW Update UI intent from Settings application

Code in
RecoverySystem APIs

Server Side Support, used to send update notifications and images to be updated
This is a dark land. No vendor has published its own push and deploy architecture :(((
Update.zip OTA deploy
References:
<Bootloader for Android learning>
<Recovery of Android learning>
<Learn from Android and customize bootloader + recovery>
AOSP source code
Introduction to http://tjworld.net/wiki/Android/UpdaterScriptEdifyFunctions -- edify
Https://events.linuxfoundation.org/images/stories/pdf/lf_abs12_boie.pdf

From Melody_lu123