When Android Nougat released, it had us talking about all kinds of new features. We got a newly updated user interface for starters along with long-awaited multiwindow capabilities and Vulkan Graphics API support. But one under-the-hood addition flew over the heads of most users. Android Nougat introduced “Seamless Updates” on devices that support A/B partitions. The vast majority of existing Android devices (excluding the new Google Pixel and Google Pixel XL) did not have A/B partitions at the time and thus couldn’t take advantage of seamless updates. The basic premise of this feature is that the device has a second set of the system, boot, vendor, and other important partitions, and when you get an OTA update the update happens in the background while the second set of partitions are patched which lets you reboot into an updated software build seamlessly. If an update fails, you’ll be kicked back to a working build, meaning companies will have fewer headaches to deal with and consumers are better protected.
Supporting seamless updates is not a requirement for any new Android device, unlike Project Treble. As such, the vast majority of new Android devices don’t support the feature. We’ve been keeping a list of all the supported devices so far, and it’s clear that this feature is not widely supported. That’s a shame because A/B partitions bring a lot of benefits for both regular users and power-users alike. However, the feature has a bit of a bad reputation in the enthusiast community because it’s perceived to make Android development and flashing custom modifications more difficult. This is not actually the case, so we wanted to demystify seamless updates and explain how A/B partitions affect custom development on XDA.
Many thanks to XDA Senior Member npjohnson, a contributor to LineageOS and maintainer of the Motorola Moto Z2 Force, who helped us fact check this article.
Partitions on an Android device
A partition is simply a discrete section on the phone’s internal storage where data is kept. What kind of data is kept on each partition depends on the hardware, operating system, and many other factors. The bootloader will have one, the system (Android OS) will have one, the user data will have one… and so on and so forth. When you see people talk about “/system” and “/cache”, they’re referring to the given names for those partitions. The OnePlus 6, for example, has 72 partitions. That sounds like a lot, but the OnePlus 6 is one of the devices that supports seamless updates which means many of these partitions are simply duplicates of each other.
Partial output of the partitions on the OnePlus 6. Some A/B partitions are underlined for demonstration purposes.
There are a lot of partitions on a device that you will never have to worry about as a user. Many of these partitions are never modified when flashing custom ROMs, kernels, recoveries, or modifications like Magisk or Xposed. A lot of these partitions will either be unused for our purposes or are too dangerous to touch unless you know what you’re doing (XLOADER and OEMINFO on Huawei/Honor devices come to mind.) For the vast majority of Android users, the partitions that we mostly deal with are system, boot, recovery, userdata and more recently vendor and vbmeta. Here’s a brief explanation of the purpose of each partition:
- system – holds the Android OS, system libraries, system apps, and other system media like bootanimations, stock wallpapers, ringtones, etc.
- boot – holds the kernel, ramdisk, and on A/B devices also the recovery as well
- recovery – holds the recovery, where TWRP is most commonly flashed on A-only devices (A/B devices don’t have a dedicated recovery partition)
- userdata – holds all of your app, system, and internal storage data
- vendor – holds platform and device-specific HALs, the files necessary for the Android OS to communicate with the underlying hardware
- vbmeta – the partition for Android Verified Boot 2.0 which verifies the integrity of the boot process
Device OEMs can change their partition schemes to use whatever layout they want. For instance, Huawei splits the boot partition into ramdisk_recovery and kernel. There are also a lot of extra partitions that may contain other system apps such as cust, product, and oem, and while these are safe to modify, it’s generally not recommended if you want to make it easier on yourself to return to stock. So where do A/B partitions play a role?
The A/B Partition Scheme
How updates work on devices with seamless updates
The very simple image I made below illustrates how an update is handled on a device with A/B partition support. The partition that is illustrated is the system partition, though other partitions such as boot and vendor may also be updated with any given OTA update from an OEM. This update process happens with not only major Android version updates but also security patch updates.
- We start with two system partitions, system_a and system_b, both on the same version of Android.
- Assuming that system_a is active, the OTA update will patch system_b, the inactive partition, in the background.
- system_a is set to inactive and system_b then becomes active once the user reboots.
- The now-inactive partition, system_a, will be updated when the next OTA update rolls out.
What are the benefits of this update process?
- If an update fails, the device will roll back to the working build on the other slot.
- Your data is kept perfectly intact, even if the update is borked, as there is only one partition (userdata) which houses your data.
- Update streaming: If your data partition is full, then the update can be downloaded and streamed to the inactive slot. It’s a pretty neat feature and means that you don’t have to waste any temporary storage on your updates. That’s why there’s no cache partition on A/B devices as they’re no longer needed.
What impact does the A/B partitioning scheme have on the storage of a device?
Does the fact that seamless updates result in a bunch of duplicated partitions mean you’re losing a bunch of storage space? Not at all. Google says that devices with seamless update support should only be down about a few hundred Megabytes thanks to removing the /cache and /recovery partitions. Removing both balances the cost of adding a second set of partitions. According to Google, the Pixel’s A/B system image is half the size of the A-only system image. Most of the additional storage usage actually comes from the addition of a second vendor partition. That makes sense as the vendor partition houses all of the proprietary binaries used by OEMs (part of Project Treble), so it’s expected to take up quite a bit of space. While Google doesn’t recommend having A/B partitioning on devices with 4GB of storage (as it’s nearly 10% of total available storage), they do recommend it on devices with 8GB and higher.
Here’s a breakdown of the storage space used on a Google Pixel with and without A/B partitions.
| Partition Sizes | A/B | A-only |
|---|---|---|
| Bootloader | 50MB*2 | 50MB |
| Boot | 32MB*2 | 32MB |
| Recovery | 0 | 32MB |
| Cache | 0 | 100MB |
| Radio | 70MB*2 | 70MB |
| Vendor | 300MB*2 | 300MB |
| System | 2048MB*2 | 4096MB |
| Total | 5000MB | 4680MB |
What happened to the recovery partition?
The underlying Linux kernel on Android devices is what lets Android recognize and use the hardware properly on a smartphone. On A-only Android devices, you generally have two versions of the kernel: One is packed inside of the recovery partition while the other is in the boot partition. On A/B devices supporting seamless updates, the recovery is now inside of the boot image along with the kernel. The recovery’s main function was to install updates, but since that’s handled by the system itself (update_engine) while Android is booted up the dedicated recovery partition is no longer needed.
To install a custom recovery on A/B devices, we thus need to modify the boot partition and replace the stock recovery with our own. This is why to install TWRP you need to use a fastboot command to boot a custom boot image first and then flash the TWRP installation script, as fastboot can’t patch partitions—only flash over them entirely. You could technically pre-patch your existing boot image with TWRP and then flash it via fastboot, but that’s more trouble than it’s worth. The TWRP installer script patches both the boot_a and boot_b partitions to install TWRP.
Fun fact: The Android update_engine which handles seamless updates is basically ripped straight from Chrome OS. Only recently were strings containing “Chrome OS” removed from update_engine’s log to avoid confusion for anyone who happens to check logcat.
Does my Android smartphone support A/B partitions for seamless updates?
While we keep a list of all devices that support it, you can also easily check yourself.
How do seamless updates affect custom development?
User Perception of A/B Partitions
Deemed a hindrance to custom software development by many users, seamless updates are actually a boon to developers. The reason that A/B devices are perceived to have poor development support comes down to the price of the first A/B devices. After all, the Google Pixel devices were some of the first to support seamless updates and compared to the Nexus smartphones of yesteryear they were relatively expensive. Furthermore, thanks to the myriad of improvements Google has been making to the Android OS which has made custom ROMs and modifications less popular on Google devices, the Google Pixel smartphones didn’t take off on our forums nearly as well as the Nexus smartphones. A combination of external factors led to a decrease in custom development on the Google Pixel smartphones, though most users chose to blame A/B partition support instead. Compare the availability of custom development on devices like the Google Pixel with devices like the Xiaomi Mi A1 on our forums.
In addition, a lack of understanding of how A/B partitions changed the way users need to install custom ROMs, kernels, recoveries, and modifications led to A/B partition support being unpopular. With the recovery now living inside of the boot image, flashing modifications in the wrong order such as Magisk or Xposed can cause conflicts and can lead to a bootloop. What order you flash these mods in can be important, though in the case of custom ROMs you shouldn’t need to worry about what slot you’re flashing to. Contrary to common belief, the installation script for most custom ROMs does not flash to both slots. You mostly don’t need to worry about that as you shouldn’t need to be swapping slots manually.
How Developers View A/B Partitions
When building a ROM, developers can make use of both partitions to test separate builds. If one doesn’t work, they can just revert back to the working partition and rebuild their ROM. Developers can also test for regressions by simply installing an update, switching the active partition, and comparing the two without having to wipe data. Here’s how the LineageOS team views A/B partition support:
“Many around the Android community have bashed A/B as being ‘hard to support’ and ‘not developer friendly’, when in fact, properly implemented it is easier to support and just as developer friendly.” – jrizzoli, LineageOS Changelog 19
The initial difficulty with A/B support for developers came from modifying their existing tools to support these devices. The developer of Magisk, topjohnwu, added official support for the Google Pixel a year after it was released—not because it was difficult, but rather because it took him a year to actually obtain the device to work on. TWRP support came pretty quickly on A/B devices after the lead developer, Dees_Troy, took a crack at it. LineageOS 15.1 now supports A/B devices after volunteers found time to fix their addon.d script.
How to update an A/B device that has a custom recovery, kernel, or other mods
Custom ROMs
Flashing updates on a device with a custom ROM means that you’ll have to be wary of which slot you’re flashing too, right? Not quite. TWRP will actually handle a lot of that for you, and it defaults to the inactive slot for flashing a custom ROM. If your active slot is A and you flash a custom ROM, you’re actually flashing to slot B. When you reboot, the active slot is now B. Developers can modify the installation script and flash to both slots to make it easier on the end user, although most custom ROM installation scripts currently only flash to a single slot. Lastly, custom ROMs can implement an A/B updater in their ROM so that users don’t even need to mess with manually flashing updates—the latest LineageOS 15.1 includes a Lineage Updater tool, and XDA Senior Member USA-RedDragon made a generic A/B updater that other developers can use.
Stock ROMs
But isn’t it problematic if your device is running the stock ROM with various modifications and you want to install an update without losing all of these mods? It can be if you don’t know the right steps to install an update. On the OnePlus 6, for example, you can’t flash an incremental OTA on your modified device because the incremental OTA will attempt to patch your modified boot image. Thus, you’ll likely end up with a bootloop, and that’s why you have to flash the full ROM update to completely overwrite your modified boot image. Here are the general steps you need to take to install an OxygenOS update on your OnePlus 6 while still retaining TWRP, Magisk, and optionally a custom kernel.
- Downloaded the latest full ROM zip
- Flash the full ROM zip in recovery
- (Optional) Flash custom kernel
- Flash TWRP installer
- Reboot straight back to recovery
- Flash Magisk
On the Google Pixel devices, you can flash the factory image without wiping data, then boot TWRP, install TWRP via the install script, then install Magisk.
Extracting an update to flash individual partition images
Update files for many A/B devices are a little different compared to A-only devices. They’re no longer just a zip file containing lots of images (excluding Google and Razer’s factory images), instead, they’re in the form of a payload.bin file. You can extract this file and flash each part manually, but it requires a special tool to do so. If you’re interested in learning how to do so on the OnePlus 6, Xiaomi Mi A1, and many other A/B devices, read on.
Setting up to extract payload.bin
- Make you sure you have Python 3.6 installed.
- Download payload_dumper.py and update_metadata_pb2.py here.
- Extract your OTA zip and place payload.bin in the same folder as these files.
- Open PowerShell, Command Prompt, or Terminal depending on your OS.
- Enter the following command:
python -m pip install protobuf - When that’s finished, enter this command:
python payload_dumper.py payload.bin - This will start to extract the images within the payload.bin file to the current folder you are in.
You can flash each of these images separately now via fastboot if you wish. The next section shows you how to do that.
Using fastboot to flash images on a device that supports seamless updates
There are a number of commands that are exclusive to A/B partition system devices. You can change your active slot and flash to specific slots. If you have a Project Treble-compatible device and want to learn how to flash Generic System Images, you should be familiar with these commands. Take a look at the table below.
| Fastboot commands | Command |
|---|---|
| Get current active slot | fastboot getvar all | grep “current-slot”
If you’re on a Windows PC, the “grep” command won’t work. |
| Set other slot as active | fastboot set_active other |
| Set specified slot as active | fastboot set_active $
OR fastboot –set-active=_$slot where $ is either a or b |
| Flash image to the specified partition in the current slot | fastboot flash partition partition.img |
| Flash image to the specified partition in the specified slot | fastboot flash partition_a partition.img
fastboot flash partition_b partition.img |
(Note: On A/B devices, you can either specify a partition in a particular slot to flash to or you can leave out the slot suffix and it’ll flash to the current active slot. For example, you can replace “partition” in the flash command with “system”, “system_a”, or “system_b.”)
On Windows PCs, you can’t use grep, so just remove that part and look for “current-slot”.
A Word on Project Treble and Seamless Updates
A common misconception is that having Project Treble support and A/B partition support are related to one another, but that’s not actually the case. Having one does not imply the other. The Motorola Moto Z2 Force uses an A/B partitioning scheme but doesn’t support Treble. On the other hand, the Honor 9 Lite supports Project Treble, yet is an A-only device.
The Honor 9 Lite supports Project Treble but does not support Seamless Updates
Frequently Asked Questions/Summary
- What are the benefits of A/B partitioning?
- A/B partitioning allows you to update your Android smartphone while using it, simply rebooting when you’re ready to boot into the new version. It also acts as protection against bricks—if the update goes wrong you’ll go back to the working install.
- Does having A/B partitioning hinder development?
- While it did take developers a bit of time to adapt, the answer is pretty much no. In fact, it can help developers as they can dual boot their custom ROM with the old version and a new testing version to check for regressions.
- How do A/B partitions affect mods such as custom kernels, Magisk, or Xposed?
- You have to be careful when installing them, but there are currently no issues. Magisk officially supports devices with seamless updates, and so long as you flash things in the right order you should have no problems. Make sure to flash the custom kernel before flashing your other mods, and you should be good to go.
- Can I flash two different ROMs on each partition and dual boot?
- In theory, yes. Problems arise because of the shared data partition though, so it’s not recommended.
- Does having an A/B partition scheme mean that I have reduced storage?
- Nope! Google says that devices which support seamless updates only sacrifice a few hundred Megabytes of storage to support it. The benefits outweigh that cost.
- My device supports A/B partitions, does that mean I can make use of a Project Treble Generic System Image?
- Not necessarily. Project Treble and A/B support are unrelated. The Motorola Moto Z2 Force doesn’t support Project Treble, yet it supports the A/B partition scheme.
- My device supports Project Treble, does that mean I have an A/B partition scheme?
- This is not always the case. The Honor 9 Lite is a prime example as it supports Project Treble yet does not have an A/B partition scheme.
- Why do I need to boot TWRP with fastboot first and then flash it?
- This is because of how fastboot works and the fact that the recovery partition no longer exists. Recovery is placed inside of the boot partition, so we have to modify both boot_a and boot_b. You can’t patch a partition in fastboot, only flash over it. You could, in theory, make a prepatched boot image and then flash that instead.
- Are there any dangers with A/B partitions? How does rollback protection affect things?
- Google has tried their hardest to make this not an issue, but in the case of the Motorola Moto Z2 Force, there were known cases of a device reactivating the older slot after upgrading to Android Oreo. This meant that rollback protection kicked in, and device owners could only rescue their smartphone with EDL recovery. Google says that rollback protection only kicks in after first boot though, so the slot needs to be fully functioning after an update before you can no longer downgrade.
from xda-developers https://ift.tt/2JF6wa9
via IFTTT
Aucun commentaire:
Enregistrer un commentaire