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:
- Deixe
DEVICE_MANIFEST_FILE
ePRODUCT_ENFORCE_VINTF_MANIFEST
indefinidos. - Implemente HALs para a versão do FCM de destino.
- Grave o arquivo de manifesto do dispositivo correto.
- Grave a versão do FCM de destino no arquivo de manifesto do dispositivo.
- Defina
DEVICE_MANIFEST_FILE
. - Defina
PRODUCT_ENFORCE_VINTF_MANIFEST
comotrue
.
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:
- Implemente todas as novas versões de HAL necessárias para a versão de destino do FCM.
- Modifique as versões HAL no arquivo de manifesto do dispositivo.
- Modifique a versão do FCM de destino no arquivo de manifesto do dispositivo.
- 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 eBOARD_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
comofalse
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
.