Android OS and security level fragmentation is a huge problem that Google is investing a lot of engineering effort to combat. In the past two years, Google announced two major initiatives designed to speed up the rollout of updates: Project Treble and Project Mainline. The latter was only announced this May during Google I/O 2019, and it’s only supported on devices launching with Android 10. The former, however, has been around since Google I/O 2017, so we’ve seen how much of an impact it’s had on Android updates with Android 9 Pie and Android 10.
Besides reducing fragmentation, Google also wants Project Treble to be useful for app developers. That’s why they unveiled Dynamic System Updates (DSU) in Android 10 to let developers try a barebones version of a new OS update without unlocking the bootloader or wiping data. Seeing the potential for DSU, Google isn’t stopping there—they’re expanding its utility by making it possible for OTA updates from OEMs to be installed the same way GSIs are installed.
That’s a lot of jargon, but imagine this happening in the future: an OEM releases a phone with Android 10 and starts a beta program for Android 11. You’re interested in trying out this beta to see the new features, but you don’t want to risk the stability of your current daily driver. Instead of flashing the beta update and then hoping it’s perfectly stable, why not temporarily install it through the DSU flow? If you don’t like it, just reboot and your setup will return to normal. If you do like it, you can “commit” to the update.
I don’t know about you, but this would be a welcome change to Android that would make beta testing more enjoyable. You would no longer have to commit to a beta update just to see what it’s like for yourself. I’m sure many of you are itching to see an Android 10 beta for your device, but you may not be comfortable installing it right away. With the changes made to DSU, that would no longer be a concern.
Dynamic System Updates in Android 10+ – What’s Changing
Luca Stefani, a friend of the XDA Portal and a Recognized Developer, informed us about a new commit merged in AOSP titled “mount multiple DSU partitions when present.” The commit makes changes to the file system table (fstab) and the init process to make it so that DSU partitions other than system, for now including product and vendor, can be mounted during the boot process.
New code in fstab to add support for loading product_gsi and vendor_gsi images in place of the existing product and vendor partitions respectively. A comment notes that DSUs can be signed by the OEM, but otherwise support Google’s official GSIs.
Currently, DSU is designed to only let you boot a Generic System Image (GSI), a barebones system image compiled from AOSP, so you can test the new APIs and other changes in the latest Android update. However, with this change, DSU will also accept product and vendor images. The former contains device-specific apps, libraries, and other files, while the latter contains device-specific binaries. Project Treble made it so you can boot a device using a system image with no device-specific files, so to now allow the loading of product and vendor doesn’t seem to make much sense.
However, a Google engineer explicitly says that this change is to “allow OEMs [to] install OTA packages on /data, then using [the] ‘DSU’ flow to mount product.img, system.img, [and] vendor.img from /data.” This means that, rather than overwriting the current installation with the new OTA package, the OTA can be temporarily loaded via DSU. After trialing the OTA update, “the user can decide if they want to ‘commit’ those images to /super or not.” This last part about “committing” the changes is still in-the-works, as one Google engineer notes that “currently we don’t have a plan to make DSU partitions permanent under the DSU context.” He then states how this could be implemented, but that this implementation is “beyond the scope” of this current patch.
There are some terms and concepts we need to explain here because Google likes to change up the partition scheme in every Android version. For starters, I recommend reading over my previous article on Dynamic System Updates for a broad overview of how it works, but in summary, it takes advantage of the concept of a “dynamic partition,” one real partition of storage (called the “super” partition) that gets divided into resizable logical partitions (including system, vendor, product, and system_ext), to temporarily install a GSI. When installing a GSI, DSU creates space for the new system and userdata images by resizing the existing userdata partition. The building blocks for DSU support (dynamic partitions, a ramdisk, and checkpoints for data backups) are launch requirements for Android 10, so any device launching with the new Android OS version should support DSU. DSU isn’t the dual boot solution for custom ROMs that some of you are looking for, because only images that match the Android Verified Boot (AVB) keys can be installed. However, with this new change, it could prove much more useful in the future.
On top of dynamic partitions, Google also introduced the concept of “virtual A/B” in Android 10. This is basically an implementation of the dual A/B partitions from before, but with logical partitions instead. A/B partitions involve copies of important partitions to allow for seamless and safe updates. Using “virtual A/B” is how one Google engineer envisions “committing” the DSU partitions onto the partitions from the current installation; like with the current A/B OTA update process, perhaps the changes from the new images are made to the inactive partition.
These changes are still in development and could take some time before they get used by Google or OEMs. We probably won’t see any implementations of this until, at the earliest, Android 11 R gets released next year. Even so, there’s no guarantee that OEMs even adopt this feature for its OTA updates. Given how useful this seems to be for beta testing, though, I imagine that Google is already working with interested OEMs to enable this feature for future updates. I’m personally excited by the prospect of trying-before-buying new Android updates, but what about you?
The post Google is expanding Android 10’s DSU feature to let you try OTAs from OEMs without committing to the update appeared first on xda-developers.
0 comments:
Post a Comment