Uma versão do framework do Android tem várias matrizes de compatibilidade de framework (FCMs, na sigla em inglês), uma para cada versão do FCM de destino atualizável, que definem o que o framework pode usar e os requisitos da versão do FCM de destino. Como parte do ciclo de vida do FCM, o Android descontinua o uso e remove as HALs HIDL, depois modifica os arquivos do FCM para refletir o status da versão da HAL.
Para ativar OTAs somente de framework nos próprios ecossistemas, os parceiros que estendem as interfaces do fornecedor também precisam descontinuar e remover HALs HIDL usando os mesmos métodos.
Terminologia
- Matriz de compatibilidade de framework (FCM)
- Um arquivo XML que especifica os requisitos do framework em implementações de fornecedores em conformidade. A matriz de compatibilidade é versionada, e uma nova versão é congelada para cada versão do framework. Cada versão do framework contém várias FCMs.
- Versões da plataforma FCM (SF)
- O conjunto de todas as versões do FCM em uma versão do framework. O framework pode funcionar com qualquer implementação de fornecedor que atenda a um desses FCMs.
- Versão do FCM (F)
- A versão mais recente entre todas as FCMs em uma versão do framework.
- Versão do FCM desejada (V)
- A versão do FCM de destino (do SF), declarada explicitamente no manifesto do dispositivo, que uma implementação do fornecedor atende. Uma implementação do fornecedor precisa ser gerada em relação a um FCM publicado, embora possa declarar versões mais recentes do HAL no manifesto do dispositivo.
- Versão HAL
- Uma versão HAL tem o formato
foo@x.y
, em quefoo
é o nome HAL ex.y
é a versão específica. Por exemplo,nfc@1.0
,keymaster@3.0
(o prefixo raiz, por exemplo,android.hardware
, é omitido em todo este documento). - Manifesto do dispositivo
- Arquivos XML que especificam quais versões do HAL o lado do dispositivo da interface do fornecedor, incluindo as imagens do fornecedor e do ODM, fornece. O conteúdo de um manifesto de dispositivo é restringido pela versão do FCM de destino do dispositivo, mas pode listar HALs estritamente mais recentes em relação ao FC correspondente a V.
- HALs do dispositivo
- HALs listadas (fornecidas) no manifesto do dispositivo e listadas na matriz de compatibilidade do framework (FCM).
- Matriz de compatibilidade de dispositivos (DCM)
- Um arquivo XML que especifica os requisitos do fornecedor em implementações de framework em conformidade. Cada dispositivo contém um DCM.
- Manifesto do framework
- Um arquivo XML que especifica quais versões do HAL o lado do framework da interface do fornecedor, incluindo system, system_ext e imagens do produto, fornece. Os HALs no manifesto do framework são desativados dinamicamente de acordo com a versão do FCM de destino do dispositivo.
- HALs de framework HALs
- listados como fornecidos no manifesto do framework e listados na matriz de compatibilidade de dispositivos (DCM).
Ciclo de vida do FCM na base de código
Este documento descreve o ciclo de vida do FCM no resumo. Para conferir os
manifestos com suporte, consulte
hardware/interfaces/compatibility_matrix.<FCM>.xml
,
onde o FCM pode ser encontrado em
system/libvintf/include/vintf/Level.h
.
Espera-se que um dispositivo que envie a versão do lançamento do Android correspondente tenha um valor do FCM maior ou igual ao nível equivalente. Por exemplo, um dispositivo enviado com o Android 11 geralmente tem o nível 5 do FCM, mas implementa o nível 6 ou mais recente, que vem com vários requisitos adicionais especificados nas matrizes de compatibilidade. Os níveis aceitos são:
FCM | Versão do Android |
---|---|
4 | Android 10/Q |
5 | Android 11/R |
6 | Android 12/S |
7 | Android 13/T |
8 | Android 14/U |
202404 | Android 15/V |
O nível do FCM é igual ou mais recente do que o nível da API do fornecedor.
Quando o Android descontinua um nível do FCM, ele ainda é aceito para dispositivos atuais. Os dispositivos com níveis mais baixos do FCM podem usar implicitamente HALs listados em níveis mais recentes do FCM, desde que estejam disponíveis no branch.
Desenvolver em uma nova versão do FCM
O Android incrementa a versão do FCM para cada versão do framework, como o Android
8 e 8.1. Durante o desenvolvimento, o novo compatibility_matrix.F.xml
é
criado, e o compatibility_matrix.f.xml
atual (onde f
< F
) não
é mais alterado.
Para começar a desenvolver em uma nova versão F
do FCM:
- Copie o
compatibility_matrix.<F-1>.xml
mais recente paracompatibility_matrix.F.xml
. - Atualize o atributo
level
no arquivo paraF
. - Adicione as regras de build correspondentes para instalar essa matriz de compatibilidade no dispositivo.
Apresentação de um novo HAL
Durante o desenvolvimento, ao introduzir uma nova HAL (Wi-Fi, NFC etc.) no Android
na versão atual do FCM F
, adicione a HAL a compatibility_matrix.F.xml
.
Por exemplo, o Android 8.1 introduziu cas@1.0
. Os dispositivos lançados com o Android
8.1 podem implementar essa HAL. Portanto, a seguinte entrada foi adicionada a
compatibility_matrix.F.xml
, que era chamada de
compatibility_matrix.current.xml
temporariamente durante o desenvolvimento dessa
versão:
<hal format="hidl">
<name>android.hardware.cas</name>
<version>1.0</version>
<interface>
<name>IMediaCasService</name>
<instance>default</instance>
</interface>
</hal>
Fazer upgrade de uma HAL (secundária)
As versões da HAL do AIDL são contadas como versões secundárias da HAL. As versões da interface HIDL têm
versões major.minor
, como 1.2
.
Durante o desenvolvimento, quando uma HAL AIDL tem um upgrade de versão de 2
para
3
na versão atual do FCM F
, a nova versão é adicionada à entrada HAL
em compatibility_matrix.F.xml
. O campo de versão de uma entrada HAL aceita
intervalos como 2-3
.
Por exemplo, o Android FCM F
introduziu foo@3
como uma versão secundária
da HAL. A versão mais antiga, foo@2
, é usada para
dispositivos com FCMs mais antigos, enquanto a versão mais recente,
foo@3
, pode ser usada para dispositivos com FCM do Android F
. A entrada nas
FCMs mais antigas antes da versão 2
é semelhante a esta:
<hal format="aidl">
<name>foo</name>
<version>2</version>
<interface>
<name>IFoo</name>
<instance>default</instance>
</interface>
</hal>
Essa entrada foi copiada para compatibility_matrix.F.xml
e modificada para oferecer suporte à
versão 3
da seguinte maneira:
<hal format="aidl">
<name>foo</name>
<version>2-3</version>
<interface>
<name>IFoo</name>
<instance>default</instance>
</interface>
</hal>
Fazer upgrade de uma HAL (principal)
Durante o desenvolvimento, quando uma HAL tem um upgrade de versão principal na versão atual do
FCM F
, a nova versão principal x.0
é adicionada a
compatibility_matrix.F.xml
com as seguintes configurações:
- Somente a versão
x.0
, se os dispositivos que vêm comV = F
precisam ser iniciados comx.0
. - Com versões principais mais antigas na mesma tag
<hal>
, se os dispositivos enviados comV = F
puderem ser iniciados com uma versão principal mais antiga.
Por exemplo, a versão F
do FCM introduz foo@2.0
como uma
atualização de versão principal da HAL 1.0 e descontinua o uso da HAL 1.0. A versão
mais antiga, foo@1.0
, é usada para dispositivos com versões anteriores do FCM. Os dispositivos
que segmentam a versão F
do FCM precisam fornecer a nova versão 2.0 se fornecerem o
HAL. Neste exemplo, as versões anteriores do FCM contêm esta entrada:
<hal format="hidl">
<name>foo</name>
<version>1.0</version>;
<interface>
<name>IFoo</name>
<instance>default</instance>
</interface>
</hal>
Copie essa entrada para compatibility_matrix.F.xml
e modifique da seguinte
forma:
<hal format="hidl">
<name>foo</name>
<version>2.0</version>
<interface>
<name>IFoo</name>
<instance>default</instance>
</interface>
</hal>
Restrições:
- Como o HAL 1.0 não está em
compatibility_matrix.F.xml
, os dispositivos que têm como destino a versãoF
do FCM não podem fornecer o HAL 1.0, já que ele é considerado descontinuado. - Como o HAL 1.0 está presente em versões mais antigas do FCM, o framework ainda pode funcionar com o HAL 1.0 para que ele seja compatível com versões mais antigas do FCM.
Novas versões do FCM
O processo de lançamento de uma versão do FCM na partição do sistema é feito exclusivamente pelo Google como parte de uma versão do AOSP e inclui as seguintes etapas:
- Verifique se o
compatibility_matrix.F.xml
tem o atributolevel="F"
. - Verifique se todos os dispositivos são criados e inicializados.
- Atualização dos testes do VTS
para garantir que os dispositivos iniciados com a estrutura mais recente (com base
no nível da API de envio) tenham a versão do FCM de destino
V >= F
. - Publicar o arquivo no AOSP.
Por exemplo, os testes VTS garantem que os dispositivos lançados com o Android 9 tenham a versão do FCM de destino >= 3.
Além disso, os FCMs do produto e do system_ext também podem listar os requisitos de cada versão do FCM da plataforma. O lançamento de versões do FCM nas partições do produto e do system_ext é feito pelo proprietário dessas imagens, respectivamente. Os números de versão do FCM nas partições do produto e system_ext precisam estar alinhados com os da partição do sistema. Assim como as versões do FCM na partição do sistema, a matriz de compatibilidade na versão F do FCM nas partições do produto e do system_ext reflete os requisitos em um dispositivo com a versão F do FCM de destino.
Descontinuação da versão da HAL
A descontinuação de uma versão do HAL é uma decisão do desenvolvedor. Ou seja, para HALs do AOSP, o Google toma a decisão. Isso pode acontecer quando uma versão mais recente do HAL (menor ou principal) é lançada.
Desativar um HAL de dispositivo
Quando um determinado HAL foo@x.y
do dispositivo é descontinuado na versão F
do FCM, isso significa
que qualquer dispositivo iniciado com a versão de destino V = F
ou mais recente do FCM não pode
implementar foo
na versão x.y
ou qualquer versão anterior à x.y
. Uma versão descontinuada
do HAL ainda tem suporte do framework para upgrade de dispositivos.
Quando a versão F
do FCM for lançada, uma versão foo@x.y
do HAL será considerada
descontinuada se a versão específica do HAL não for explicitamente declarada na
versão mais recente do FCM para a versão de destino V = F
. Para dispositivos iniciados com V = F
, uma das
seguintes condições é verdadeira:
- O framework exige uma versão mais recente (principal ou secundária).
- O framework não precisa mais da HAL.
Por exemplo, no Android 9, health@2.0
é introduzido
como uma atualização importante da versão da HAL 1.0. health@1.0
foi removido de
compatibility_matrix.3.xml
, mas está presente em
compatibility_matrix.legacy.xml
,
compatibility_matrix.1.xml
e compatibility_matrix.2.xml.
Portanto, health@1.0
é considerado descontinuado.
Desativar um HAL de framework
Quando um determinado framework HAL foo@x.y
é descontinuado na versão F
do FCM, isso significa
que qualquer dispositivo lançado com a versão de destino V = F
ou mais recente do FCM não pode
esperar que o framework forneça foo
na versão x.y
ou em qualquer versão mais antiga
do que x.y
. Uma versão descontinuada do HAL ainda é fornecida pelo framework para
atualização de dispositivos.
Quando a versão F
do FCM é lançada, uma versão foo@x.y
da HAL é considerada
descontinuada se o manifesto do framework especificar
max-level="F - 1"
para foo@x.y
. Para dispositivos iniciados
com V = F
, o framework não fornece o HAL foo@x.y
. A matriz de compatibilidade
do dispositivo em dispositivos lançados com V = F
não pode listar HALs
de framework com max-level < V
.
Por exemplo, no Android 12, schedulerservice@1.0
foi
descontinuado. O atributo max-level
é definido como 5
, a versão do FCM introduzida
no Android 11. Consulte
Manifesto do framework
do Android 12.
Remoção do suporte para versões de destino do FCM
Quando os dispositivos ativos de uma determinada versão do FCM de destino V
ficam abaixo de um determinado
limite, a versão do FCM de destino é removida do conjunto SF da
próxima versão do framework. Isso é feito seguindo estas etapas:
A remoção de
compatibility_matrix.V.xml
das regras de build para que ele não seja instalado na imagem do sistema e a exclusão de qualquer código que tenha implementado ou dependido dos recursos removidos.Removemos as HALs do framework com
max-level
menor ou igual aV
do manifesto do framework e excluímos qualquer código que implemente as HALs do framework removidas.
Os dispositivos com uma versão do FCM de destino fora do SF para uma determinada versão do framework não podem ser atualizados para essa versão.
Status da versão do HAL
As seções a seguir descrevem (em ordem cronológica) os estados possíveis de uma versão do HAL.
Inéditos
Para HALs de dispositivo, se uma versão de HAL não estiver em nenhuma das matrizes de compatibilidade
públicas e congeladas, ela será considerada não lançada e possivelmente em desenvolvimento.
Isso inclui versões do HAL que estão apenas na compatibility_matrix.F.xml
.
Exemplos:
- Durante o desenvolvimento do Android 9, a
HAL
health@2.0
foi considerada uma HAL não lançada e estava presente apenas emcompatibility_matrix.3.xml
. - A HAL
teleportation@1.0
não está em nenhuma matriz de compatibilidade lançada e também é considerada uma HAL não lançada.
Para HALs de framework, se uma versão do HAL estiver apenas no manifesto do framework de uma ramificação de desenvolvimento não relacionada, ela será considerada não lançada.
Lançado e atual
Para HALs de dispositivo, se uma versão da HAL estiver em qualquer matriz de compatibilidade pública
e congelada, ela será lançada. Por exemplo, depois que a versão 3 do FCM é congelada e publicada
no AOSP, a HAL health@2.0
é considerada uma versão HAL lançada e atual.
Se uma versão do HAL estiver em uma matriz de compatibilidade pública e congelada que tenha a
versão mais recente do FCM, a versão do HAL será atual (ou seja, não descontinuada). Por
exemplo, as versões do HAL atuais (como nfc@1.0
introduzidas em
compatibility_matrix.legacy.xml
)
que continuam existindo em compatibility_matrix.3.xml
também são consideradas
versões do HAL lançadas e atuais.
Para HALs de framework, se uma versão da HAL estiver no manifesto do framework
da versão mais recente lançada sem o atributo max-level
ou (incomum) um
max-level
igual ou superior à versão do FCM lançada nessa ramificação, ela
será considerada uma versão HAL lançada e atual. Por exemplo, a
HAL displayservice
foi lançada e atualizada no Android
12, conforme especificado pelo
manifesto do framework
do Android 12.
Lançada, mas descontinuada
Para HALs de dispositivo, uma versão do HAL será descontinuada somente se todas as condições abaixo forem atendidas:
- Ele é lançado.
- Ela não está na matriz de compatibilidade pública e congelada que tem a versão FCM mais alta.
- Ele está em uma matriz de compatibilidade pública e congelada com suporte do framework.
Exemplos:
- O HAL
health@1.0
está emcompatibility_matrix.legacy.xml
,compatibility_matrix.1.xml
ecompatibility_matrix.2.xml
, mas não emcompatibility_matrix.3.xml
. Por isso, ele é considerado descontinuado no Android 9. - A HAL de energia tem uma atualização de versão secundária no Android
9, mas
power@1.0
ainda está emcompatibility_matrix.3.xml
. power@1.0
compatibility_matrix.legacy.xml
,compatibility_matrix.1.xml
ecompatibility_matrix.2.xml
.compatibility_matrix.3.xml
tempower@1.0-1
.
Portanto, power@1.0
é atual, mas NÃO foi descontinuado no Android
9.
Para HALs de framework, se uma versão da HAL estiver no manifesto do framework da ramificação
mais recente com um atributo max-level
inferior à versão do lançamento do FCM
nesta ramificação, ela será considerada uma versão da HAL lançada, mas descontinuada. Por
exemplo, a HAL schedulerservice
foi lançada, mas foi descontinuada no
Android 12, conforme especificado pelo
manifesto do framework do Android 12.
Vídeo removido
Para HALs de dispositivo, uma versão HAL é removida somente se as seguintes condições forem verdadeiras:
- Ele foi lançado anteriormente.
- Ele não está em nenhuma matriz de compatibilidade pública e congelada com suporte do framework.
Matrizes de compatibilidade que são públicas, congeladas, mas não têm suporte do framework são mantidas na base de código para definir o conjunto de versões HAL removidas, para que os testes do VTS possam ser escritos e garantir que as HALs removidas não estejam em novos dispositivos.
Para HALs de framework, uma versão HAL será removida somente se as seguintes condições forem atendidas:
- Ele foi lançado anteriormente.
- Ele não está em nenhum manifesto de framework da ramificação lançada mais recentemente.
FCMs legados
A versão legada do FCM é um valor especial para todos os dispositivos que não são do sistema treble. O
FCM legado, compatibility_matrix.legacy.xml
, lista os requisitos
do framework em dispositivos legados (ou seja, dispositivos lançados antes do Android 8.0).
Se esse arquivo existir para um FCM com a versão F
, qualquer dispositivo que não seja do Treble poderá ser
atualizado para F
, desde que o manifesto do dispositivo seja compatível com esse arquivo. A
remoção segue o mesmo procedimento dos FCMs para outras versões do FCM de destino
(removidas depois que o número de dispositivos ativos anteriores à versão 8.0 cai abaixo de um determinado
limite).
Versões do FCM lançadas
A lista de versões lançadas do FCM pode ser encontrada em
hardware/interfaces/compatibility_matrices
.
Para encontrar a versão do FCM lançada com uma versão específica do Android, consulte
Level.h
.