O Google tem o compromisso de promover a igualdade racial para as comunidades negras. Saiba como.

Desenvolvimento de Manifesto de Dispositivo

Ao desenvolver e lançar novos dispositivos, os fornecedores podem definir e declarar a versão do FCM de destino no manifesto do dispositivo (DM). Ao atualizar a imagem do fornecedor para dispositivos antigos, os fornecedores podem escolher implementar novas versões de HAL e incrementar a versão do FCM de destino.

Desenvolvendo novos dispositivos

Ao definir a versão do FCM de destino do dispositivo para novos dispositivos:

  1. Deixe DEVICE_MANIFEST_FILE e PRODUCT_ENFORCE_VINTF_MANIFEST indefinido.
  2. Implemente HALs para a versão do FCM de destino.
  3. Grave o arquivo de manifesto do dispositivo correto.
  4. Grave a versão do FCM de destino no arquivo de manifesto do dispositivo.
  5. Set DEVICE_MANIFEST_FILE .
  6. Set PRODUCT_ENFORCE_VINTF_MANIFEST a true .

Lançamento de novos dispositivos

Quando um novo dispositivo é liberado, o seu alvo inicial FCM Versão precisa ser determinada e declarada no manifesto de dispositivo como o " target-level atributo" na de nível superior <manifest> elemento.

Por exemplo, os dispositivos lançados com o Android 9 devem ter a versão do FCM alvo igual a 3 (a versão superior disponível no momento). Para declarar isso no manifesto do dispositivo:

<manifest version="1.0" type="device" target-level="3">
    <!-- ... -->
</manifest>

Atualizando a imagem do fornecedor

Ao atualizar a imagem do fornecedor para um dispositivo antigo, os fornecedores podem escolher implementar novas versões de HAL e incrementar a versão do FCM de destino.

Atualizando HALs

Durante uma atualização de imagem do fornecedor, os fornecedores podem implementar novas versões do HAL, desde que o nome do HAL, o nome da interface e o nome da instância sejam os mesmos. Por exemplo:

  • Google Pixel 2 e Pixel 2 XL dispositivos lançados com a Target FCM Versão 2, que implementou o necessário áudio 2.0 HAL android.hardware.audio@2.0::IDeviceFactory/default .
  • Para o áudio HAL 4.0 que lançado com Android 9, Google Pixel 2 e dispositivos Pixel 2 XL pode usar um OTA completa para atualizar para o HAL 4.0, que implementa android.hardware.audio@4.0::IDeviceFactory/default .
  • Mesmo que o compatibility_matrix.2.xml especifica áudio 2.0 só, a exigência na imagem um fornecedor com a Target FCM versão 2 foi afrouxado porque o quadro Android 9 (FCM Versão 3) considera áudio 4.0 a substituição de áudio 2.0 HAL em termos de funcionalidade .

Para resumir, dado que compatibility_matrix.2.xml requer áudio 2.0 e compatibility_matrix.3.xml requer áudio 4.0, os requisitos são os seguintes:

Versão FCM (sistema) Versão do FCM de destino (fornecedor) Requisitos
2 (8,1) 2 (8,1) Audio 2.0
3 (9) 2 (8,1) Áudio 2.0 ou 4.0
3 (9) 3 (9) Áudio 4.0

Atualizando a versão do FCM de destino

Durante uma atualização de imagem do fornecedor, os fornecedores também podem incrementar a versão do FCM de destino para especificar a versão do FCM de destino com a qual a imagem do fornecedor pode trabalhar. Para aumentar a versão do FCM de destino de um dispositivo, os fornecedores precisam:

  1. Implemente todas as novas versões de HAL necessárias para a versão do FCM de destino.
  2. Modifique as versões do HAL no arquivo de manifesto do dispositivo.
  3. Modifique a versão do FCM de destino no arquivo de manifesto do dispositivo.
  4. Remova as versões obsoletas do HAL.

Por exemplo, dispositivos Google Pixel e Pixel XL lançados com Android 7.0, portanto, sua versão do FCM de destino deve ser pelo menos legada. No entanto, o manifesto de dispositivo declara o alvo FCM Versão 2 porque a imagem fornecedor foi atualizado para se conformar com compatibility_matrix.2.xml :

<manifest version="1.0" type="device" target-level="2">

Se os fornecedores não implementarem todas as novas versões do HAL necessárias ou não removerem as versões obsoletas do HAL, a versão do FCM de destino não poderá ser atualizada.

Por exemplo, o Google Pixel 2 e Pixel 2 XL dispositivos têm Alvo FCM Versão 2. Enquanto eles fazem implementar algumas HALs exigidos pela compatibility_matrix.3.xml (tais como áudio 4.0, saúde 2.0, etc.), eles não retire android.hardware.radio.deprecated@1.0 , que está obsoleto no FCM Versão 3 (Android 9). Portanto, esses dispositivos não podem atualizar a versão do FCM de destino para 3.

Requisitos obrigatórios de kernel durante OTA

Atualizando dispositivos do Android 9 ou inferior

Em dispositivos com Android 9 ou inferior, certifique-se de que os seguintes CLs sejam escolhidos a dedo:

Estas alterações introduzem a bandeira de construção PRODUCT_OTA_ENFORCE_VINTF_KERNEL_REQUIREMENTS e deixar o unset bandeira para dispositivos lançados com o Android 9 ou diminuir.

  • Ao atualizar para o Android 10, os clientes OTA em dispositivos que executam o Android 9 ou inferior não verificam os requisitos do kernel no pacote OTA corretamente. Essas mudanças são necessárias para eliminar os requisitos de kernel do pacote OTA gerado.
  • Ao atualizar para o Android 11, é opcional para definir o PRODUCT_OTA_ENFORCE_VINTF_KERNEL_REQUIREMENTS bandeira de construção para verificar a compatibilidade VINTF quando o pacote de atualização é gerado.

Para mais informações sobre esta bandeira de construção, consulte Atualizando dispositivos do Android 10 .

Atualizando dispositivos do Android 10

Android 10 introduz uma nova bandeira construção, PRODUCT_OTA_ENFORCE_VINTF_KERNEL_REQUIREMENTS . Para dispositivos lançados com o Android 10, esta bandeira é automaticamente definida para true . Quando a bandeira está definido como true , um script extrai a versão do kernel e as configurações de kernel da imagem do kernel instalado.

  • Ao atualizar para o Android 10, o pacote de atualização OTA contém a versão e configuração do kernel. Os clientes OTA em dispositivos com Android 10 leem essas informações para verificar a compatibilidade.
  • Ao atualizar para o Android 11, a criação do pacote OTA lê a versão e a configuração do kernel para verificar a compatibilidade.

Se o script não consegue extrair essa informação para sua imagem do kernel, execute um dos seguintes procedimentos:

  • Edite o script para oferecer suporte ao formato do kernel e contribuir para o AOSP.
  • Set BOARD_KERNEL_VERSION para a versão do kernel e BOARD_KERNEL_CONFIG_FILE ao caminho do kernel construído arquivo de configuração .config . Ambas as variáveis ​​devem ser atualizadas quando a imagem do kernel é atualizada.
  • Como alternativa, defina PRODUCT_OTA_ENFORCE_VINTF_KERNEL_REQUIREMENTS a false para pular a verificação dos requisitos do kernel. Isso não é recomendado porque qualquer incompatibilidade fica oculta e só é descoberta durante a execução de testes VTS após a atualização.

Você pode ver o código fonte da informação do kernel roteiro extração extract_kernel.py .