Desde o Android 10,
Imagem genérica do sistema (GSI) usada para execução.
O teste de compliance CTS-on-GSI/VTS mudou
do tipo de build "userdebug" para o tipo de build "user" para ter assinatura de lançamento. Esta é uma
problema para o teste do VTS porque ele exige
adb root
para ser executado, mas
O adb root
não está disponível em dispositivos de build de usuário.
O ramdisk de depuração (ou imagem de inicialização de depuração) é introduzido para ativar o adb root
em um
dispositivo de build do usuário cujo carregador de inicialização é
desbloqueado. Isso simplifica os testes
usando a mesma GSI de build do usuário system.img
para CTS-on-GSI e
VTS na GSI. Para a configuração do STS, ainda é necessário usar outro OEM system.img
de userdebug
obrigatórios.
A tabela a seguir mostra as mudanças de imagem e tipo de build para testes de compliance em Android 10
Pacote de testes | Testar com | Criar | Depurar o ramdisk | raiz do adb? | Android 9 -> Mudança de 10 variantes de build |
---|---|---|---|---|---|
CTS | Sistema do OEM | user | N | N | Sem mudanças |
CTS-on-GSI (link em inglês) | GSI | user | N | N | userdebug -> GSI do usuário versão assinada |
STS | Sistema do OEM | userdebug | N | Y | Novidades no trimestre |
VTS (em inglês) | GSI | user | Y | Y | userdebug -> GSI do usuário versão assinada |
Visão geral
Esses arquivos de imagem extras são gerados na pasta de build
(${ANDROID_PRODUCT_OUT}
):
boot-debug.img
vendor_boot-debug.img
Quando a boot-debug.img
é atualizada na partição boot
do dispositivo, a
a versão userdebug do arquivo sepolicy do sistema e um arquivo de propriedade adicional,
adb_debug.prop
foram carregadas. Isso permite que adb root
com o build do usuário
system.img
(GSIs ou OEMs).
Para
Imagem genérica do kernel (GKI)
usar dispositivos que tenham uma partição vendor_boot
, boot-debug.img
não podem ser
atualizada, já que a partição boot
precisa ser atualizada com uma imagem GKI certificada.
Em vez disso, a vendor_boot-debug.img
precisa ser transferida por flash para o vendor_boot
.
para facilitar a depuração do ramdisk.
Pré-requisitos para usar um ramdisk de depuração
O ramdisk de depuração é fornecido pelo OEM que executa os testes de conformidade. Ela não pode ser assinado por lançamento e só pode ser usado se o dispositivo estiver desbloqueado.
O ramdisk de depuração não será gerado nem usado para fazer upgrade de dispositivos com:
BOARD_BUILD_SYSTEM_ROOT_IMAGE
verdadeiroskip_initramfs
na linha de comando do kernel
GSI do Android 12
Nenhuma outra instrução é necessária para usar o ramdisk de depuração com a GSI do Android 12.
A partir de 29/09/2021, os ramdisks de depuração não precisarão mais ser atualizados com a
Ferramenta repack_bootimg
. GSI do Android 12
build após SGR1.210929.001 (7777720)
incorporar a versão
userdebug_plat_sepolicy.cil
no system.img
e ignora
userdebug_plat_sepolicy.cil
no ramdisk de depuração. Consulte a
CLs para
detalhes.
GSI do Android 11
Quando boot-debug.img
ou vendor_boot-debug.img
são usados, o sistema
sepolicy é carregado do arquivo userdebug_plat_sepolicy.cil
na depuração
ramdisk da boot-debug.img
ou do vendor_boot-debug.img
. Para inicializar a GSI
imagens, incorpore sempre mudanças atualizadas de sepolicy do
android11-gsi
para recriar a boot-debug.img
ou o vendor_boot-debug.img
.
Como alternativa, a ferramenta repack_bootimg
pode ser usada para recriar um
boot-debug.img
ou vendor_boot-debug.img
com a sepolicy da GSI atualizada.
Recompactar um ramdisk de depuração
Em vez de incorporar mudanças da sepolicy para recriar o boot-debug.img
, os parceiros
pode usar repack_bootimg
para atualizar o arquivo sepolicy da GSI para boot-debug.img
.
(ou vendor_boot-debug.img
se o dispositivo usar GKI).
As etapas são as seguintes:
Baixar o
otatools.zip
de https://ci.android.com (link em inglês). Recomendamos fazer o download dos artefatos de build deaosp_arm64-userdebug
emaosp-main
.Configure o ambiente de execução para
repack_bootimg
:unzip otatools.zip -d otatools
export PATH="${PWD}/otatools/bin:${PATH}"
repack_bootimg --help
Faça o download do
userdebug_plat_sepolicy.cil
ouboot-with-debug-ramdisk-${KERNEL_VERSION}.img
do build da GSI que você está usando. Por exemplo, se você estiver usando uma GSI arm64 daRJR1.211020.001 (7840830)
, depois faça o download pelo https://ci.android.com/builds/submitted/7840830/aosp_arm64-user/latest (link em inglês).Atualize o dispositivo
boot-debug.img
ouvendor_boot-debug.img
comuserdebug_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
Com
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
Os argumentos de
--ramdisk_add
podem ser ajustados de acordo com o dispositivo personalizadas. Consulte a próxima seção para mais detalhes. explicação.
Caminho da sepolicy userdebug
O repack_bootimg
acima copia o arquivo userdebug_plat_sepolicy.cil
do
ramdisk de --src_bootimg
para o ramdisk de --dst_bootimg
. No entanto, o caminho
em um ramdisk de depuração podem ser diferentes em versões distintas do Android. Em
Android 10 e 11, o caminho é
first_stage_ramdisk/userdebug_plat_sepolicy.cil
para dispositivos com
androidboot.force_normal_boot=1
na linha de comando do kernel. Caso contrário, o
o caminho é userdebug_plat_sepolicy.cil
.
Execute o seguinte comando para verificar se há androidboot.force_normal_boot
na linha de comando do kernel:
adb root
adb shell cat /proc/cmdline | grep force_normal_boot
No Android 12 e versões mais recentes, o caminho em uma depuração
o ramdisk é sempre userdebug_plat_sepolicy.cil
, independentemente da existência de
androidboot.force_normal_boot=1
na linha de comando do kernel. O seguinte
mostra os caminhos em um ramdisk de depuração em diferentes versões do Android.
Depurar imagem | Android 10 | Android 11 | Android 12 |
---|---|---|---|
GKI boot-with-debug-ramdisk-${KERNEL_VERSION}.img | N/A | first_stage_ramdisk/userdebug_plat_sepolicy.cil |
userdebug_plat_sepolicy.cil |
boot-debug.img específico do dispositivo | Depende de force_normal_boot | Depende de force_normal_boot | userdebug_plat_sepolicy.cil |
Atributo específico do dispositivo fornecedor_boot-debug.img | N/A | Depende de force_normal_boot | userdebug_plat_sepolicy.cil |
Você pode especificar --ramdisk_add
para copiar arquivos de e para caminhos diferentes com um
lista de pares src_path:dst_path
. Por exemplo, o comando a seguir copia
o arquivo first_stage_ramdisk/userdebug_plat_sepolicy.cil
de uma boot-with-debug-ramdisk-5.4.img
do Android 11 para
first_stage_ramdisk/userdebug_plat_sepolicy.cil
em uma vendor_boot-debug.img
do 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
Se não houver androidboot.force_normal_boot=1
na linha de comando do kernel,
o comando deve ser ajustado conforme abaixo para alterar o caminho de destino para
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
Adicionar um rodapé do AVB
Se a imagem transmitida para --dst_bootimg
estiver configurada como um
Encadeamento AVB
partição, um rodapé AVB precisa ser adicionado depois de executar a repack_bootimg
kubectl.
Por exemplo, antes de executar repack_bootimg
, execute o seguinte comando para
verifica se um vendor_boot-debug.img
tem um rodapé AVB encadeado.
avbtool info_image --image vendor_boot-debug.img
Se ele originalmente tiver um rodapé AVB encadeado, será necessário adicionar um rodapé da AVB.
depois de executar o comando repack_bootimg
. Usar qualquer chave de teste para assinar o
vendor_boot-debug.img
funciona porque o ramdisk de depuração só pode ser usado quando um
dispositivo está desbloqueado, o que permite imagens assinadas de chave de não liberação no boot
ou
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