Desenvolvimento de manifesto de dispositivo,Desenvolvimento de manifesto de dispositivo

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

Desenvolvimento de novos dispositivos

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

  1. Deixe DEVICE_MANIFEST_FILE e PRODUCT_ENFORCE_VINTF_MANIFEST indefinidos.
  2. Implemente HALs para a versão alvo do FCM.
  3. Escreva o arquivo de manifesto do dispositivo correto.
  4. Grave a versão alvo do FCM no arquivo de manifesto do dispositivo.
  5. Defina DEVICE_MANIFEST_FILE .
  6. Defina PRODUCT_ENFORCE_VINTF_MANIFEST como true .

Lançamento de novos dispositivos

Quando um novo dispositivo é lançado, sua versão alvo do FCM inicial 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 lançados com Android 9 devem ter a versão Target FCM 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 imagem do fornecedor

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

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 iguais. 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 HAL de áudio 4.0 lançado com Android 9, os dispositivos Google Pixel 2 e Pixel 2 XL podem usar um OTA completo para atualizar para o HAL 4.0, que implementa android.hardware.audio@4.0::IDeviceFactory/default .
  • Embora a compatibility_matrix.2.xml especifique apenas áudio 2.0, o requisito de 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 FCM (Sistema) Versão alvo 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

Atualizando a versão do Target FCM

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 funcionar. Para superar a versão Target FCM de um dispositivo, os fornecedores precisam:

  1. Implemente todas as novas versões HAL necessárias para a versão alvo 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 versões HAL obsoletas.

Por exemplo, os dispositivos Google Pixel e Pixel XL lançados com Android 7.0, portanto, sua versão Target FCM deve ser pelo menos legada. No entanto, o manifesto do dispositivo declara o Target FCM versão 2 porque a imagem do fornecedor foi atualizada para estar em conformidade compatibility_matrix.2.xml :

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

Se os fornecedores não implementarem todas as novas versões HAL necessárias ou não removerem versões HAL obsoletas, a versão alvo do FCM 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, saúde 2.0, etc.), eles não removem android.hardware.radio.deprecated@1.0 , que está obsoleto na versão 3 do FCM (Android 9). Portanto, esses dispositivos não podem atualizar a versão Target FCM para 3.

Requisitos obrigatórios do 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:

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

  • Ao atualizar para o Android 10, os clientes OTA em dispositivos que executam o Android 9 ou inferior não verificam corretamente os requisitos do kernel no pacote OTA. Essas mudanças 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 build, 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 Android 10, esse sinalizador é automaticamente definido 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 instalada.

  • 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 geração do pacote 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 a imagem do kernel, siga um destes procedimentos:

  • Edite o script para suportar o formato do seu kernel e contribuir com 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 compilado .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 extract_kernel.py .