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

Desenvolver novos dispositivos

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

  1. Sair de DEVICE_MANIFEST_FILE e PRODUCT_ENFORCE_VINTF_MANIFEST indefinido.
  2. Implemente HALs para a versão de destino do FCM.
  3. Grave o arquivo de manifesto correto do dispositivo.
  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 "target-level" nos atributos de nível superior <manifest>.

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

Fazer upgrade de HALs

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

  • Dispositivos Google Pixel 2 e Pixel 2 XL lançados com a versão de destino do FCM 2, que implementou a HAL de áudio 2.0 necessária android.hardware.audio@2.0::IDeviceFactory/default:
  • Para a HAL de áudio 4.0 lançada com o Android 9, os dispositivos Google Pixel 2 e Pixel 2 XL podem usar uma para a HAL 4.0, que implementa android.hardware.audio@4.0::IDeviceFactory/default:
  • Mesmo que o compatibility_matrix.2.xml especifique o áudio 2.0 o requisito de uma imagem de fornecedor com destino à versão 2 do FCM foi afrouxado porque o framework do Android 9 (versão do FCM) 3) considera o áudio 4.0 uma substituição da HAL de áudio 2.0 em termos de funcionalidade.

Para resumir, já que compatibility_matrix.2.xml exige áudio 2.0 e compatibility_matrix.3.xml exigem áudio 4.0, a requisitos são os seguintes:

Versão (sistema) do FCM 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

Fazer upgrade da versão de destino do FCM

Durante um upgrade de imagem do fornecedor, eles também podem incrementar o FCM de destino versão para especificar a versão de destino do FCM que a imagem atualizada do fornecedor pode funcionar com Para promover a versão de destino do FCM de um dispositivo, os fornecedores precisam:

  1. Implemente todas as novas versões necessárias da HAL 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. As versões descontinuadas da HAL foram removidas.

Por exemplo, dispositivos Google Pixel e Pixel XL lançados com o Android 7.0. portanto, a versão de destino do FCM precisa ser pelo menos legada. No entanto, o dispositivo manifesto declara a versão 2 do FCM de destino porque a imagem do fornecedor foi atualizado 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 descontinuadas, a versão de destino do FCM não poderá ser atualizada.

Por exemplo, os dispositivos Google Pixel 2 e Pixel 2 XL têm como destino a versão 2 do FCM. Apesar de implementarem algumas HALs exigidas pelos compatibility_matrix.3.xml (como áudio 4.0, Health 2.0 etc.), ele não vai remover android.hardware.radio.deprecated@1.0, que é descontinuados na versão 3 do FCM (Android 9). Portanto, os dispositivos não podem fazer upgrade da versão de destino do FCM para a 3.

Como exigir requisitos do kernel durante a OTA

Atualizar dispositivos com o Android 9 ou versões anteriores

Em dispositivos com o Android 9 ou versões anteriores, verifique se as seguintes CLs foram: escolhidos a dedo:

Essas mudanças introduzem a flag de build PRODUCT_OTA_ENFORCE_VINTF_KERNEL_REQUIREMENTS e deixe o não definido para dispositivos lançados com o Android 9 ou mais baixo.

  • Ao atualizar para o Android 10, 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 eliminar os requisitos do kernel do OTA gerado .
  • Ao atualizar para o Android 11, é opcional definir o Sinalização de build PRODUCT_OTA_ENFORCE_VINTF_KERNEL_REQUIREMENTS para verificar o VINTF quando o pacote de atualização é gerado.

Para saber mais sobre esse flag de build, consulte Atualizar dispositivos Android 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çado com o Android 10, essa flag será definido automaticamente como true. Quando a flag é definida como true, um script extrai a versão e o kernel do kernel da imagem do kernel instalada.

  • Ao atualizar para o Android 10, o pacote de atualização OTA contém versão e configuração do kernel. Clientes OTA em dispositivos com Android 10 leiam estas informações para verificar compatibilidade.
  • Ao atualizar para o Android 11, a gênero de pacotes OTA lê a versão e a configuração do kernel para verificar a compatibilidade;

Se o script não extrair essas informações para a imagem do kernel, execute uma das o seguinte:

  • Edite o script para oferecer suporte ao formato de kernel e contribuir para o AOSP.
  • Defina BOARD_KERNEL_VERSION como a versão do kernel. e BOARD_KERNEL_CONFIG_FILE para o caminho do kernel criado. arquivo de configuração .config. As duas variáveis precisam 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.

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