With Android 7.0 Nougat, Google introduced a partition scheme designed to speed up software updates. In Nougat, Google added support for duplicating certain partitions so that inactive partitions can get updated in the background and then swapped to active with a quick reboot. This “A/B partition” setup allows for “seamless updates” to take place on supported Android devices, much like Google’s Chrome OS. However, Google has never mandated the use of A/B partitions, so many devices out there that don’t support seamless updates. That could change with Android 11, however, as Google is making it mandatory for newly launched devices to support virtual A/B partitions.
For a bit of background, A/B partitions refer to the set of read-only partitions that are duplicated. Duplicated partitions typically include the system, vendor, boot, and product partitions. When the phone is downloading an update, the updater patches the inactive set of partitions (one “slot”) in the background. Once the update has finished being applied to the inactive slot, the user is prompted to reboot their device. When the user reboots their device, the inactive slot swaps place with the active slot, finishing the update process. The previously active slot is left untouched if there is an issue with booting the newly updated slot. When the next update rolls around, this process is repeated. If you’re interested in a more technical explanation, refer to Google’s developer documentation on A/B partitions.
In contrast, devices without A/B partitions, such as the Samsung Galaxy S20, OPPO Find X2, and many others, apply updates through a dedicated updater in a recovery process. This kicks the user out of Android and renders them unable to use their device for several minutes, potentially missing important notifications, calls, or texts. Google believes that simplifying the update process leads to more people actually taking an update once it rolls out; in fact, in May of 2017, Google found that a higher percentage of Pixel users than Nexus users were running the latest security update. Of course, the user can schedule updates to occur when they aren’t actively using their device, but many users simply don’t update their device even when prompted. In addition, by not having A/B partitions, the user misses out on one of its inherent benefits: protecting them from botched system updates.
For example, when Xiaomi first rolled out the Android 10 update for the Mi A2 Lite, many users discovered that their devices were not booting. Fortunately for them, the Mi A2 Lite has A/B partitions for seamless updates, so users on our forums found that they could use a fastboot command to set the bootloader to boot the untouched, previously active set of partitions. Thus, not only do A/B partitions provide users a much quicker update process, but they also act as a failsafe for botched updates. OEMs that haven’t implemented A/B partitions can still engineer their own way to protect against OTA failures, though why go through that trouble when this protection is part of the design of A/B partitions? For your reference, here’s a partial (and admittedly outdated) list of devices that support A/B partitions for seamless updates, and here’s a tutorial on how to check if your own device supports the feature.
It may seem puzzling why certain OEMs like Samsung charge $1,400 for a smartphone but won’t offer such a nifty feature. The reason usually boils down to storage: OEMs don’t want to sacrifice a few gigabytes of storage space to support seamless updates. Phones like the Samsung Galaxy S20 have a ton of pre-installed software, so duplicating partitions like /system and /product will lead to a lot of huge files and applications being duplicated. Google managed to implement A/B partitions without sacrificing too heavily on storage space thanks to a clever trick to work around the issue of duplicating massive .odex files. Another reason OEMs may have chosen not to implement A/B partitions is cost: Keeping up with Google’s constant changes to Android’s partition schemes requires a lot of effort, as XDA Recognized Developer topjohnwu will tell you. Unless OEMs are forced to, many won’t bother changing what already works for them.
Finally, though, Google seems to be laying down the law in Android 11. By forcing the adoption of virtual A/B partitions on newly launched devices, they’ve all but assured that OEMs will have to support seamless updates for their late 2020 and 2021 devices. As spotted by XDA Recognized Developer luca020400, Yifan Hong, a software engineer at Google on the Project Treble team, submitted a commit to the AOSP Gerrit titled “Require Virtual A/B on R launches.” The commit updates the Vendor Test Suite, or VTS, which is an automated test that all devices must pass to be considered compatible with Project Treble. The new test checks if the system property “ro.virtual_ab.enabled” is set to true and if “ro.virtual_ab.retrofit” is set to false on devices with a shipping API level of 30 or higher. In other words, this test checks if a device launching with Android 11 or higher supports virtual A/B partitions. “Virtual” A/B partitions were introduced with Android 10 alongside “dynamic partitions,” which are dynamically resizable partitions. They’re the same concept as regular A/B partitions except they can be freely resized.
If a device that launches with Android 11 does not support virtual A/B partitions, then it will fail VTS. If the device fails VTS, then it cannot ship with Google Mobile Services. In other words, Google has effectively made it required for OEMs to support virtual A/B partitions, and by extension, seamless updates. This commit has not yet been merged, though, but we’ll keep an eye out on it for further developments.
The post Google is requiring Virtual A/B on new Android 11 devices, paving the way for mandatory Seamless Updates appeared first on xda-developers.
from xda-developers https://ift.tt/2RlfG2q
via
IFTTT
