Desenvolvimento do manifesto do dispositivo

Ao desenvolver e lançar novos dispositivos, os fornecedores podem definir e declarar a versão de destino do FCM no manifesto do dispositivo (DM, na sigla em inglês). Ao fazer upgrade da imagem do fornecedor para dispositivos antigos, os fornecedores podem implementar novas versões de HAL e aumentar a versão de destino do FCM.

Desenvolver novos dispositivos

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

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

Lançar novos dispositivos

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

Por exemplo, dispositivos lançados com o Android 9 precisam ter a versão de destino do FCM igual a 3 (a versão mais recente disponível no momento). Para declarar isso no manifesto do dispositivo:

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

Fazer upgrade da imagem do fornecedor

Ao fazer upgrade da imagem do fornecedor para um dispositivo antigo, os fornecedores podem implementar novas versões de HAL e aumentar a versão de destino do FCM.

Fazer upgrade das HALs

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

• Os dispositivos Google Pixel 2 e Pixel 2 XL foram lançados com a versão de destino do FCM 2, que implementou o HAL de áudio 2.0 necessário android.hardware.audio@2.0::IDeviceFactory/default.
• Para o HAL de áudio 4.0 lançado com o Android 9, os dispositivos Google Pixel 2 e Pixel 2 XL podem usar uma OTA completa para fazer upgrade para o HAL 4.0, 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 do fornecedor com a versão 2 do FCM de destino foi flexibilizado porque o framework do Android 9 (versão 3 do FCM) considera o áudio 4.0 um substituto do HAL de áudio 2.0 em termos de funcionalidade.

Resumindo, como o compatibility_matrix.2.xml requer áudio 2.0 e o compatibility_matrix.3.xml requer áudio 4.0, os requisitos são os seguintes:

Fazer upgrade da versão de destino do FCM

Durante um upgrade de imagem do fornecedor, os fornecedores também podem incrementar a versão de destino do FCM para especificar a versão de destino com que a imagem atualizada pode trabalhar. Para aumentar a versão de destino do FCM 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 da HAL no arquivo de manifesto do dispositivo.
3. Modifique a versão de destino do FCM no arquivo de manifesto do dispositivo.
4. Remova as versões HAL descontinuadas.

Por exemplo, os dispositivos Google Pixel e Pixel XL foram lançados com o Android 7.0. Portanto, a versão de destino do FCM precisa ser pelo menos legada. No entanto, o manifesto do dispositivo declara a versão 2 do FCM como destino 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 necessárias da HAL ou não removerem as versões descontinuadas, não será possível fazer upgrade para a versão de destino do FCM.

Por exemplo, os dispositivos Google Pixel 2 e Pixel 2 XL têm como destino a versão 2 do FCM. Embora implementem algumas HALs exigidas pelo compatibility_matrix.3.xml (como áudio 4.0, integridade 2.0 etc.), eles não removem o android.hardware.radio.deprecated@1.0, que está descontinuado na versão 3 do FCM (Android 9). Portanto, esses dispositivos não podem fazer upgrade da versão de destino do FCM para 3.

Obrigação de requisitos do kernel durante a OTA

Atualizar dispositivos do Android 9 ou versões anteriores

Em dispositivos com Android 9 ou versões anteriores, verifique se as seguintes CLs foram selecionadas:

• CL 722283
• CL 722284
• CL 722345

Essas mudanças introduzem a flag de build PRODUCT_OTA_ENFORCE_VINTF_KERNEL_REQUIREMENTS e deixam a flag não definida para dispositivos lançados com o Android 9 ou versões anteriores.

• Ao atualizar para o Android 10, os clientes OTA em dispositivos com Android 9 ou versões anteriores não verificam corretamente os requisitos do kernel no pacote OTA. Essas mudanças são necessárias para remover os requisitos do kernel do pacote OTA gerado.
• Ao atualizar para o Android 11, é opcional definir a flag de build PRODUCT_OTA_ENFORCE_VINTF_KERNEL_REQUIREMENTS para verificar a compatibilidade do VINTF quando o pacote de atualização é gerado.

Para mais informações sobre essa flag de build, consulte Atualizar dispositivos do Android 10.

Atualizar dispositivos do Android 10

O Android 10 introduz uma nova flag de build, PRODUCT_OTA_ENFORCE_VINTF_KERNEL_REQUIREMENTS. Para dispositivos lançados com o Android 10, essa flag é definida automaticamente como true. Quando a flag é definida como true, um script extrai a versão do kernel e as configurações do kernel da imagem instalada.

• 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 a imagem do kernel, faça uma das seguintes ações:

• Edite o script para oferecer suporte ao formato do kernel e contribua com o AOSP.
• Defina BOARD_KERNEL_VERSION como a versão do kernel e BOARD_KERNEL_CONFIG_FILE como o caminho do arquivo de configuração do kernel criado .config. As duas variáveis precisam ser atualizadas quando a imagem do kernel é atualizada.
• Como alternativa, defina PRODUCT_OTA_ENFORCE_VINTF_KERNEL_REQUIREMENTS como false para pular a verificação dos requisitos do kernel. Isso não é recomendado porque qualquer incompatibilidade fica oculta e só é descoberta ao executar testes do VTS após a atualização.

É possível conferir o código-fonte do script de extração de informações do kernel extract_kernel.py.