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 executando Android 9 ou superior pode ser executado com êxito.

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 depois 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 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 dispositivo de destino e, em seguida , atualize o GSI para um dispositivo Android.

Configuração e variações do GSI

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

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

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

Metas GSI para testes de conformidade Treble

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

Tipo de dispositivo Criar alvo
Dispositivos lançados com Android 12 gsi_$arch-user (assinado)
Dispositivos lançados com 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 Criando GSIs ).

Mudanças 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 mudanças importantes em relação aos GSIs anteriores:

  • Nome do destino. 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.
  • O GSI legado foi 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.
  • Política 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.

Mudanças no GSI do Android 11

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

  • conteúdo 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 .
  • APEX. 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 Configuração do sistema para suportar atualizações do APEX para obter detalhes.

Mudanças 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 mudanças importantes em relação aos GSIs anteriores:

  • Construção do usuário. O GSI tem compilação do usuário a partir do Android 10. No Android 10, o GSI da compilação do usuário pode ser usado em testes de conformidade CTS-on-GSI/VTS. Consulte Teste VTS com Debug Ramdisk para obter detalhes.
  • Formato não esparso. GSI com destinos aosp_$arch são construídos com formato não analisado. Você pode usar img2simg para converter um GSI não esparso em formato esparso, se necessário.
  • Sistema como root. O destino de construção legado do GSI denominado 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 no 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 verificação de inicialização.

Mudanças no GSI do Android 9

Os dispositivos lançados ou atualizados para o Android 9 devem usar GSIs do Android 9 para testes de conformidade. Isso inclui as seguintes mudanças importantes em relação aos GSIs anteriores:

  • Mescla GSI e emulador. Os GSIs são construídos a partir de imagens de 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 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 oferece suporte à interface do binder de 32 bits, portanto, tanto os GSIs de 32 bits quanto os 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 do sistema compatível. O Android 9 permite a verificação de acesso para uma propriedade de sistema compatível ( PRODUCT_COMPATIBLE_PROPERTY_OVERRIDE := true ).

Mudanças no Keymaster do Android 9

Nas versões anteriores do Android, os dispositivos que implementavam o Keymaster 3 ou inferior eram obrigados a 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 normalmente eram obtidas no cabeçalho da imagem de inicialização.

No Android 9 e versões posteriores, esse requisito mudou 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 gerenciador 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 .

Baixar 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 como criar GSIs para destinos específicos.

Crie 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 filiais 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 correta do GSI para o 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 do GSI gsi_arm64-userdebug na ramificação do 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 GSI são para dispositivos lançados no Android 9 ou superior.

Nome do GSI Arco da CPU Bitness da interface do fichário Sistema como raiz Criar alvo
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 atualizar GSIs

Os dispositivos Android podem ter designs diferentes, portanto, não existe um comando genérico ou um conjunto de instruções para atualizar um GSI que se aplique a todos os dispositivos. Consulte o fabricante do dispositivo Android para obter instruções explícitas sobre flash. Use as seguintes etapas como orientação geral:

  1. Certifique-se de que o dispositivo tenha o seguinte:
    • Treblisado
    • Um método para desbloquear dispositivos (para que possam ser atualizados usando fastboot )
    • Um estado desbloqueado para torná-lo flash 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 atual do sistema 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. Reinicializar:
    $ fastboot reboot
Em dispositivos Android 10 ou mais recentes que possuem 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.

Contribua para GSIs

O Android agradece suas contribuições para o desenvolvimento do 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 seleções do branch principal AOSP, portanto, para enviar um patch GSI, você deve:
    1. Envie o patch para o branch main do AOSP .
    2. Escolha o patch para DESSERT -gsi .
    3. Registre um bug para que o cherrypick seja revisado.
  • Relatar bugs do GSI ou fazer outras sugestões. Revise as instruções em Relatando bugs e procure ou registre bugs de GSI .

Pontas

Altere 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.