Od Androida 10 obraz systemu ogólnego (GSI) używany do przeprowadzania testów zgodności CTS-on-GSI/VTS zmienił się z typu userdebug na userbuild, aby można było go podpisać. Jest to problem z testowaniem VTS, ponieważ mechanizm VTS wymaga do działania adb root
, ale narzędzie adb root
nie jest dostępne na urządzeniu kompilacji użytkownika.
Wprowadzono obraz rozruchowy do debugowania (lub obraz rozruchowy do debugowania), aby umożliwić adb root
na urządzeniu z wersją użytkownika, którego program rozruchowy jest odblokowany. Upraszcza to proces testowania, ponieważ do testów CTS na GSI i VTS na GSI można używać tej samej kompilacji użytkownika na GSI system.img
. W przypadku konfiguracji STS nadal wymagane jest użycie innego OEM-u userdebugsystem.img
.
Poniższa tabela zawiera zmiany w typach obrazów i kompilacji na potrzeby testów zgodności w Androidzie 10.
Zestaw testów | Testowanie za pomocą | Budowanie | Debugowanie dysku RAM | adb root? | Android 9 -> Android 10 – zmiana wariantu kompilacji |
---|---|---|---|---|---|
CTS, | System OEM | użytkownik | N | N | Bez zmian |
CTS-on-GSI | GSI | użytkownik | N | N | userdebug -> user GSI release signed |
STS | System OEM | userdebug | N | Y | Nowości w Q |
VTS | GSI | użytkownik | Y | Y | userdebug -> GSI użytkownika release signed |
Omówienie
Te dodatkowe pliki obrazów są generowane w folderze kompilacji (${ANDROID_PRODUCT_OUT}
):
boot-debug.img
vendor_boot-debug.img
Gdy boot-debug.img
zostanie wgrany na partycję boot
urządzenia, wczytywane są wersja userdebug pliku systemowego sepolicy i dodatkowy plik właściwości adb_debug.prop
. Dzięki temu adb root
może korzystać z wersji użytkownika system.img
(GSI lub OEM).
W przypadku ogólnego obrazu jądra (GKI) na urządzeniach z partycją vendor_boot
nie można zapisać obrazu boot-debug.img
, ponieważ partycja boot
musi być zapisana za pomocą certyfikowanego obrazu GKI.
Zamiast tego vendor_boot-debug.img
należy przeflashować na partycji vendor_boot
, aby ułatwić debugowanie dysku RAM.
Wymagania wstępne dotyczące korzystania z pamieci RAM na potrzeby debugowania
Pamięć RAM do debugowania jest dostarczana przez producenta OEM, który przeprowadza testy zgodności. Nie może być podpisane i można go używać tylko wtedy, gdy urządzenie jest odblokowane.
Ramdysk debugowania nie będzie generowany ani używany do uaktualniania urządzeń z:
BOARD_BUILD_SYSTEM_ROOT_IMAGE
prawdaskip_initramfs
w wierszu poleceń jądra
Android 12 GSI
Aby używać debugowania w ramce z Androidem 12 GSI, nie musisz wykonywać żadnych dodatkowych czynności.
Od 29 września 2021 r. nie trzeba już aktualizować debugowanych dysków RAM za pomocą narzędzia repack_bootimg
. Wersja GSI Androida 12, która po SGR1.210929.001 (7777720)
zawiera aktualny plik userdebug_plat_sepolicy.cil
w katalogu system.img
i ignoruje plik userdebug_plat_sepolicy.cil
z trybusu debugowania. Więcej informacji znajdziesz w specyfikacji CL.
Android 11 GSI
Gdy używasz boot-debug.img
lub vendor_boot-debug.img
, system wczytuje plik sepolicy z pliku userdebug_plat_sepolicy.cil
na karcie pamięci RAM urządzenia boot-debug.img
lub vendor_boot-debug.img
. Aby uruchomić obrazy GSI, zawsze uwzględniaj aktualne zmiany w pliku sepolicy z gałęzi android11-gsi
, aby odbudować obraz boot-debug.img
lub vendor_boot-debug.img
.
Możesz też użyć narzędzia repack_bootimg
, aby odtworzyć plik boot-debug.img
lub vendor_boot-debug.img
z aktualizowanymi zasadami zabezpieczeń GSI.
Przepakowywanie pamięci RAM dysku debugowania
Zamiast wdrażać zmiany w sepolicy, aby ponownie skompilować boot-debug.img
, partnerzy mogą użyć repack_bootimg
, aby zaktualizować plik sepolicy GSI na boot-debug.img
(lub vendor_boot-debug.img
, jeśli urządzenie korzysta z GKI).
Aby to zrobić:
Pobierz
otatools.zip
ze strony https://ci.android.com. Zalecamy pobranie z archiwów kompilacjiaosp_arm64-userdebug
naaosp-main
.Skonfiguruj środowisko wykonania dla
repack_bootimg
:unzip otatools.zip -d otatools
export PATH="${PWD}/otatools/bin:${PATH}"
repack_bootimg --help
Pobierz plik
userdebug_plat_sepolicy.cil
lubboot-with-debug-ramdisk-${KERNEL_VERSION}.img
z wersji GSI, której używasz. Jeśli na przykład używasz GSI arm64 zRJR1.211020.001 (7840830)
, pobierz z https://ci.android.com/builds/submitted/7840830/aosp_arm64-user/latest.Zaktualizuj urządzenie
boot-debug.img
lubvendor_boot-debug.img
do wersjiuserdebug_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
Z użyciem aplikacji
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
Argumenty funkcji
--ramdisk_add
można dostosować do konfiguracji urządzenia. Szczegółowe informacje znajdziesz w następnej sekcji.
Ścieżka zasady sekwencji debugowania użytkownika
Powyższy wiersz kodu repack_bootimg
kopiuje plik userdebug_plat_sepolicy.cil
z dysku RAM --src_bootimg
na dysk RAM --dst_bootimg
. Ścieżka na dysku RAM debugowania może jednak być inna w różnych wersjach Androida. W Androidzie 10 i 11 ścieżka to first_stage_ramdisk/userdebug_plat_sepolicy.cil
na urządzeniach z androidboot.force_normal_boot=1
w wierszu poleceń jądra. W przeciwnym razie ścieżka to userdebug_plat_sepolicy.cil
.
Aby sprawdzić, czy w wierszu poleceń jądra jest androidboot.force_normal_boot
, uruchom to polecenie:
adb root
adb shell cat /proc/cmdline | grep force_normal_boot
Od Androida 12 ścieżka na karcie pamięci debugowania jest zawsze userdebug_plat_sepolicy.cil
, niezależnie od istnienia androidboot.force_normal_boot=1
w wierszu poleceń jądra. Poniższa tabela zawiera ścieżki w pamięci RAM na potrzeby debugowania w różnych wersjach Androida.
Debugowanie obrazu | Android 10 | Android 11 | Android 12 |
---|---|---|---|
GKI boot-with-debug-ramdisk-${KERNEL_VERSION}.img | Nie dotyczy | first_stage_ramdisk/userdebug_plat_sepolicy.cil |
userdebug_plat_sepolicy.cil |
boot-debug.img dla konkretnego urządzenia | Zależy od force_normal_boot | Zależy od force_normal_boot | userdebug_plat_sepolicy.cil |
vendor_boot-debug.img dotyczący konkretnego urządzenia | Nie dotyczy | Zależy od force_normal_boot | userdebug_plat_sepolicy.cil |
Możesz użyć parametru --ramdisk_add
, aby kopiować pliki z różnych ścieżek do innych ścieżek za pomocą listy par src_path:dst_path
. Na przykład to polecenie kopiuje plik first_stage_ramdisk/userdebug_plat_sepolicy.cil
z Androida 11 boot-with-debug-ramdisk-5.4.img
do first_stage_ramdisk/userdebug_plat_sepolicy.cil
w Androidzie 11 vendor_boot-debug.img
.
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
Jeśli w wierszu poleceń jądra nie ma parametru androidboot.force_normal_boot=1
, należy zmienić polecenie w taki sposób, jak pokazano poniżej, aby zmienić ścieżkę docelową na 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
Dodawanie stopki AVB
Jeśli obraz przekazany do --dst_bootimg
jest skonfigurowany jako partycja połączona z AVB, po wykonaniu polecenia repack_bootimg
należy dodać stopkę AVB.
Na przykład przed uruchomieniem repack_bootimg
uruchom to polecenie, aby sprawdzić, czy vendor_boot-debug.img
ma łańcuchowy nagłówek AVB.
avbtool info_image --image vendor_boot-debug.img
Jeśli zawiera ona łańcuchową stopkę AVB, musisz dodać stopkę AVB po wykonaniu polecenia repack_bootimg
. Użycie dowolnego klucza testowego do podpisania vendor_boot-debug.img
działa, ponieważ dysk RAM do debugowania może być używany tylko wtedy, gdy urządzenie jest odblokowane, co umożliwia używanie obrazów podpisanych kluczem nieprzeznaczonym do wydania na partycji boot
lub vendor_boot
.
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