VTS-Tests mit Debug-RAMdisk

Seit Android 10 Generisches System-Image (GSI), das für die Ausführung verwendet wird Änderung der Compliancetests für CTS-on-GSI/VTS vom User-Debug bis zum Nutzer-Build-Typ, um die Veröffentlichung zu signieren. Dies ist ein Problem für VTS-Tests, da VTS adb root ausführen, aber adb root ist auf einem vom Nutzer erstellten Gerät nicht verfügbar.

Das Debugging-RAMdisk-Image (oder das Debugging-Boot-Image) wird eingeführt, um adb root auf einem Nutzer-Build-Gerät, dessen Bootloader entsperrt. Dies vereinfacht die Tests unter Verwendung derselben Nutzer-Build-GSI-system.img für CTS-on-GSI und VTS-on-GSI Bei der STS-Einrichtung ist die Verwendung eines anderen Nutzerdebug-OEMs system.img weiterhin möglich. erforderlich.

Die folgende Tabelle zeigt Änderungen der Image- und Build-Typen für Compliancetests in Android 10

Test-Suite Testen mit Eine Community Fehler in Ramdisk beheben ADB-Stamm? Android 9 -> 10 Änderung der Build-Variante
CTS System des OEMs Nutzer N N Keine Änderung
CTS auf GSI GSI Nutzer N N

userdebug -> Nutzer-GSI

unterschrieben über die Freilassung
STS System des OEMs Fehlerbehebung N J Neu im Q
VTS GSI Nutzer J J

userdebug -> Nutzer-GSI

unterschrieben über die Freilassung

Übersicht

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

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

Wenn boot-debug.img in die Partition boot des Geräts geladen wird, wird der userdebug-Version der Systemsepolicy-Datei und eine zusätzliche Eigenschaftsdatei, adb_debug.prop geladen. Dadurch kann adb root mit dem Nutzer-Build verwendet werden system.img (entweder von GSI oder vom OEM).

Für Generisches Kernel-Image (GKI) mit einer Partition vendor_boot verwenden, darf boot-debug.img nicht geflasht, da die Partition boot mit einem zertifizierten GKI-Image geflasht werden muss. Stattdessen sollte vendor_boot-debug.img auf das vendor_boot-Element gelegt werden. um die Fehlerbehebung für Ramdisk zu erleichtern.

Voraussetzungen für die Verwendung einer Debug-RAMdisk

Der Debug-RAM Disk wird von dem OEM bereitgestellt, der die Compliancetests ausführt. Es darf nicht unterschrieben sein und kann nur verwendet werden, wenn das Gerät entsperrt ist.

Die Debug-RAMdisk wird bei folgenden Geräten nicht generiert oder 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 weiteren Anweisungen erforderlich.

Ab dem 29.09.2021 müssen RAMdisks nicht mehr mit der repack_bootimg-Tool. Android 12 GSI Build, nachdem SGR1.210929.001 (7777720) die aktuellen userdebug_plat_sepolicy.cil-Datei in ihrer system.img und ignoriert userdebug_plat_sepolicy.cil aus der Debug-RAMdisk. Weitere Informationen finden Sie in der CLs für Details.

Android 11 GSI

Wenn boot-debug.img oder vendor_boot-debug.img verwendet wird, sepolicy wird im Debugging aus der Datei userdebug_plat_sepolicy.cil geladen Ramdisk von boot-debug.img oder vendor_boot-debug.img. Um GSI zu starten nehmen Sie bitte immer aktuelle Richtlinienänderungen aus den android11-gsi 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 aktualisierter GSI-Richtlinie.

Debug-RAMdisk neu packen

Anstatt sepolicy-Änderungen vorzunehmen, um boot-debug.img neu zu erstellen, kann mit repack_bootimg die GSI-Datei „sepolicy“ in boot-debug.img aktualisieren (oder vendor_boot-debug.img, wenn das Gerät GKI verwendet).

Dazu sind folgende Schritte erforderlich:

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

  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 von Ihrem GSI-Build verwenden. Wenn Sie z. B. eine arm64-GSI- RJR1.211020.001 (7840830), dann herunterladen von https://ci.android.com/builds/submitted/7840830/aosp_arm64-user/latest

  4. Gerät boot-debug.img oder vendor_boot-debug.img aktualisieren 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 je nach Gerät angepasst werden Konfigurationen. Ausführliche Informationen finden Sie im nächsten Abschnitt. Erklärung.

Pfad der Fehlerbehebungsrichtlinie für den Nutzer

Das obige repack_bootimg kopiert die Datei userdebug_plat_sepolicy.cil aus dem Ramdisk von --src_bootimg zur Ramdisk von --dst_bootimg. Der Pfad einer Debug-RAMdisk kann bei verschiedenen Android-Versionen unterschiedlich sein. In Android 10 und 11 ist der Pfad first_stage_ramdisk/userdebug_plat_sepolicy.cil für Geräte mit androidboot.force_normal_boot=1 in die Kernel-Befehlszeile. Andernfalls wird das Feld Pfad ist userdebug_plat_sepolicy.cil.

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

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

Ab Android 12 wird der Pfad innerhalb einer Fehlerbehebung ramdisk ist immer userdebug_plat_sepolicy.cil, unabhängig davon, ob androidboot.force_normal_boot=1 in die Kernel-Befehlszeile. Die folgenden Die Tabelle zeigt die Pfade innerhalb einer Debug-RAMdisk in verschiedenen Android-Versionen.

Bild zur Fehlerbehebung Android 10 Android 11 Android 12
GKI boot-with-debug-ramdisk-${KERNEL_VERSION}.img – first_stage_ramdisk/userdebug_plat_sepolicy.cil userdebug_plat_sepolicy.cil
Gerätespezifisches boot-debug.img Hängt von „force_normal_boot“ ab Hängt von „force_normal_boot“ ab userdebug_plat_sepolicy.cil
Gerätespezifisches „vendor_boot-debug.img“ – Hängt von „force_normal_boot“ ab userdebug_plat_sepolicy.cil

Sie können --ramdisk_add angeben, um Dateien mit einem Liste mit src_path:dst_path-Paaren. Mit dem folgenden Befehl wird beispielsweise Datei first_stage_ramdisk/userdebug_plat_sepolicy.cil von einem boot-with-debug-ramdisk-5.4.img-Gerät mit Android 11 first_stage_ramdisk/userdebug_plat_sepolicy.cil auf einem vendor_boot-debug.img mit Android 11.

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 androidboot.force_normal_boot=1 nicht vorhanden ist, Dann sollte der Befehl wie unten gezeigt angepasst werden, um den Zielpfad in userdebug_plat_sepolicy.cil.

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

Wenn das an --dst_bootimg übergebene Image als AVB-Verkettung muss eine AVB-Fußzeile hinzugefügt werden, nachdem die repack_bootimg ausgeführt wurde. .

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

avbtool info_image --image vendor_boot-debug.img

Wenn sie ursprünglich eine verkettete AVB-Fußzeile hat, muss eine AVB-Fußzeile hinzugefügt werden nach der Ausführung des Befehls repack_bootimg. Signieren der Datei mit einem beliebigen Testschlüssel vendor_boot-debug.img funktioniert, da die RAM-Disk zur Fehlerbehebung nur verwendet werden kann, Das Gerät ist entsperrt. Dadurch sind Bilder mit nicht vom Release-Schlüssel signierten Bildern auf dem boot oder vendor_boot-Partition.

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