Desenvolvimento do manifesto do dispositivo

Mantenha tudo organizado com as coleções Salve e categorize o conteúdo com base nas suas preferências.

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 fazer upgrade da imagem do fornecedor para dispositivos antigos, os fornecedores podem implementar novas versões do HAL e incrementar a versão do FCM de destino.

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

Lançar novos dispositivos

Quando um novo dispositivo é lançado, a 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 lançados com o Android 9 precisam ter a versão do FCM de destino 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 atualizar a imagem do fornecedor para um dispositivo antigo, os fornecedores podem implementar novas versões do HAL e incrementar a versão de destino do FCM.

Fazer upgrade de HALs

Durante um upgrade 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:

• Os dispositivos Google Pixel 2 e Pixel 2 XL foram lançados com a versão 2 do FCM alvo, que implementou o HAL de áudio 2.0 android.hardware.audio@2.0::IDeviceFactory/default necessário.
• 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 o áudio 2.0, o requisito em uma imagem do fornecedor com a versão 2 do FCM foi afrouxado porque o framework do Android 9 (versão 3 do FCM) considera o áudio 4.0 como uma substituição do HAL do áudio 2.0 em termos de funcionalidade.

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

Fazer upgrade da versão do FCM de destino

Durante um upgrade 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 que a imagem do fornecedor atualizada pode funcionar. Para atualizar a versão do FCM de destino de um dispositivo, os fornecedores precisam:

1. Implemente todas as novas versões do HAL necessárias para a versão de destino do FCM.
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. As versões descontinuadas do HAL foram removidas.

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

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

Obrigatoriedade de requisitos do kernel durante o OTA

Atualizar dispositivos do Android 9 ou versões anteriores

Em dispositivos com o 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 não a definem para dispositivos lançados com o Android 9 ou versões anteriores.

• Ao atualizar para o Android 10, clientes OTA em dispositivos com Android 9 ou versões anteriores não verificam os requisitos do kernel no pacote OTA corretamente. 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 for gerado.

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

Como 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 o 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 uma das seguintes ações:

• Edite o script para oferecer suporte ao formato do kernel e contribuir para 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 gerado .config. Ambas as 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 de VTS após a atualização.

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