Imagens genéricas do sistema

Uma imagem genérica do sistema (GSI) é uma imagem do sistema com configurações ajustadas para dispositivos Android. É considerado uma implementação Android pura com código Android Open Source Project (AOSP) não modificado que qualquer dispositivo Android executando o Android 9 ou superior pode ser executado com sucesso.

Os GSIs são usados ​​para executar testes VTS e CTS-on-GSI. A imagem do sistema de um dispositivo Android é substituída por uma GSI e testada com o Vendor Test Suite (VTS) e o Compatibility Test Suite (CTS) para garantir que o dispositivo implemente as interfaces do fornecedor corretamente com a versão mais recente do Android.

Para começar com GSIs, revise as seções a seguir para obter detalhes sobre configurações de GSI (e variações permitidas) e tipos . Quando estiver pronto para usar um GSI, baixe e crie o GSI para o destino do seu dispositivo e, em seguida, atualize o GSI para um dispositivo Android.

Configuração e variações de GSI

A GSI do Android atual tem a seguinte configuração:

O GSI do Android atual inclui as seguintes variações principais:

  • Arquitetura da CPU. Suporte para diferentes instruções de CPU (ARM, x86, etc.) e bitness da CPU (32 bits ou 64 bits).

Metas GSI para testes de conformidade do Treble

O GSI usado para teste de conformidade é determinado pela versão do Android com a qual o dispositivo é iniciado.

Tipo de dispositivo Destino de compilação
Dispositivos lançados com Android 12 gsi_$arch-user (assinado)
Dispositivos lançados com o Android 11 gsi_$arch-user (assinado)
Dispositivos lançados com Android 10 gsi_$arch-user (assinado)
Dispositivos lançados com Android 9 gsi_$arch-userdebug

Todos os GSIs são criados a partir da base de código do Android 12 e cada arquitetura de CPU tem um binário GSI correspondente (consulte a lista de destinos de compilação em Como criar GSIs ).

Alterações no GSI do Android 12

Os dispositivos lançados ou atualizados para o Android 12 devem usar GSIs do Android 12 para testes de conformidade. Isso inclui as seguintes alterações principais de GSIs anteriores:

  • Nome do alvo. O nome do destino GSI para testes de conformidade foi alterado para gsi_$arch . O GSI com o nome de destino aosp_$arch é mantido para desenvolvedores de aplicativos Android. O plano de teste CTS-on-GSI também é reduzido para testar a interface do fornecedor.
  • O GSI legado é descontinuado. O GSI 12 remove as soluções alternativas que acomodam dispositivos Android 8.0 ou 8.1 que não são totalmente Treblized.
  • Userdebug SEPolicy. O GSI gsi_$arch contém userdebug_plat_sepolicy.cil . Ao vendor_boot-debug.img específico do OEM ou boot-debug.img , /system/bin/init carregará userdebug_plat_sepolicy.cil do GSI system.img . Consulte Teste de VTS com Debug Ramdisk para obter detalhes.

Alterações no GSI do Android 11

Os dispositivos lançados ou atualizados para o Android 11 devem usar GSIs do Android 11 para testes de conformidade. Isso inclui as seguintes alterações principais de GSIs anteriores:

  • conteúdo do system_ext. O Android 11 define uma nova partição system_ext . A GSI coloca o conteúdo da extensão do sistema na pasta system/system_ext .
  • APEX. A GSI contém APEXes achatados e compactados. Qual usar é determinado pela propriedade do sistema ro.apex.updatable na partição do fornecedor em tempo de execução. Consulte Configurando o sistema para oferecer suporte a atualizações do APEX para obter detalhes.

Alterações no GSI do Android 10

Os dispositivos lançados ou atualizados para o Android 10 devem usar GSIs do Android 10 para testes de conformidade. Isso inclui as seguintes alterações principais de GSIs anteriores:

  • Construção do usuário. A GSI tem a versão do usuário do Android 10. No Android 10, a GSI da versão do usuário pode ser usada em testes de conformidade CTS-on-GSI/VTS. Consulte Teste de VTS com Debug Ramdisk para obter detalhes.
  • Formato não esparso. GSI com alvos aosp_$arch são construídos com formato não esparso. Você pode usar img2simg para converter um GSI não esparso em formato esparso, se necessário.
  • Sistema-como-raiz. O destino de compilação GSI legado chamado aosp_$arch_a foi descontinuado. Para os dispositivos atualizados do Android 8 ou 8.1 para o Android 10 com ramdisk e sem sistema como root, use o GSI legado aosp_$arch_ab . O init atualizado em ramdisk suporta OEM system.img com layout de sistema como raiz.
  • Verifique a inicialização. Usando GSI você só precisa desbloquear o dispositivo. Não é necessário desabilitar a inicialização de verificação.

Alterações GSI do Android 9

Os dispositivos iniciados com ou atualizados para o Android 9 devem usar GSIs do Android 9 para testes de conformidade. Isso inclui as seguintes alterações principais de GSIs anteriores:

  • Mescla GSI e emulador. Os GSIs são construídos a partir das imagens do sistema de produtos emuladores, por exemplo, aosp_arm64 e aosp_x86 .
  • Sistema-como-raiz. Nas versões anteriores do Android, os dispositivos que não suportavam atualizações A/B podiam montar a imagem do sistema no diretório /system . No Android 9, a raiz da imagem do sistema é montada como a raiz do dispositivo.
  • Interface de fichário de 64 bits. No Android 8.x, os GSIs de 32 bits usavam a interface do binder de 32 bits. O Android 9 não é compatível com a interface do binder de 32 bits, portanto, GSIs de 32 bits e GSIs de 64 bits usam a interface do binder de 64 bits.
  • Aplicação do VNDK. No Android 8.1, o VNDK era opcional. A partir do Android 9, o VNDK é obrigatório, portanto, BOARD_VNDK_VERSION deve ser definido.
  • Propriedade de sistema compatível. O Android 9 habilita a verificação de acesso para uma propriedade de sistema compatível ( PRODUCT_COMPATIBLE_PROPERTY_OVERRIDE := true ).

Mudanças no Android 9 Keymaster

Nas versões anteriores do Android, os dispositivos que implementavam o Keymaster 3 ou inferior precisavam verificar se as informações de versão ( ro.build.version.release e ro.build.version.security_patch ) relatadas pelo sistema em execução correspondiam às informações de versão relatadas pelo bootloader. Essas informações geralmente eram obtidas do cabeçalho da imagem de inicialização.

No Android 9 e superior, esse requisito foi alterado para permitir que os fornecedores inicializem uma GSI. Especificamente, o Keymaster não deve realizar a verificação porque as informações de versão relatadas pelo GSI podem não corresponder às informações de versão relatadas pelo carregador de inicialização do fornecedor. Para dispositivos que implementam o Keymaster 3 ou inferior, os fornecedores devem modificar a implementação do Keymaster para ignorar a verificação (ou atualizar para o Keymaster 4). Para obter detalhes sobre o Keymaster, consulte Keystore com suporte de hardware .

Baixando GSIs

Você pode baixar GSIs pré-criados do site de integração contínua (CI) do AOSP em ci.android.com . Se o tipo de GSI para sua plataforma de hardware não estiver disponível para download, consulte a seção a seguir para obter detalhes sobre como criar GSIs para destinos específicos.

Construindo GSIs

A partir do Android 9, cada versão do Android tem uma ramificação GSI chamada DESSERT -gsi no AOSP (por exemplo, android12-gsi é a ramificação GSI no Android 12). As ramificações GSI incluem o conteúdo do Android com todos os patches de segurança e patches GSI aplicados.

Para criar uma GSI, configure a árvore de origem do Android fazendo download de uma ramificação da GSI e escolhendo um destino de compilação da GSI . Use as tabelas de destino de compilação abaixo para determinar a versão GSI correta para seu dispositivo. Após a conclusão da compilação, o GSI é a imagem do sistema (ou seja, system.img ) e aparece na pasta de saída out/target/product/ generic_arm64 .

Por exemplo, para compilar o destino de compilação GSI gsi_arm64-userdebug na ramificação GSI android12-gsi , execute os comandos a seguir.

$ repo init -u https://android.googlesource.com/platform/manifest -b android12-gsi
$ repo sync -cq
$ source build/envsetup.sh
$ lunch gsi_arm64-userdebug
$ make -j4

Destinos de compilação do Android GSI

Os seguintes destinos de compilação de GSI são para dispositivos iniciados no Android 9 ou superior.

Nome GSI Arco de CPU Bitness da interface do fichário Sistema como raiz Destino de compilação
gsi_arm BRAÇO 64 S gsi_arm-user
gsi_arm-userdebug
gsi_arm64 ARM64 64 S gsi_arm64-user
gsi_arm64-userdebug
gsi_x86 x86 64 S gsi_x86-user
gsi_x86-userdebug
gsi_x86_64 x86-64 64 S gsi_x86_64-user
gsi_x86_64-userdebug

Requisitos para flashear GSIs

Os dispositivos Android podem ter designs diferentes, portanto, não há comando genérico ou conjunto de instruções para atualizar uma GSI para aplicar a todos os dispositivos. Consulte o fabricante do dispositivo Android para obter instruções explícitas de flash. Use as etapas a seguir como uma diretriz geral:

  1. Certifique-se de que o dispositivo tenha o seguinte:
    • Treblited
    • Um método para desbloquear dispositivos (para que eles possam ser atualizados usando fastboot )
    • Um estado desbloqueado para torná-lo flashable via fastboot (para garantir que você tenha a versão mais recente do fastboot , compile-o a partir da árvore de origem do Android.)
  2. Apague a partição do sistema atual e, em seguida, atualize o GSI para a partição do sistema.
  3. Limpe os dados do usuário e limpe os dados de outras partições necessárias (por exemplo, dados do usuário e partições do sistema).
  4. Reinicie o dispositivo.

Por exemplo, para fazer o flash de uma GSI em qualquer dispositivo Pixel:

  1. Inicialize no modo fastboot e desbloqueie o bootloader .
  2. Os dispositivos que suportam fastbootd também precisam inicializar no fastbootd por:
    $ fastboot reboot fastboot
  3. Apague e atualize o GSI para a partição do sistema:
    $ fastboot erase system
$ fastboot flash system system.img
  4. Limpe os dados do usuário e limpe os dados de outras partições necessárias (por exemplo, dados do usuário e partições do sistema):
    $ fastboot -w
  5. Reinicialização:
    $ fastboot reboot
Em dispositivos Android 10 ou mais recentes com partições de sistema menores, a seguinte mensagem de erro pode aparecer ao atualizar o GSI:
    Resizing 'system_a'    FAILED (remote: 'Not enough space to resize partition')
    fastboot: error: Command failed
Use o comando a seguir para excluir a partição do produto e liberar espaço para a partição do sistema. Isso fornece espaço extra para atualizar o GSI:
$ fastboot delete-logical-partition product_a
O postfix _a deve corresponder ao ID do slot da partição do sistema, como system_a neste exemplo.

Contribuindo para o GSI

O Android agradece suas contribuições para o desenvolvimento de GSI. Você pode se envolver e ajudar a melhorar o GSI:

  • Criando um patch GSI. DESSERT -gsi não é uma ramificação de desenvolvimento e aceita apenas seleções da ramificação mestre AOSP, portanto, para enviar um patch GSI, você deve:
    1. Envie o patch para o branch master do AOSP .
    2. Escolha o patch para DESSERT -gsi .
    3. Registre um bug para que o cherrypick seja revisado.
  • Relatando bugs de GSI ou fazendo outras sugestões. Revise as instruções em Reporting Bugs , então procure ou arquive bugs GSI .

Pontas

Alterando o modo da barra de navegação usando adb

Ao inicializar com GSI, o modo da barra de navegação é configurado pela substituição do fornecedor. Você pode alterar o modo da barra de navegação executando o seguinte comando adb em tempo de execução.

adb exec-out cmd overlay enable-exclusive com.android.internal.systemui.navbar.mode

Onde o mode pode ser threebutton botões , twobutton , gestural e assim por diante.