VTS-Tests mit Debug-Ramdisk

Seit Android 10 hat sich das generische Systemimage (GSI), das zum Ausführen der CTS-on-GSI/VTS-Konformitätstests verwendet wird, von „userdebug“ zu „user“ geändert, um Release-signiert zu sein. Das ist ein Problem für VTS-Tests, da für VTS adb root erforderlich ist, adb root aber auf einem Gerät mit Nutzer-Build nicht verfügbar ist.

Die Debug-Ramdisk (oder das Debug-Boot-Image) wird eingeführt, um adb root auf einem Gerät mit Nutzer-Build zu aktivieren, dessen Bootloader entsperrt ist. Dadurch wird der Testablauf vereinfacht, da für CTS‑on‑GSI und VTS‑on‑GSI derselbe Nutzer-Build-GSI system.img verwendet wird. Für die STS-Einrichtung ist weiterhin ein anderes system.img-OEM-Userdebug erforderlich.

In der folgenden Tabelle sind die Änderungen bei Bild- und Build-Typen für Compliance-Tests in Android 10 aufgeführt.

Ü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 Partition boot des Geräts geflasht wird, werden die Userdebug-Version der System-SELinux-Datei und eine zusätzliche Eigenschaftendatei, adb_debug.prop, geladen. Dadurch kann adb root mit dem Nutzer-Build system.img (entweder GSIs oder die des OEM) verwendet werden.

Bei Geräten mit einer vendor_boot-Partition, die Generic Kernel Image (GKI) verwenden, 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 Partition vendor_boot geflasht werden, um die Debug-Ramdisk zu ermöglichen.

Voraussetzungen für die Verwendung einer Debug-Ramdisk

Die Debug-Ramdisk wird vom OEM bereitgestellt, der die Konformitätstests ausführt. Es darf nicht mit einem Release-Signaturschlüssel signiert sein und kann nur verwendet werden, wenn das Gerät entsperrt ist.

Die Debug-Ramdisk wird nicht generiert oder zum Upgraden von Geräten mit folgenden Eigenschaften verwendet:

• BOARD_BUILD_SYSTEM_ROOT_IMAGE true
• 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 Debug-Ramdisks nicht mehr mit dem Tool repack_bootimg aktualisiert werden. Der Android 12-GSI-Build nach SGR1.210929.001 (7777720) enthält die aktuelle userdebug_plat_sepolicy.cil-Datei in seinem system.img und ignoriert userdebug_plat_sepolicy.cil aus der Debug-Ramdisk. Weitere Informationen finden Sie in den Änderungslisten.

Android 11 GSI

Wenn boot-debug.img oder vendor_boot-debug.img verwendet wird, wird die System-SEPolicy aus der Datei userdebug_plat_sepolicy.cil im Debug-RAM-Laufwerk von boot-debug.img oder vendor_boot-debug.img geladen. Damit GSI-Images gebootet werden können, müssen Sie immer aktuelle sepolicy-Änderungen aus dem Branch android11-gsi einbeziehen, um boot-debug.img oder vendor_boot-debug.img neu zu erstellen.

Alternativ kann das repack_bootimg-Tool verwendet werden, um ein boot-debug.img oder vendor_boot-debug.img mit aktualisierten GSI-SELinux-Richtlinien neu zu erstellen.

Debug-Ramdisk neu packen

Anstatt sepolicy-Änderungen zur Neuerstellung von boot-debug.img einzubinden, 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.

So gehen Sie vor:

1. Laden Sie otatools.zip von https://ci.android.com herunter. Wir empfehlen, die Build-Artefakte von aosp_cf_arm64_only_phone-userdebug im aosp-android-latest-release-Branch 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 die userdebug_plat_sepolicy.cil oder boot-with-debug-ramdisk-${KERNEL_VERSION}.img aus dem GSI-Build herunter, den Sie verwenden. Wenn Sie beispielsweise ein arm64-GSI von RJR1.211020.001 (7840830) verwenden, laden Sie es von https://ci.android.com/builds/submitted/7840830/aosp_arm64-user/latest herunter.

4. Aktualisieren Sie das Gerät boot-debug.img oder vendor_boot-debug.img mit userdebug_plat_sepolicy.cil:

   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 entsprechend den Gerätekonfigurationen angepasst werden. Eine detaillierte Erklärung finden Sie im nächsten Abschnitt.

Pfad der userdebug-SEPolicy

Mit dem obigen repack_bootimg wird die Datei userdebug_plat_sepolicy.cil von der Ramdisk von --src_bootimg auf die Ramdisk von --dst_bootimg kopiert. Der Pfad in einer Debug-Ramdisk kann sich jedoch in verschiedenen Android-Versionen unterscheiden. 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 einer Debug-Ramdisk immer userdebug_plat_sepolicy.cil, unabhängig davon, ob androidboot.force_normal_boot=1 in der Kernel-Befehlszeile vorhanden ist. In der folgenden Tabelle sind die Pfade in einer Debug-Ramdisk in verschiedenen Android-Versionen aufgeführt.

Sie können --ramdisk_add angeben, um Dateien von und zu verschiedenen Pfaden mit einer Liste von src_path:dst_path-Paaren 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, sollte der Befehl wie unten 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 dem Ausführen des repack_bootimg-Befehls 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 ein vendor_boot-debug.img einen verketteten AVB-Footer hat.

avbtool info_image --image vendor_boot-debug.img

Wenn das Image ursprünglich eine verkettete AVB-Fußzeile hat, muss eine AVB-Fußzeile nach dem Ausführen des Befehls repack_bootimg hinzugefügt werden. Die Verwendung eines beliebigen Testschlüssels zum Signieren von vendor_boot-debug.img ist möglich, da die Debug-Ramdisk nur verwendet werden kann, wenn ein Gerät entsperrt ist. Dadurch können Bilder, die mit einem Nicht-Release-Schlüssel signiert wurden, auf der Partition boot oder vendor_boot verwendet werden.

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