Testes VTS com ramdisk de depuração

Desde o Android 10, a imagem genérica do sistema (GSI) usada para executar o teste de compliance CTS-on-GSI/VTS mudou de userdebug para o tipo de build do usuário para ser assinado pela versão. Isso é um problema para o teste do VTS porque ele requer a execução de adb root, mas adb root não está disponível em um dispositivo de build do 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 está desbloqueado. Isso simplifica o fluxo de testes usando a mesma GSI system.img do build do usuário para CTS-on-GSI e VTS-on-GSI. Para a configuração do STS, ainda é necessário usar outro OEM system.img de userdebug.

A tabela a seguir mostra as mudanças de imagem e tipo de build para testes de compliance no Android 10.

Pacote de testes Testar com Criar Ramdisk de depuração adb root? Mudança na variante de build do Android 9 para o 10
CTS Sistema do OEM user N N Sem alterações
CTS-on-GSI (link em inglês) GSI user N N

userdebug -> user GSI

versão assinada

STS Sistema do OEM userdebug N Y Novidades do Q
VTS (em inglês) GSI user Y Y

userdebug -> GSI do usuário

versão assinada

Visão geral

Esses arquivos de imagem adicionais são gerados na pasta de build (${ANDROID_PRODUCT_OUT}):

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

Quando boot-debug.img é atualizado na partição boot do dispositivo, a versão de userdebug do arquivo sepolicy do sistema e um arquivo de propriedade extra, adb_debug.prop, são carregados. Isso permite que adb root seja usado com o build do usuário system.img (GSI ou OEM).

Para imagens genéricas do kernel (GKI, na sigla em inglês) que usam dispositivos com uma partição vendor_boot, o boot-debug.img não pode ser flasheado, já que a partição boot precisa ser flasheada com uma imagem GKI certificada. Em vez disso, o vendor_boot-debug.img precisa ser atualizado na partição vendor_boot para facilitar o debug do ramdisk.

Pré-requisitos para usar um ramdisk de depuração

O ramdisk de depuração é fornecido pelo OEM que executa os testes de compliance. Ele não pode ser assinado para 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 verdadeiro
  • skip_initramfs na linha de comando do kernel

GSI do Android 12

Nenhuma instrução extra é necessária para usar o ramdisk de depuração com a GSI do Android 12.

A partir de 29/09/2021, as ramdisks de depuração não precisam mais ser atualizadas com a ferramenta repack_bootimg. O build do GSI do Android 12 depois que SGR1.210929.001 (7777720) incorpora o arquivo userdebug_plat_sepolicy.cil atualizado no system.img e ignora userdebug_plat_sepolicy.cil do ramdisk de depuração. Consulte os CLs para mais detalhes.

GSI do Android 11

Quando boot-debug.img ou vendor_boot-debug.img é usado, a sepolicy do sistema é carregada do arquivo userdebug_plat_sepolicy.cil no ramdisk de depuração do boot-debug.img ou vendor_boot-debug.img. Para inicializar imagens do GSI, sempre incorpore as alterações de política de segurança atualizadas da filial android11-gsi para recriar o 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 política de segurança do GSI atualizada.

Recompactar um ramdisk de depuração

Em vez de incorporar mudanças de sepolicy para recriar boot-debug.img, os parceiros podem usar repack_bootimg para atualizar o arquivo de sepolicy da GSI em boot-debug.img (ou vendor_boot-debug.img se o dispositivo usar GKI).

As etapas são as seguintes:

  1. Faça o download de otatools.zip em https://ci.android.com. Recomendamos fazer o download dos artefatos de build de aosp_arm64-userdebug em aosp-main.

  2. Configure o ambiente de execução para repack_bootimg:

    unzip otatools.zip -d otatools
    export PATH="${PWD}/otatools/bin:${PATH}"
    repack_bootimg --help
  3. Faça o download de userdebug_plat_sepolicy.cil ou boot-with-debug-ramdisk-${KERNEL_VERSION}.img do build da GSI que você está usando. Por exemplo, se você estiver usando uma GSI arm64 do RJR1.211020.001 (7840830), faça o download em https://ci.android.com/builds/submitted/7840830/aosp_arm64-user/latest.

  4. Atualize o boot-debug.img ou vendor_boot-debug.img do dispositivo com 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

    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 as configurações do dispositivo. Consulte a próxima seção para uma explicação detalhada.

Caminho da sepolicy do 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 pode ser diferente em diferentes versões do Android. No 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 caminho será userdebug_plat_sepolicy.cil.

Execute o comando abaixo 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 um ramdisk de depuração é sempre userdebug_plat_sepolicy.cil, independente da existência de androidboot.force_normal_boot=1 na linha de comando do kernel. A tabela a seguir 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
vendor_boot-debug.img específico do dispositivo N/A Depende de force_normal_boot userdebug_plat_sepolicy.cil

É possível especificar --ramdisk_add para copiar arquivos de e para caminhos diferentes com uma lista de pares src_path:dst_path. Por exemplo, o comando a seguir copia o arquivo first_stage_ramdisk/userdebug_plat_sepolicy.cil de um boot-with-debug-ramdisk-5.4.img do Android 11 para first_stage_ramdisk/userdebug_plat_sepolicy.cil em um 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 precisará ser ajustado conforme abaixo para mudar 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

Se a imagem transmitida para --dst_bootimg estiver configurada como uma partição AVB-chained, um rodapé AVB precisará ser adicionado após a execução do comando repack_bootimg.

Por exemplo, antes de executar repack_bootimg, execute o comando a seguir para verificar se um vendor_boot-debug.img tem um rodapé AVB encadeado.

avbtool info_image --image vendor_boot-debug.img

Se ele tiver um rodapé AVB encadeado, será necessário adicionar um depois de executar o comando repack_bootimg. O uso de 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 com chaves não de lançamento na partição 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