1 of 34

Dual booting for testing and curiosity with Dynamic System Updates

Droidcon London 2025

Niall Scott

Bluesky: niallscott.bsky.social

2 of 34

Outcomes

I will cover…

What Generic System Images (GSIs) are, as prerequisite knowledge for…
Dynamic System Updates (DSUs)
With a walkthrough on how to apply DSUs
And examples on how they could be useful in your development workflow

3 of 34

Who has heard of Dynamic System Updates (DSUs)?

4 of 34

5 of 34

6 of 34

TIL = “Today I learned” (https://dictionary.cambridge.org/dictionary/english/til)

7 of 34

So, what are Dynamic System Updates?

We’ll get there!

Firstly, we need to talk about Generic System Images (GSIs)...

8 of 34

So, what are Generic System Images (GSI)s?

9 of 34

https://developer.android.com/topic/generic-system-image (image sourced from same page)

“A Generic System Image (GSI) is a pure Android implementation with unmodified Android Open Source Project (AOSP) code, runnable on a variety of Android devices.”

10 of 34

Why are GSIs useful?

Allows you to test your code with a pure-Android image on a real device
Allows you to test hardware features which the emulator cannot replicate
If the device supports it, you can switch Android versions with ease
Combined with Dynamic System Updates, it’s even easier to apply GSIs and switch versions

11 of 34

GSI pre-requisites

Bootloader is unlocked - so probably not suitable for your daily driver
Device is Project Treble compliant

`adb shell getprop ro.treble.enabled` returns `true`

The device launched with Android 9 (API level 28) or higher
The GSI image CPU architecture must match the device CPU architecture

`adb shell getprop ro.product.cpu.abi`; for example: arm64-v8a

Flashing to a device which does not meet the requirements may result in the device becoming non-bootable (soft or hard bricked)

That the bootloader is in an unlocked state. The device will now likely fail Google Play Integrity verification, meaning some apps will refuse to function, e.g. banking apps. So this is not suitable for your daily driver
Project Treble was a project to uncouple components within Android. GSI relies on this uncoupling to operate. Use this ADB command to determine if the device is compliant
The device must have launched with Android 9 or higher. There is a small amount of support for devices which launched prior to Android 9, but this isn’t guaranteed at all
The GSI image CPU architecture must match the CPU architecture of the device it is being flashed to. If it does not match, the process will fail. Use the ADB command on the screen to determine the device CPU architecture
Draw attention to the fact that failure to meet the prerequisites may cause bricking

12 of 34

Device recommendations

Google Pixel 3 and above has the best support
Look at Pixel ‘a’ series phones for cost-effectiveness (e.g. Pixel 7a)
Other OEMs do have support, but refer back to pre-requisites and check online before trying on a device

13 of 34

How to obtain a GSI

Official releases: https://developer.android.com/topic/generic-system-image/releases

Available with and without Google Mobile Services (GMS)

https://ci.android.com -> Search for “gsi” in the search box and select your desired version from the results

Android 15 and 16 don’t seem to be present - unsure why

Build your own - see https://source.android.com/docs/core/tests/vts/gsi#building-gsis

14 of 34

Flashing a GSI (the non-DSU way)

Beyond the scope of this talk, but…
The flashing instructions differ between OEMs and device models
For Google Pixel devices, see https://source.android.com/docs/core/tests/vts/gsi#flashing-gsis
https://flash.android.com may also be of interest

This method will most likely erase any data on the user partition. Also, there is the possibility of soft or hard bricking the device if you are not careful

15 of 34

And now, for DSUs…

16 of 34

What is a Dynamic System Update (DSU)?

Creates a new dynamic partition on the device
Installs a GSI (or another Android system image) onto the new dynamic partition
Reboots the device in to the new system image as a guest operating system on the device
You can switch between the primary install and the DSU managed install without risking corruption to the data on the primary install*

*It’s best to backup data first, or better, do this on a specifically assigned test device!

Dynamic partitions are a userspace partition system on Android. The system can reallocate the size of partitions depending on its needs. As long as your device has enough free space, DSU can make space for your guest image installation
The guest image is installed on to the new dynamic partition
Once ready, the device can be rebooted. If the image is bootable you should see the guest installation in a few moments. If it failed, it *should* boot you back in to your primary install, but be careful
You can switch between your primary and guest installations with relative ease. You can even make the guest installation the preferred boot image so the device attempts to boot in to it first. We’ll cover that shortly
Things can always go wrong - backup data first or even better, do this on a specifically assigned test device

17 of 34

DSU prerequisites

DSUs were introduced in Android 10 (API level 29)
Mostly the same prerequisites as GSIs (device must be Project Treble compliant and image and device CPU arch must match)
If the guest image passes Android Verified Boot (AVB) then you may not have to unlock the bootloader
The guest system image must have a newer security patch timestamp than the host OS system image

18 of 34

DSU installation methods

DSU Loader

Pro: easier installation

Con: less choice of images

Command line (CLI)

Pro: ability to install wider range of images and to fix any issues more easily

Con: more faff, more opportunity to make mistakes

19 of 34

Prepare the device - Google Pixel�(other devices may vary)

These instructions apply to Pixel devices - other devices can and will vary
This assumes you have already enabled developer options and enabled USB debugging, and the device is connected to your computer by USB
Don’t perform the following steps unless you’re okay with losing data on the device
Firstly, verify you can see your device in adb
Then reboot in to the bootloader. Wait until the device is in fastboot mode
Then unlock the bootloader. After issuing the `fastboot flashing unlock` command, follow the instructions on the device’s screen. This will erase all user data on the device
Now we want to disable verified boot verification so that the guest image can boot regardless of the signing key
Download the special vbmeta image from the URL on this slide
Once downloaded, flash this image to the vbmeta partition, also supplying the extra arguments to disable verification
The device is now ready to accept DSUs

20 of 34

DSU Loader - initiate installation

Settings app -> Developer options -> DSU Loader
Choose an image (usually GSI and GSI+GMS for different build numbers)
Agree to terms
Wait on the download to finish

21 of 34

DSU Loader - installation complete

Once the installation is complete, hit the “Restart” button on the notification

22 of 34

DSU Loader - success (hopefully)

If the boot was successful, you will see your guest image
If not, you should *hopefully* return to your main installation
And if that doesn’t happen, you may need to think about disaster recovery

23 of 34

Install DSU from CLI - prepare image

24 of 34

Install DSU from CLI - installation

25 of 34

Install DSU from CLI - installation

26 of 34

Install DSU from CLI - installation complete

Hopefully successful!

27 of 34

Making the DSU guest image sticky

By default, if you reboot from the guest image, it will reboot back to the host image
However, you can enable sticky mode

28 of 34

Disabling sticky mode

It is possible to disable sticky mode to make the main installation the default booted image.

29 of 34

Disaster recovery

The easiest way to recover from disaster is backups, or preferably, do this on a dedicated test device
Failed boots *should* recover by booting back into the main installation
Google provide factory images for Pixel devices at https://developers.google.com/android/images
Other OEMs should have their own recovery methods
Disclaimer: in the worst case scenario, you could hard-brick the device. You have been warned

30 of 34

Tips

Because of rollback protection, make the default installation an older version of Android
Do not use DSU on your daily driver
DSU Loader will show Android build numbers - see what they map to here: https://source.android.com/docs/setup/reference/build-numbers
Sometimes the instructions don’t result in success, so you may need to use your own intuition to solve issues, or give up

You may wish to move between Android versions. If so, you may wish to install an older version of Android as your primary installation with an older security datestamp so that your DSU installations always pass the rollback protection check
As alluded to before, it’s best to not use DSU on your daily driver because unlocking the bootloader disables some device security protections, and the chance of losing data
The DSU Loader UI will likely present Android build numbers rather than the more publicly understandable Android versions to you. To map between build numbers and Android versions, go to the shown URL
Sometimes the instructions in this presentation and on the Android Developers site doesn’t always result in success. You may need to search for help, use your own intuition or give up if you have issues

31 of 34

Possible use-case #1: testing across platform versions on real hardware

DSUs (usually) make it relatively easy to install new platform versions
Guest images have access to real hardware which the emulator does not
If you use AOSP images, you’re testing against the gold-standard of the Android platform
Money can be saved as you don’t need a full test lab

32 of 34

Possible use case #2: running userdebug builds on real hardware

Production builds are user builds signed by private vendor signing keys and are locked down - non-rooted
Testing and debugging builds are userdebug or eng builds - usually signed by AOSP-provided test-keys key and are not locked down as much - rooted
To access some hidden or restricted APIs, you need to be signed with the same key as the system and/or be a privileged app (e.g. your APK is installed in /system_ext/priv-app/)

33 of 34

Possible use case #2: running userdebug builds on real hardware (continued)

The test-keys are publicly available, so you can easily sign your APK with the same key in a userdebug system
In a userdebug built system, you can `adb root && adb remount` to push your APK to the normally read-only system with `adb push` then restart
Why do this? Curiosity, fun, learning how Android works internally!
Also, if you’re writing system services, it gives you a route to testing them if you’re still waiting on your test hardware to arrive

Because the test-keys are publicly available from AOSP, you can easily sign your APK with the same key as a userdebug-built system
In a userdebug system, because the production protections have been disabled, such as the ability to access root, you can remount the system as writable so you can push your APK to the priv-app installation location
So why do this? When messing around in a userdebug system, you can learn a lot about how Android works internally. It’s fun, and perhaps satisfies your curiosity. And with DSUs you don’t need to worry about breaking anything - if you mess the system up, you just return back to the host OS and install a new DSU image and try again
Also, if you’re writing system-level services for your day job but you don’t yet have access to development hardware, DSUs with userdebug images give you a route to testing them out. This is the reason I learnt about DSUs

34 of 34

Thank you!

Resources - overviews

https://developer.android.com/topic/generic-system-image

https://developer.android.com/topic/dsu

Resources - internals/how it works

https://source.android.com/docs/core/tests/vts/gsi

https://source.android.com/docs/core/ota/dynamic-system-updates

Bluesky: niallscott.bsky.social