VTS Testing with Debug Ramdisk

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 GSI system.img. For STS setup, using another userdebug OEM system.img is still required. 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	userdebug	N	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.

The debug ramdisk won't be generated or used for upgrading devices with:

BOARD_BUILD_SYSTEM_ROOT_IMAGE true
skip_initramfs in kernel command line

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.img
boot-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).