Android 11’s DSU Loader makes it easier than ever for developers to test apps on stock Android

A good app ecosystem is one of the most important pillars of the success of an operating system. Both Google and Apple recognize the value of having good applications on their platforms, and so both companies try to balance the needs of their users and their app developers. Users keep pushing for changes in the OSes, and while most people generally appreciate new features, these changes are not always fun for app developers as they can alter a lot of the core functionality and behavior. For developers who are constantly working to keep their apps relevant, dealing with these changes adds to their growing worklist. Even if these changes do not directly affect their applications, developers still need to make sure that their apps will work on the new OS update. Google has done many changes over the years to make this process easier for Android app developers, and now, a new feature in Android 11, called DSU Loader, will make it even easier for app developers to test their apps on new Android versions.

It starts with Project Treble

Project Treble, introduced in Android 8.0, is a major re-architecting of the Android OS. The goal of Project Treble was to split the Android OS into two big chunks: the framework and the vendor implementation (“vendor” here refers to the maker of any proprietary hardware component found within a device, usually referring to the silicon). The Android OS framework is the operating system itself, including all the system apps, the UI and its components, and the APIs that are shared across Android devices. The vendor implementation contains the vendor HALs (Hardware Abstraction Layers) and the Linux kernel and Linux kernel modules.

Since OEMs ship smartphones with many different hardware components from many different vendors, they have to do a lot of work just to get the hardware up and running on a single Android OS release. Then with each new Android OS update, they have to do even more work to make sure that their hardware works with the new version. But with Project Treble standardizing the ABI (Application Binary Interface) between the Android OS framework and HALs for a particular Android version, Android OEMs can start testing updates to their devices without needing to wait for silicon manufacturers and other component makers to update their side of the code. This change noticeably sped up the way Android updates are handled.

That’s the gist of what Project Treble has done for Android updates, but what’s more important for app developers here is that Treble has enabled the use of Generic System Images (GSIs) for compatibility testing.

The Emergence of GSIs

In order for OEMs to test if they’ve properly implemented Project Treble, Google mandates that the OEM should be able to boot a clean build of Android from AOSP on the device. This clean build of Android is called the Generic System Image, or GSI. If the GSI boots and most basic hardware functions properly, then the OEM knows that their device meets Project Treble’s requirements. The initial purpose of the GSIs was thus for testing Treble compatibility, but as we’ve seen with the development community here at XDA-Developers, they can be used for other purposes. We saw how GSIs could essentially allow devices with heavy Android UXs to enjoy the latest version of Android with working features within days of a new release. But Google envisions another purpose behind the GSI: giving app developers the ability to test their apps on a new Android version on a physical device that they already own.

With Android 10, Google released its own GSI builds for developers. Google cemented the idea that app developers should use a GSI to boot a clean build of Android on their own hardware, making it easier to test their application’s behavior against stock Android. This method thus added on to the existing options of testing app compatibility on stock Android without OEM behavior changes, the others being using a Pixel smartphone, using the official Android Emulator within Android Studio, or deploying app builds to a device instance on the cloud.

Despite all the convenience that GSIs brought along, their installation was still a cumbersome process. App developers may not be comfortable with manually flashing a system image on an Android device as this is something typically only hobbyists or Android OS developers will be familiar with. Installing a GSI required flashing a system image over fastboot, which requires disabling Android Verified Boot and unlocking the bootloader. Bootloader unlocking, in turn, requires a complete user data wipe. And as we all know, there isn’t exactly a single process or guide for unlocking the bootloader of every Android device out there, so there is no consistency to be found. For instance, Samsung devices do not have fastboot while Xiaomi devices make you jump through a few hoops to unlock the bootloader. It’s a convenient mess that has the potential of being untangled into something simpler.

This is where Dynamic System Updates come in.

Dynamic System Updates simply installing GSIs

Google realized that the current method of installing GSIs was not a perfect solution, so they started working on a better solution. In Android 10, Google began testing Dynamic System Updates, or DSU. DSU is a new way to temporarily install a GSI without needing to use fastboot commands to flash a system image, overwriting the original installation. With DSU, you can boot into a GSI, test your app, and then conveniently reboot back into your original installation which has remained untouched.

The reason that DSU can install a GSI without touching the original installation is that it creates new system and data partition images that are temporarily stored in /data/gsi. These images are then mounted during boot rather than the original system and data partitions. Because the phone needs additional storage space for these new, temporary images, your phone must have “logical partitions” on board, which are dynamically resizable partitions. Logical partitions are a new userspace partitioning system for Android, which is mandatory for devices launching with Android 10. If your device launched with Android 10, then it should support installing GSIs through DSU.

In Android 10, all you need to do to install a GSI via DSU is to change a system property and then launch the DynamicSystemUpdatesInstallationService by sending an intent with the path to the GSI as an intent extra.

Got Android 11 temporarily installed on the Pixel 3 XL without wiping the Android 10 install thanks to Dynamic System Updates (DSU). Unfortunately, it requires an unlocked bootloader to boot. pic.twitter.com/6TfUFD3ut9

— Mishaal Rahman (@MishaalRahman) February 22, 2020

While this process may seem unfamiliar, it is by far easier and less intrusive when compared to using fastboot commands and dealing with the hassle of everything, including the original installation, being wiped. You do require some knowledge of ADB and intents to make use of DSU, but this shouldn’t be a problem for most app developers out there. Still, there’s no reason the process couldn’t be made even simpler. Plus, there’s the fact that installing a GSI through DSU still requires you to unlock the bootloader, wiping all user data in the process. To that end, Google has implemented changes to improve both aspects of GSI installation. In Android 11, they’ve eliminated the need to use the command line at all to install a GSI. Separately, they’ve also made it possible to install a GSI without unlocking the bootloader.

DSU Loader in Android 11

DSU Loader is a new tool present in Android 11’s Developer Options that allows you to download and install the latest GSI from Google without needing to input any fastboot or ADB commands. Simply tap the DSU Loader option within Settings and a dialog box will appear with a list of supported GSIs straight from Google. These supported GSIs will be based on your current OS and architecture, so you can only install GSIs that are newer than your OS version and that match your SoC architecture. Simply choose the GSI that you want to install and it will be downloaded from Google’s servers and installed in the background automatically.

DSU Loader on Android 11

With DSU Loader, developers never have to touch the command line to install a GSI. At least, that’s the dream, because there’s still one issue left to solve.

The way forward

Currently, to install a GSI via DSU Loader, you need an unlocked bootloader. While this may defeat the purpose of the whole ordeal, it is not supposed to be this way, and we’re told that it will get fixed. Google has planned for users to be able to boot Google-signed GSIs through DSU without needing to unlock the bootloader. In fact, Google mandates that all Android 10 launch devices include the Android Verified Boot public keys of Google-signed Android 10, Android 11, and Android 12 GSIs. Including the AVB public keys in the device’s ramdisk will ensure that AVB will not reject the GSI that you are trying to boot. This is why the current method involves unlocking the bootloader – by flashing an empty vbmeta image to the vbmeta partition, you disable AVB so that it will not reject the GSI you are about to flash. Disabling AVB is a major security risk, though, as it means that any modified system/boot/product/vendor partition can be loaded onto the device, which is why Google wants to do away with that requirement.

Android 10 GSI Launch Requirements

So when can you expect to boot a GSI through DSU without having to unlock the bootloader or use any command-line tools? Hopefully soon, as Google mentioned to us that they had a few kinks to iron out with the initial Android 11 Developer Previews before they can get this all working properly. Moving forward, one can expect to install future Developer Preview GSIs via DSU without needing to unlock the bootloader. Perhaps when Android 12 Developer Previews are made available, you’ll even be able to boot it entirely by using DSU Loader in Android 11’s Developer Options. For app developers, this means there will be yet another way for you to test your applications on physical hardware running a new Android version.

The post Android 11’s DSU Loader makes it easier than ever for developers to test apps on stock Android appeared first on xda-developers.

from xda-developers https://ift.tt/2xu59La
via IFTTT