Imagens genéricas do sistema

Uma imagem genérica do sistema (GSI) é uma imagem do sistema com configurações ajustadas para dispositivos Android. É considerada uma implementação Android pura com código Android Open Source Project (AOSP) não modificado que qualquer dispositivo Android com Android 9 ou superior pode executar 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 um GSI e testado 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 a usar 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 seu destino de dispositivo e, em seguida , atualize o GSI para um dispositivo Android.

Configuração e variações de GSI

O Android GSI atual tem a seguinte configuração:

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

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

Metas GSI para testes de conformidade com Treble

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

Tipo de dispositivo Construir alvo
Dispositivos lançados com o Android 12 gsi_$arch-user (assinado)
Dispositivos sendo lançados com o Android 11 gsi_$arch-user (assinado)
Dispositivos sendo lançados com o Android 10 gsi_$arch-user (assinado)
Dispositivos sendo lançados com o 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 Construindo GSIs ).

Alterações GSI do Android 12

Os dispositivos iniciados ou atualizados para o Android 12 devem usar Android 12 GSIs para testes de conformidade. Isso inclui as seguintes mudanças importantes de GSIs anteriores:

  • Nome do alvo. O nome do destino GSI para testes de conformidade foi alterado para gsi_$arch . O GSI com 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.
  • A GSI herdada foi desativada. O GSI 12 remove as soluções alternativas que acomodam dispositivos Android 8.0 ou 8.1 que não são totalmente Treblizados.
  • SEPolicy de depuração do usuário. O GSI gsi_$arch contém userdebug_plat_sepolicy.cil . Ao atualizar o vendor_boot-debug.img ou boot-debug.img específico do OEM, /system/bin/init carregará userdebug_plat_sepolicy.cil do GSI system.img . Consulte Teste VTS com Debug Ramdisk para obter detalhes.

Alterações GSI do Android 11

Os dispositivos iniciados ou atualizados para o Android 11 devem usar Android 11 GSIs para testes de conformidade. Isso inclui as seguintes mudanças importantes de GSIs anteriores:

  • conteúdo system_ext. O Android 11 define uma nova partição system_ext . GSI coloca o conteúdo da extensão do sistema na pasta system/system_ext .
  • APEXes. GSI contém APEXs achatados e compactados. Qual usar é determinado pela propriedade do sistema ro.apex.updatable na partição do fornecedor no tempo de execução. Referência Configurando o sistema para suportar atualizações APEX para o detalhe.

Alterações GSI do Android 10

Os dispositivos iniciados ou atualizados para o Android 10 devem usar Android 10 GSIs para testes de conformidade. Isso inclui as seguintes mudanças importantes de GSIs anteriores:

  • Construção do usuário. A GSI foi criada pelo usuário a partir do Android 10. No Android 10, a GSI criada pelo usuário pode ser usada em testes de conformidade CTS-on-GSI/VTS. Consulte VTS Testing with 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 root. O destino de compilação do GSI herdado chamado aosp_$arch_a foi eliminado. Para os dispositivos atualizados do Android 8 ou 8.1 para o Android 10 com ramdisk e sem sistema como root, use o legado GSI aosp_$arch_ab . O init atualizado em ramdisk suporta OEM system.img com layout de sistema como raiz.
  • Verifique a inicialização. Usando o GSI, você só precisa desbloquear o dispositivo. Não é necessário desabilitar a verificação de inicialização.

Alterações GSI do Android 9

Os dispositivos iniciados ou atualizados para o Android 9 devem usar Android 9 GSIs para testes de conformidade. Isso inclui as seguintes mudanças importantes 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 root. 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 raiz do dispositivo.
  • Interface de fichário de 64 bits. No Android 8.x, GSIs de 32 bits usavam a interface de fichário de 32 bits. O Android 9 não oferece suporte à interface do fichário de 32 bits, portanto, GSIs de 32 bits e GSIs de 64 bits usam a interface do fichário de 64 bits.
  • Aplicação de VNDK. No Android 8.1, o VNDK era opcional. A partir do Android 9, o VNDK é obrigatório, então BOARD_VNDK_VERSION deve ser definido.
  • Propriedade do 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 Keymaster do Android 9

Em versões anteriores do Android, os dispositivos que implementavam o Keymaster 3 ou inferior precisavam verificar se as informações da versão ( ro.build.version.release e ro.build.version.security_patch ) relatadas pelo sistema em execução correspondiam às informações da 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 um 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é-construídos no 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 a criação de GSIs para destinos específicos.

Criação de 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 um GSI, configure a árvore de origem do Android baixando de uma ramificação do GSI e escolhendo um destino de compilação do 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 criar o destino de compilação GSI gsi_arm64-userdebug na ramificação GSI android12-gsi , execute os seguintes comandos.

$ 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 GSI são para dispositivos iniciados no Android 9 ou superior.

nome GSI arco da CPU Número de bits da interface do fichário Sistema como raiz Construir alvo
gsi_arm BRAÇO 64 Y gsi_arm-user
gsi_arm-userdebug
gsi_arm64 ARM64 64 Y gsi_arm64-user
gsi_arm64-userdebug
gsi_x86 x86 64 Y gsi_x86-user
gsi_x86-userdebug
gsi_x86_64 x86-64 64 Y gsi_x86_64-user
gsi_x86_64-userdebug

Requisitos para atualizar GSIs

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

  1. Certifique-se de que o dispositivo tenha o seguinte:
    • Treblado
    • Um método para desbloquear dispositivos (para que 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 , crie-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 atualizar um GSI para 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. Reiniciar:
    $ fastboot reboot
Em dispositivos Android 10 ou mais recentes com partições de sistema menores, a seguinte mensagem de erro pode aparecer ao piscar o GSI:
    Resizing 'system_a'    FAILED (remote: 'Not enough space to resize partition')
    fastboot: error: Command failed
Use o seguinte comando 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 sufixo _a deve corresponder ao ID do slot da partição do sistema, como system_a neste exemplo.

Contribuindo para GSIs

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 é um branch de desenvolvimento e aceita apenas cherrypicks do branch principal AOSP, portanto, para enviar um patch GSI, você deve:
    1. Envie o patch para a ramificação main do AOSP .
    2. Cherrypick o patch para DESSERT -gsi .
    3. Registre um bug para que o cherrypick seja revisado.
  • Reportando bugs GSI ou fazendo outras sugestões. Revise as instruções em Relatando bugs e, em seguida, navegue ou arquive os 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 mode pode ser threebutton , twobutton , gestural e assim por diante.