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

Hinweis: Die RAM-Disk-Fehlerbehebung ändert sich AOSP werden identifiziert durch die debug_ramdisk Hashtag.

Ü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

Hinweis: Alle neuen Geräte, die mit Android 10 und höher auf den Markt gebracht wurden müssen initramfs verwenden, Dynamische Partitionen

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

Hinweis: Sie können jetzt aufhören zu lesen, wenn ein Android 12 GSI mit Version >= SGR1.210929.001 verwendet wird. Die folgenden Abschnitte enthalten die repack_bootimg Schritte, was nur bei Verwendung eines GSI für Android 11 erforderlich ist.

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

   Wichtig :${KERNEL_VERSION} ist hier nicht relevant. Sie können eine der boot-with-debug-ramdisk-${KERNEL_VERSION}.img.
   Hinweis: Seit dem 27.09.2021 ist boot-debug-${KERNEL_VERSION}.img in einem GSI-Build umbenannt in boot-with-debug-ramdisk-${KERNEL_VERSION}.img.

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.

   Hinweis :Unter repack_bootimg --help finden Sie eine ausführliche Verwendung und Beispiele.

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 der 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 bei 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

AVB-Fußzeile hinzufügen

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 Debug-RAMdisk nur verwendet werden kann, wenn ein 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

Wichtig: Die an --partition_size übergebene Nummer sollte basierend auf dem gerätespezifische Partitionsgröße, z.B. die Größe der Partition vendor_boot das Gerät.