Thanks to Project Treble, smartphone device makers have delivered Android Pie software updates faster than they were able to do so for the Android Oreo update, at least for flagship smartphones. Google doesn’t want to see only OEMs reap the benefits of Project Treble, though. The company has previously expressed interest in releasing a Generic System Image (GSI) of Android Q for developers so they don’t have to rely on emulators, use a cloud service, or wait for an update on their own device to test an app against the latest API level. In theory, releasing a GSI should allow any developer with a Project Treble-compatible device (originally Android 8.0 Oreo and above, but now considered only devices launching with Android 9 Pie) to test the latest Android version. All the developer has to do is flash a system image on top of their existing software installation—no need for a custom recovery, boot, or vendor image.
However, there are several problems with the current GSI installation process. First, you need an unlocked bootloader, which isn’t possible on Huawei or Honor devices (without paying a fee), HMD Global’s Nokia devices (excluding the Nokia 8), or U.S. carrier-branded devices. Next, the process will be difficult for anyone who isn’t familiar with flashing images via fastboot. Lastly, flashing a GSI now will need you to wipe the internal storage completely, which means you’ll probably want a spare device to test on. Right now, flashing a GSI is only something that OEMs use to test Project Treble-compatibility on their devices, and beyond that, it’s only appealing to die-hard custom ROM enthusiasts. Google’s new “Dynamic Android” project may look to change that.
Dynamic Android—Easily Test AOSP GSIs on any Android Q Device
For the past few months, Google has worked on a way to securely boot a GSI without having to unlock the bootloader. In short, Google is developing an app that has special permissions that allow it to download a GSI, reserve storage space for it, and mark the GSI as bootable. There are several components to this project, so let’s discuss them one-by-one.
Dynamic Android and Android On Tap
Two new services are being added to Android Q: the Dynamic Android and Android On Tap services. While Dynamic Android handles the installation of a GSI, Android On Tap informs system apps with callbacks and broadcast intents. For instance, Android On Tap alerts the KeyguardManager to ask the user to confirm an installation request if the device is protected by a PIN, password, or pattern. AOT also alerts the user when they’re booted into a GSI.
According to the description for “DynamicAndroidManager,” the service “offers a mechanism to use a new Android image temporarily.” After installation, the device can reboot into the newly installed image with a newly created /data. Rebooting while in the GSI returns the user to the original system image, but the newly installed image and its data are merely disabled and not deleted. If the user chooses to do so, the GSI and its data can be fully removed, however.
Sources: [1], [2], [3], [4]
GSID
The GSI daemon allocates space in the /data partition to store the GSI image and its data and to make the image bootable. The metadata of the GSI is stored in /metadata, while the GSI itself and its data are stored in /data/gsi. By default, GSID allocates 8GB of userdata for the newly installed GSI. In general, GSID looks for at least 40% free space before beginning an installation. Lastly, the daemon prevents the user from installing a GSI within a GSI, for obvious reasons.
Sources: [1], [2], [3], [4]
Security
Android Verified Boot (AVB) is enabled for the newly installed EXT4 system image (system_gsi mounted to /system). Google has also implemented SELinux policies for the new services. Lastly, installation of a GSI requires an app to have the new MANAGE_DYNAMIC_ANDROID permission. This is a signature-level permission which means the app must be signed by the OEM.
Sources: [1], [2]
ADB and Fastboot Commands
GSIs will also be installable via new ADB commands. The new ADB gsi_tool shell command will allow users to disable, re-enable, install and preserve userdata, install and create userdata, install and wipe userdata, or check the status of the installation.
gsi_tool - command-line tool for installing GSI images.
Usage:
gsi_tool <disable|install|wipe|status> [options]
disable Disable the currently installed GSI.
enable Enable a previously disabled GSI.
install Install a new GSI. Specify the image size with
--gsi-size and the desired userdata size with
--userdata-size (the latter defaults to 8GiB)
--wipe (remove old gsi userdata first)
wipe Completely remove a GSI and its associated data
status Show status
Two new fastboot commands will be added to manage the GSI, though fastboot installation is unsupported since fastboot can’t mount userdata.
fastboot gsi wipe
fastboot gsi disable
Sources: [1], [2]
Who will this benefit?
I want to say that app developers will be able to take advantage of Dynamic Android and Android On Tap, but I’m not entirely certain. Although Google has expressed interest in just that, there’s no guarantee that this feature will be available in every Android Q release from non-Google OEMs. To take advantage of this on the device, the software needs a GSI picker app that’s signed by the same certificate as the ROM. I’m also not certain that installing GSIs from ADB will be possible without ADB root because of SELinux policies. If this isn’t intended for app developers to test their apps on a clean build of Android, then it’ll likely only benefit engineers from OEMs looking to test the Compatibility Test Suite (CTS) and Vendor Test Suite (VTS) on their devices.
Special thanks to XDA Recognized developer luca020400 for his assistance in this article.
