In Android 10, the
generic system image (GSI) used to
run CTS-on-GSI/VTS
compliance testing changes from userdebug to user build type, because GSI is
release signed. However, the
adb root
command that gives a host root permissions to the Android device under test
isn't available in a user build. This is a problem because VTS requires
adb root to run.
The debug ramdisk is introduced in Android 10 to make
adb root possible, if the device is unlocked. This simplifies the testing flow
by reusing the same user build system.img (either GSI or the OEM’s
system.img). The following table shows images and build types for the
compliance tests in Android 10.
| Test suite | Test with | Build | Debug ramdisk | adb root? | Android 9 -> 10 build variant change |
|---|---|---|---|---|---|
| CTS | OEM’s system | user | N | N | No change |
| CTS-on-GSI | GSI | user | N | N | userdebug -> user GSI release signed |
| STS | OEM’s system | user | Y | Y | New in Q |
| VTS | GSI | user | Y | Y | userdebug -> user GSI release signed |
Prerequisites for using a debug ramdisk
The debug ramdisk is provided by the OEM running the compliance tests. It shouldn't be release signed, and it can only be used if the device is unlocked.
AOSP changes
The debug ramdisk changes in
AOSP are identified by
the
debug_ramdisk
hashtag.
These additional image files are generated under the build folder
out/target/product/$(TARGET_DEVICE):
ramdisk-debug.imgboot-debug.img
When boot-debug.img is flashed onto the /boot partition of the device, the
userdebug version of the system sepolicy file and an additional property file,
adb_debug.prop, are loaded. This allows adb root with the user build
system.img (either GSI’s or the OEM’s).