About "A / B" partition structure and "seamless" updates
Or the answer to the question: "What is wrong with my device? Why is it not like everyone else?"
Let's start. You've probably heard that some devices use some kind of outlandish A / B partition structure. It differs from the structure in most Android devices.
It is somehow strange and unusual set updates, chat with the system running (O_o). Inside OTA image of another, unreadable structure. Install TWRP is accompanied by some, earlier met, challenges, additional manipulation and significantly different from all that "I" had seen. Everyone is talking about some of the letter "A", "B", slots, and the two systems, and other, incomprehensible "me" things.
Well, let's try to figure it all out. Let's start with general questions: Q: Well, who invented all this? Damned manufacturers simple geeks complicate life? A: New structure "
A / B sections "Designed just Google-th as part of the global changes in the Android architecture. It has been successfully used in Google Pixel smartphones, Essential Phone and a variety of other devices. In the future, more and more devices from third-party manufacturers will use it. There is nothing bad and wrong with that, on the contrary It opens many new possibilities.
Q: So what is the A / B partition structure? A: Speaking quite simply - inside your device there are two at once (and depending on the implementation and more), independent among themselves, systems. Something like
MultiROM (if you heard about this), only with a much more thoughtful implementation at a lower level. If you are interested in specific information explaining all aspects, please continue reading.
Section table on the example of Google Pixel: In order to visually display the theory outlined above, and see the differences compared to other devices, let’s look at the Google Pixel table of sections.
If you are not familiar with the structure of partitions in Linux-like systems, and Android in particular, I advise you to search for information about this in Google, since it is complete.
We are interested in specific sections that exist in two copies for clarity and demonstration.
So (we open the code completely):
/ dev / block / bootdevice / by-name / aboot_a # Partitions of the first bootloader (Slot "a")
/ dev / block / bootdevice / by-name / apdp_a # Partitions of the first bootloader (Slot "a")
/ dev / block / bootdevice / by-name / bootlocker_a # Partitions of the first bootloader (Slot "a")
/ dev / block / bootdevice / by-name / cmnlib32_a # Partitions of the first bootloader (Slot "a")
/ dev / block / bootdevice / by-name / cmnlib64_a # Partitions of the first bootloader (Slot "a")
/ dev / block / bootdevice / by-name / devcfg_a # Partitions of the first bootloader (Slot "a")
/ dev / block / bootdevice / by-name / hosd_a # Partitions of the first bootloader (Slot "a")
/ dev / block / bootdevice / by-name / hyp_a # Partitions of the first bootloader (Slot "a")
/ dev / block / bootdevice / by-name / keymaster_a # Partitions of the first bootloader (Slot "a")
/ dev / block / bootdevice / by-name / msadp_a # Partitions of the first bootloader (Slot "a")
/ dev / block / bootdevice / by-name / pmic_a # Partitions of the first bootloader (Slot "a")
/ dev / block / bootdevice / by-name / rpm_a # Partitions of the first bootloader (Slot "a")
/ dev / block / bootdevice / by-name / tz_a # Partitions of the first bootloader (Slot "a")
/ dev / block / bootdevice / by-name / xbl_a # Partitions of the first bootloader (Slot "a")
/ dev / block / bootdevice / by-name / aboot_b # Partitions of the second bootloader (Slot "b")
/ dev / block / bootdevice / by-name / apdp_b # Second bootloader partitions (Slot "b")
/ dev / block / bootdevice / by-name / bootlocker_b # Partitions of the second bootloader (Slot "b")
/ dev / block / bootdevice / by-name / cmnlib32_b # Partitions of the second bootloader (Slot "b")
/ dev / block / bootdevice / by-name / cmnlib64_b # Sections of the second bootloader (Slot "b")
/ dev / block / bootdevice / by-name / devcfg_b # Sections of the second bootloader (Slot "b")
/ dev / block / bootdevice / by-name / hosd_b # Second bootloader partitions (Slot "b")
/ dev / block / bootdevice / by-name / hyp_b # Partitions of the second bootloader (Slot "b")
/ dev / block / bootdevice / by-name / keymaster_b # Second bootloader partitions (Slot "b")
/ dev / block / bootdevice / by-name / msadp_b # Second bootloader partitions (Slot "b")
/ dev / block / bootdevice / by-name / pmic_b # Second bootloader partitions (Slot "b")
/ dev / block / bootdevice / by-name / rpm_b # Second bootloader partitions (Slot "b")
/ dev / block / bootdevice / by-name / tz_b # Second bootloader partitions (Slot "b")
/ dev / block / bootdevice / by-name / xbl_b # Second bootloader partitions (Slot "b")
/ dev / block / bootdevice / by-name / modem_a # Section of the first modem / radio module (Slot "a")
/ dev / block / bootdevice / by-name / modem_b # Second modem / radio section (slot "b")
/ dev / block / bootdevice / by-name / boot_a # The first kernel partition (Slot "a")
/ dev / block / bootdevice / by-name / boot_b # Section of the second kernel (Slot "b")
/ dev / block / bootdevice / by-name / vendor_a # First proprietary partition (Slot "a")
/ dev / block / bootdevice / by-name / vendor_b # Second proprietary partition (Slot b)
/ dev / block / bootdevice / by-name / system_a # First system partition (Slot "a")
/ dev / block / bootdevice / by-name / system_b # Second system partition (Slot "b")
As can be seen from the excerpt above, there are two, independent among themselves, slots, namely “partition groups”, which contain the main,
upgradeable components firmware.
The two slots presented consist of:Bootloader (loader) - 28 partitions (14 for each slot).
Radio / Modem (radio module) - 2 sections (one per slot).
Boot (core) - 2 sections (one per slot).
Vendor (drivers) - 2 sections (one per slot).
System (system) - 2 sections (one per slot).
The remaining sections, not listed in the table, are presented in one copy as superfluous as they are divided.
note user storage section (userdata)
always alone ! That is why
You can not (Without cleaning storage) simultaneously use two completely different firmware, there is a conflict. The simultaneous use of the same type of firmware (and in some cases this is not possible without a reset).
The principal differences compared with other devices: With overlapping sections, and the structure in general, understood. However, you may have noticed (if viewed full partition table) absence, the usual in any device partition "/ recovery" and "/ cache". Yes, they really do not. But they can also occur in deviations from the norm.
Q: Stop. But if there is no partition for Recovery, and Recovery itself is (He is, right?), Where is he located? A: The recovery system (Recovery) is included in the kernel image (boot). Therefore, the presence, absence and type of installed recovery directly depend on the system kernel. Switching to it (Recovery), as before, is performed by a special flag in the "/ misc" section.
That this is a hitch install TWRP - it somehow need to "stick" to the kernel. Because TWRP first temporarily loaded (installed its nowhere), and then from the TWRP, a special script on the fly unpacks the kernel and sewn into it TWRP. The same scheme "repacking kernel on the fly" is used in the preparation of "systemless" Ruth rights through SuperSU and Magisk.
Q: Well, what happened to the "/ cache" partition? A: In familiar devices, it is necessary only for storing OTA updates and system logs of Recovery, in this case, due to the use of the new scheme of these updates (see below), the section simply became “not needed”. That's from him and got rid of.
Manual slot switching: Naturally, besides the slots themselves, there must be a way to manually interact with them. And he is. To manually switch the current active slot, you need to use the fastboot utility. Commands:
fastboot set_active a # slot activation of "a"
fastboot set_active b # Activation "b" slots
fastboot set_active other # activation slot opposite to the current
You can also switch to another slot in the corresponding TWRP item (Reboot ->Slot A / Slot B).
Results and regulations: 1. Between the slots, both the system and the user can switch.
2. Initially (from the factory) the slots are completely identical with each other. Differences appear after applying any OTA system updates.
3. Slots are isolated between themselves. The state and integrity of one slot does not affect the other.
Except for the use of OTA updates. (see below).
"Seamless" update system: So, the sections and slots are sorted out. But what about the updates, surely they were also affected by the change, in view of the above?
Yes, OTA updates on devices with an A / B structure are completely different from what we can see on other devices.
Results and regulations: 1. All OTA updates are installed in an inactive, opposite slot. I mean - only one slot is updated.
2. All OTA updates are installed in the background with a working system, without rebooting the device.
3. All OTA updates are installed in two steps: "Step 1" - Download the update. "Step 2" - Background application of the update in an inactive, opposite slot.
4. After installing the OTA update, when the device is rebooted, it will automatically be loaded into the updated slot (previously inactive).
Android 8.0+ - broadcast updates: Starting with the version of Android 8.0, it is possible (but not necessary) to partially implement the broadcast of updates with their simultaneous use (direct recording).
This means that updates do not need to be preloaded, but are applied on the fly.
Post has been editedDisplax - 08.06.20, 01:27