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
wahrskip_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:
otatools.zip
herunterladen von https://ci.android.com auf. Wir empfehlen, die Build-Artefakte vonaosp_arm64-userdebug
herunterzuladen amaosp-main
.Richten Sie die Ausführungsumgebung für
repack_bootimg
ein:unzip otatools.zip -d otatools
export PATH="${PWD}/otatools/bin:${PATH}"
repack_bootimg --help
Laden Sie die
userdebug_plat_sepolicy.cil
oderboot-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/latestGerät
boot-debug.img
odervendor_boot-debug.img
aktualisieren mituserdebug_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 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