- The full name of OTA is Over-the-Air Technology. This kind of online upgrade, without flashing the upgrade method, is called OTA upgrade. OTA upgrade can be completed with the help of Wifi wireless network or mobile phone mobile network, which is equivalent to completing the upgrade with the help of air wireless network;
- The OTA function is needed in the project, so with this article, refer to the OTA implementation mechanism of Android, you can see that the OTA mechanism of Android has also changed with the version upgrade, and this is summarized below
Non-A/B System Updates
First look at the traditional partition structure of Android
| bootloader: After the device is started, it will first enter the bootloader program. Here, it will select which mode to boot into by judging the key combination when starting up (there will also be some other judging conditions, so I won’t go into details here). There are mainly Android system, recovery mode, fastboot mode, etc. |
| boot: Contains the kernel and ramdisk of the Android system. If the bootloader chooses to start the Android system, it will boot the kernel of this partition and load the ramdisk to complete the kernel startup. |
| misc: Mainly used for communication between the Android system and the bootloader, enabling the Android system to reboot into the recovery system and perform corresponding operations. |
| system: Contains executable programs, libraries, system services and apps of the Android system. After the kernel starts, it will run the first user-mode process init, which will start the Android system components according to the rules in the init.rc file, and these system components are in the system partition. After the Android system components are started, the system app — launcher desktop will be started at last, and the Android system startup is completed. init process start |
| vendor: Contains vendor-specific executable programs, libraries, system services, and apps. This partition can be regarded as a supplement to the system partition, and some functions of the manufacturer's custom ROM can be placed in this partition. |
| userdata: user storage space. Generally, this partition of a newly purchased mobile phone is almost empty, and the apps installed by the user and user data are stored in this partition. The mobile phone storage (sdcard) accessed by the user through the system file manager is part of this partition |
| recovery: contains the kernel and ramdisk of the recovery system. If the bootloader chooses to start the recovery mode, it will boot the kernel of this partition and load the ramdisk, start the init in it and then start the recovery program, and then you can operate the recovery mode functions (mainly including OTA upgrade, dual clearing, etc.). |
| cache: Mainly used for caching system upgrade OTA packages, etc. Shuangqing refers to the cleaning of userdata partitions and cache partitions. |
upgrade process
- The Android system receives the OTA push from the server and downloads the OTA package to the cache partition.
- After the download of the OTA package is completed, a command will be written to the misc partition, indicating that it will enter the recovery mode at the next startup and use the OTA package to upgrade.
- restart cellphone.
- After restarting, enter the bootloader first, and the bootloader will first judge the key combination, power register, etc., and then read and analyze the contents of the misc partition. Since the command has been written to the misc partition in step 2, the bootloader here will boot the recovery system after reading the command.
- Enter recovery, read the OTA package in the cache partition, and parse the upgrade script in it, and upgrade each partition of the system according to its instructions
- recovery will clear the misc partition
- restart cellphone
- After restarting, enter the bootloader first, and judge the button combination, power register, misc partition content, etc., and the Android system will be started by default. At this time, it is a new version of the system after OTA upgrade.
shortcoming
- The downloaded OTA package takes up space in the cache partition
- Unable to revert back to the old system if the upgrade fails
A/B system update
In order to solve the above two problems, after Android O, Google introduced a new partition structure called A/B partition. Correspondingly, the traditional partition structure is called non-A/B partition.
The A/B partition structure, as the name suggests, divides the system partition into two slots (slots) A and B. When the phone starts up, it will choose slot A or slot B to start, and only use the partition in the current slot during operation.
Adopting A/B partition structure, can realize seamless upgrade. For example, if the user is running slot A and receives an OTA push at this time, the system will obtain OTA data from the server and write it directly to the slot to be upgraded. There is no need for temporary storage space for OTA packages, so there is no need to store OTA data in the cache or Reserve enough space for the userdata partition. When the upgrade of the B-slot system is completed, the user will receive a restart prompt. At this time, restarting the phone will automatically switch to the new version of the B-slot system.
In order for the bootloader to judge whether a system (slot) is ready to start, Google defines several identifications of A/B slots:
- bootable: indicates whether the system of this slot can be started.
- successful: Indicates whether the system in this slot has been successfully started. Only when the system in this slot can start, run, and perform OTA upgrades, the slot will be marked as successful from the user mode.
- active: Indicates whether the slot is the currently running system, only one of the two slots can be marked as active.
shortcoming
- The storage space required by the system is more than that required by non-A/B OTA, because the partition boot. system, vendor, etc. of the A/B system have two sets of partitions
Virtual A/B
In order to solve the above problems, Android has added a virtual A/B system update in the back;
- For the AB partition, it is a traditional backup, that is, system_b is a copy of system_a; and for virtualAB, the copy-on-write snapshot technology is used, so these dynamic partitions do not need AB, and snapshots are created if there is any modification. It means that there is no problem with the modification of the partition, and the snapshot will be merged with the original base as the latest base
- What virtualAB backs up is not a copy, but a snapshot. save space.
dynamic partition
What dynamic partition solves is that each partition image no longer needs to reserve space. With dynamic partitioning, vendors don't need to worry about the size of individual partitions such as system, vendor, and product. Instead, the device allocates a super partition with dynamically resizable subpartitions.
Dynamic partitioning is implemented using the dm-linear device-mapper module in the Linux kernel. On Android Q, access to the system partition is intercepted by the driver and forwarded to an area of the super partition. Similar to doing a mapping relationship.
Snapshot
For example, I have a string of data "ABCDEF", the storage address is from 0x0 to 0x5, the backup is that I find a space from 0x7 to 0x12, and I completely copy the data to this space. From this point of view, the disadvantage of backup is obvious. If The data is relatively large, but the changes are not many or concentrated in a certain area, which takes up a lot of space, and for example, I only have 1000 bits of data and I often change 50 bits of data, and you back them up, which wastes 950 bits of data amount of space. The snapshot technology does not back up all the data, I only record the time point of the last write operation on this part of the data and the changed data (not all data), so that the data I need to record is much less than backing up all the data up.
One implementation in the snapshot is copy-on-write; that is, if I want to change the string of data "ABCDEF" (the stored address is from 0x0 to 0x5) to "ABCMEF", and only change the D in it to M, it is me First read the metadata (read D from 0x3), then change D to M, then write the changed data to another location (snapshot), and then write the changed data to the metadata (0x3)
process
- First create system_b_base, correspondingly mapped to system_a;
- Create sytem_cow (copy-on-write) (may consist of free blocks in the superpartition, or a loop device on blocks allocated on /data, or both)
- Base and cow form a unified snapshot
- When the device reboots after applying the update, a snapshot is found, and the system mounts from the snapshot until it boots successfully. After successfully mounting from the snapshot, merge the contents of the base and the snapshot. This will delete the snapshot device
summary
