VTS-Tests mit Debug-RAMdisk

Seit Android 10 wurde das Generic System Image (GSI), das zum Ausführen von Compliancetests für CTS-on-GSI/VTS verwendet wurde, vom Nutzer-Build-Typ in den Nutzer-Build-Typ geändert, um den Release zu signieren. Dies stellt ein Problem für VTS-Tests dar, da für VTS adb root erforderlich ist, aber adb root auf einem Nutzer-Build-Gerät nicht verfügbar ist.

Das Debug-Ramdisk (oder Debug-Boot-Image) wird eingeführt, um adb root auf einem von Nutzern erstellten Gerät zu aktivieren, dessen Bootloader entsperrt ist. Dies vereinfacht den Testablauf, indem derselbe Nutzer-Build GSI system.img für CTS-on-GSI und VTS-on-GSI verwendet wird. Für die STS-Einrichtung ist weiterhin die Verwendung eines anderen userdebug-OEM-system.img erforderlich.

Die folgende Tabelle zeigt Änderungen an Image- und Build-Typen für Compliance-Tests unter Android 10.

Übersicht

Diese zusätzlichen Bilddateien werden im Build-Ordner (${ANDROID_PRODUCT_OUT}) generiert:

• boot-debug.img
• vendor_boot-debug.img

Wenn boot-debug.img auf die boot-Partition des Geräts geflasht wird, werden die userdebug-Version der System-SEPolicy-Datei und eine zusätzliche Property-Datei namens adb_debug.prop geladen. So ist adb root mit dem Nutzerbuild system.img kompatibel (entweder des GSI oder des OEM).

Bei einem generischen Kernel-Image (GKI), das auf Geräten mit einer vendor_boot-Partition verwendet wird, darf boot-debug.img nicht geflasht werden, da die boot-Partition mit einem zertifizierten GKI-Image geflasht werden muss. Stattdessen sollte vendor_boot-debug.img auf die vendor_boot-Partition geflasht werden, um das Debug-Ramdisk zu vereinfachen.

Voraussetzungen für die Verwendung eines Debug-Ramdisks

Das Debug-Ramdisk wird vom OEM bereitgestellt, der die Compliance-Tests durchführt. Es muss nicht für die Veröffentlichung signiert sein und kann nur verwendet werden, wenn das Gerät entsperrt ist.

Das Debug-Ramdisk wird nicht generiert oder für das Upgrade von Geräten mit folgenden Eigenschaften verwendet:

• BOARD_BUILD_SYSTEM_ROOT_IMAGE wahr
• skip_initramfs in der Kernel-Befehlszeile

Android 12 GSI

Für die Verwendung von Debug-Ramdisk mit Android 12 GSI sind keine zusätzlichen Anweisungen erforderlich.

Ab dem 29.09.2021 müssen RAMdisks nicht mehr mit dem repack_bootimg-Tool aktualisiert werden. Der Android 12-GSI-Build nach SGR1.210929.001 (7777720) nimmt die aktuelle userdebug_plat_sepolicy.cil-Datei in seine system.img auf und ignoriert userdebug_plat_sepolicy.cil aus dem Debug-Ramdisk. Weitere Informationen finden Sie in den Änderungslisten.

Android 11 GSI

Wenn die boot-debug.img oder vendor_boot-debug.img verwendet wird, wird die System-SEPolicy aus der Datei userdebug_plat_sepolicy.cil im Debug-Ramdisk der boot-debug.img oder vendor_boot-debug.img geladen. Wenn Sie GSI-Images starten möchten, müssen Sie immer aktuelle Sepolicy-Änderungen aus dem Branch android11-gsi einbinden, um boot-debug.img oder vendor_boot-debug.img neu zu erstellen.

Alternativ kann das repack_bootimg-Tool verwendet werden, um eine boot-debug.img oder vendor_boot-debug.img mit aktualisierter GSI-SEPolicy neu zu erstellen.

Debug-Ramdisk neu verpacken

Anstatt Sepolicy-Änderungen zu übernehmen, um boot-debug.img neu zu erstellen, können Partner repack_bootimg verwenden, um die GSI-Sepolicy-Datei in boot-debug.img (oder vendor_boot-debug.img, wenn das Gerät GKI verwendet) zu aktualisieren.

Gehen Sie dazu so vor:

1. Laden Sie otatools.zip unter https://ci.android.com herunter. Wir empfehlen, die Build-Artefakte von aosp_arm64-userdebug auf aosp-main herunterzuladen.

2. Richten Sie die Ausführungsumgebung für repack_bootimg ein:

   unzip otatools.zip -d otatools
   export PATH="${PWD}/otatools/bin:${PATH}"
   repack_bootimg --help

3. Laden Sie userdebug_plat_sepolicy.cil oder boot-with-debug-ramdisk-${KERNEL_VERSION}.img aus dem verwendeten GSI-Build herunter. Wenn Sie beispielsweise eine arm64-GSI von RJR1.211020.001 (7840830) verwenden, laden Sie sie unter https://ci.android.com/builds/submitted/7840830/aosp_arm64-user/latest herunter.

4. Gerät boot-debug.img oder vendor_boot-debug.img mit userdebug_plat_sepolicy.cil aktualisieren:

   repack_bootimg --local --dst_bootimg boot-debug.img \
       --ramdisk_add userdebug_plat_sepolicy.cil:userdebug_plat_sepolicy.cil \
       --ramdisk_add userdebug_plat_sepolicy.cil:first_stage_ramdisk/userdebug_plat_sepolicy.cil
   # If using GKI
   repack_bootimg --local --dst_bootimg vendor_boot-debug.img \
       --ramdisk_add userdebug_plat_sepolicy.cil:userdebug_plat_sepolicy.cil \
       --ramdisk_add userdebug_plat_sepolicy.cil:first_stage_ramdisk/userdebug_plat_sepolicy.cil

   Mit boot-with-debug-ramdisk-${KERNEL_VERSION}.img:

   repack_bootimg --src_bootimg boot-with-debug-ramdisk-5.4.img \
       --dst_bootimg boot-debug.img \
       --ramdisk_add first_stage_ramdisk/userdebug_plat_sepolicy.cil:userdebug_plat_sepolicy.cil \
       --ramdisk_add first_stage_ramdisk/userdebug_plat_sepolicy.cil:first_stage_ramdisk/userdebug_plat_sepolicy.cil
   # If using GKI
   repack_bootimg --src_bootimg boot-with-debug-ramdisk-5.4.img \
       --dst_bootimg vendor_boot-debug.img \
       --ramdisk_add first_stage_ramdisk/userdebug_plat_sepolicy.cil:userdebug_plat_sepolicy.cil \
       --ramdisk_add first_stage_ramdisk/userdebug_plat_sepolicy.cil:first_stage_ramdisk/userdebug_plat_sepolicy.cil

   Die Argumente von --ramdisk_add können an die Gerätekonfigurationen angepasst werden. Eine detaillierte Erklärung finden Sie im nächsten Abschnitt.

Pfad der userdebug-SEPolicy

Mit dem obigen repack_bootimg-Befehl wird die Datei userdebug_plat_sepolicy.cil aus dem RAM-Disk von --src_bootimg in das RAM-Disk von --dst_bootimg kopiert. Der Pfad in einem Debug-Ramdisk kann jedoch in verschiedenen Android-Versionen unterschiedlich sein. Unter Android 10 und 11 lautet der Pfad first_stage_ramdisk/userdebug_plat_sepolicy.cil für Geräte mit androidboot.force_normal_boot=1 in der Kernel-Befehlszeile. Andernfalls ist der Pfad userdebug_plat_sepolicy.cil.

Führen Sie den folgenden Befehl aus, um zu prüfen, ob androidboot.force_normal_boot in der Kernel-Befehlszeile vorhanden ist:

adb root
adb shell cat /proc/cmdline | grep force_normal_boot

Ab Android 12 ist der Pfad in einem Debug-Ramdisk immer userdebug_plat_sepolicy.cil, unabhängig davon, ob androidboot.force_normal_boot=1 in der Kernel-Befehlszeile vorhanden ist. Die folgende Tabelle zeigt die Pfade in einem Debug-Ramdisk in verschiedenen Android-Versionen.

Sie können --ramdisk_add angeben, um Dateien mit einer Liste von src_path:dst_path-Paaren von und zu verschiedenen Pfaden zu kopieren. Mit dem folgenden Befehl wird beispielsweise die Datei first_stage_ramdisk/userdebug_plat_sepolicy.cil aus einem Android 11-boot-with-debug-ramdisk-5.4.img in first_stage_ramdisk/userdebug_plat_sepolicy.cil in einem Android 11-vendor_boot-debug.img kopiert.

repack_bootimg \
    --src_bootimg boot-with-debug-ramdisk-5.4.img \
    --dst_bootimg vendor_boot-debug.img \
    --ramdisk_add first_stage_ramdisk/userdebug_plat_sepolicy.cil:first_stage_ramdisk/userdebug_plat_sepolicy.cil

Wenn in der Kernel-Befehlszeile kein androidboot.force_normal_boot=1 vorhanden ist, muss der Befehl wie unten beschrieben angepasst werden, um den Zielpfad in userdebug_plat_sepolicy.cil zu ändern.

repack_bootimg \
    --src_bootimg boot-with-debug-ramdisk-5.4.img \
    --dst_bootimg vendor_boot-debug.img \
    --ramdisk_add first_stage_ramdisk/userdebug_plat_sepolicy.cil:userdebug_plat_sepolicy.cil

AVB-Fußzeile hinzufügen

Wenn das an --dst_bootimg übergebene Image als AVB-verkettete Partition konfiguriert ist, muss nach Ausführung des Befehls repack_bootimg eine AVB-Fußzeile hinzugefügt werden.

Führen Sie beispielsweise vor dem Ausführen von repack_bootimg den folgenden Befehl aus, um zu prüfen, ob vendor_boot-debug.img eine verkettete AVB-Fußzeile hat.

avbtool info_image --image vendor_boot-debug.img

Wenn die Datei ursprünglich eine verkettete AVB-Fußzeile hat, muss eine AVB-Fußzeile nach Ausführung des Befehls repack_bootimg hinzugefügt werden. Die Verwendung eines beliebigen Testschlüssels zum Signieren der vendor_boot-debug.img funktioniert, da das Debug-Ramdisk nur verwendet werden kann, wenn ein Gerät entsperrt ist. Dadurch sind Images, die nicht mit einem Release-Schlüssel signiert sind, auf der Partition boot oder vendor_boot zulässig.

avbtool add_hash_footer --partition_name vendor_boot \
    --partition_size 100663296 \
    --algorithm SHA256_RSA4096 \
    --key otatools/external/avb/test/data/testkey_rsa4096.pem \
    --image vendor_boot-debug.img