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 optar por implementar novas versões de HAL e incrementar a versão do FCM de destino.

Desenvolvimento de 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 indefinidos.
  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. Defina DEVICE_MANIFEST_FILE .
  6. Defina PRODUCT_ENFORCE_VINTF_MANIFEST como true .

Liberando novos dispositivos

Quando um novo dispositivo é lançado, sua versão inicial do FCM de destino precisa ser determinada e declarada no manifesto do dispositivo como o atributo " target-level " no elemento <manifest> de nível superior.

Por exemplo, os dispositivos iniciados com o Android 9 devem ter Target FCM Version 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>

Fazendo upgrade da imagem do fornecedor

Ao atualizar a imagem do fornecedor para um dispositivo antigo, os fornecedores podem optar por 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 de HAL, desde que o nome HAL, o nome da interface e o nome da instância sejam os mesmos. Por exemplo:

  • Dispositivos Google Pixel 2 e Pixel 2 XL lançados com Target FCM Versão 2, que implementou o áudio 2.0 HAL necessário android.hardware.audio@2.0::IDeviceFactory/default .
  • Para o áudio 4.0 HAL lançado com o Android 9, os dispositivos Google Pixel 2 e Pixel 2 XL podem usar um OTA completo para atualizar para o 4.0 HAL, que implementa android.hardware.audio@4.0::IDeviceFactory/default .
  • Embora o compatibility_matrix.2.xml especifique apenas áudio 2.0, o requisito em uma imagem de fornecedor com Target FCM versão 2 foi afrouxado porque a estrutura do Android 9 (FCM versão 3) considera o áudio 4.0 uma substituição do á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 do FCM (Sistema) Versão de destino do FCM (fornecedor) Requisitos
2 (8,1) 2 (8,1) Áudio 2.0
3 (9) 2 (8,1) Áudio 2.0 ou 4.0
3 (9) 3 (9) Áudio 4.0

Fazendo upgrade da 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 atualizada 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 de destino do FCM.
  2. Modifique as versões 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 de HAL obsoletas.

Por exemplo, os dispositivos Google Pixel e Pixel XL lançados com o Android 7.0, portanto, a versão do FCM de destino deve ser pelo menos herdada. No entanto, o manifesto do dispositivo declara o Target FCM Versão 2 porque a imagem do fornecedor foi atualizada para estar em conformidade 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 de HAL necessárias ou não removerem as versões de HAL obsoletas, a versão do FCM de destino não poderá ser atualizada.

Por exemplo, os dispositivos Google Pixel 2 e Pixel 2 XL têm Target FCM versão 2. Embora implementem alguns HALs exigidos por compatibility_matrix.3.xml (como áudio 4.0, health 2.0 etc.), eles não removem android.hardware.radio.deprecated@1.0 , que está obsoleto no FCM versão 3 (Android 9). Portanto, esses dispositivos não podem atualizar o Target FCM Version para 3.

Requisitos obrigatórios do kernel durante o OTA

Atualizando dispositivos do Android 9 ou inferior

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

Essas alterações introduzem o sinalizador de compilação PRODUCT_OTA_ENFORCE_VINTF_KERNEL_REQUIREMENTS e deixam o sinalizador indefinido para dispositivos lançados com Android 9 ou inferior.

  • Ao atualizar para o Android 10, os clientes OTA em dispositivos com Android 9 ou inferior não verificam corretamente os requisitos do kernel no pacote OTA. Essas alterações são necessárias para eliminar os requisitos do kernel do pacote OTA gerado.
  • Ao atualizar para o Android 11, é opcional definir o sinalizador de compilação PRODUCT_OTA_ENFORCE_VINTF_KERNEL_REQUIREMENTS para verificar a compatibilidade do VINTF quando o pacote de atualização for gerado.

Para obter mais informações sobre esse sinalizador de compilação, consulte Atualizando dispositivos do Android 10 .

Atualizando dispositivos do Android 10

O Android 10 apresenta um novo sinalizador de compilação, PRODUCT_OTA_ENFORCE_VINTF_KERNEL_REQUIREMENTS . Para dispositivos lançados com o Android 10, esse sinalizador é definido automaticamente como true . Quando o sinalizador é definido como true , um script extrai a versão do kernel e as configurações do kernel da imagem do kernel instalado.

  • Ao atualizar para o Android 10, o pacote de atualização OTA contém a versão e a 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 geração de pacotes OTA lê a versão e a configuração do kernel para verificar a compatibilidade.

Se o script não conseguir extrair essas informações para sua imagem do kernel, faça o seguinte:

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

Você pode visualizar o código-fonte do script de extração de informações do kernel extract_kernel.py .