Uma versão do framework do Android tem várias Matrizes de compatibilidade de framework (FCM, na sigla em inglês), uma para cada versão atualizável do FCM, 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 e remove HALs de HIDL e 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 ampliam interfaces do fornecedor também precisam descontinuar e remover as HALs de HIDL usando os mesmos métodos.
Terminologia
- Matriz de compatibilidade de framework (FCM, na sigla em inglês)
- Um arquivo XML que especifica os requisitos do framework em implementações de fornecedores em conformidade. A matriz de compatibilidade é controlada por versão, e uma nova versão é congelada para cada versão do framework. Cada versão do framework contém vários FCMs.
- Versões do FCM da plataforma (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 alta entre todos os FCMs em uma versão de framework.
- Versão de destino do FCM (V)
- A versão do FCM de destino (de SF), declarada explicitamente no manifesto do dispositivo, que a implementação do fornecedor cumpre. Uma implementação de fornecedor precisa ser gerada em um FCM publicado, embora possa declarar versões mais recentes da HAL no manifesto do dispositivo.
- Versão do HAL
- Uma versão da HAL tem o formato
foo@x.y
, em quefoo
é o nome da HAL ex.y
é a versão específica. Por exemplo,nfc@1.0
,keymaster@3.0
(o prefixo raiz, por exemplo,android.hardware
, foi omitido em todo este documento). - Manifesto do dispositivo
- Arquivos XML que especificam quais versões de HAL são fornecidas no lado do dispositivo da interface do fornecedor, incluindo as imagens do fornecedor e ODM. O conteúdo de um manifesto de dispositivo é restrito pela versão do FCM de destino do dispositivo, mas pode listar HALs que são estritamente mais recentes em relação à FC correspondente a V.
- HALs do dispositivo
- HALs listadas (fornecidas) no manifesto do dispositivo e listadas (obrigatórios ou opcionais) na matriz de compatibilidade do framework (FCM).
- Matriz de compatibilidade de dispositivos (DCM)
- Um arquivo XML que especifica os requisitos do fornecedor sobre implementações de framework em conformidade. Cada dispositivo contém um DCM.
- Manifesto do framework
- Um arquivo XML que especifica quais versões de HAL o lado do framework da interface do fornecedor fornece, incluindo system, system_ext e imagens de produto. As HALs no manifesto do framework são desativadas dinamicamente de acordo com a versão do FCM de destino do dispositivo.
- HALs de framework
- HALs que são listadas conforme fornecido no manifesto do framework e listadas como obrigatórias ou opcionais na matriz de compatibilidade de dispositivos (DCM).
Ciclo de vida do FCM na base de código
Neste documento, descrevemos o ciclo de vida do FCM no resumo. Para ver os manifestos
compatíveis, consulte hardware/interfaces/compatibility_matrix.<FCM>.xml
,
em que o FCM pode ser encontrado em
system/libvintf/include/vintf/Level.h
.
Um dispositivo que envia a versão correspondente do Android precisa ter um valor do FCM maior ou igual ao nível equivalente. Por exemplo, um dispositivo enviado com o Android 11 geralmente teria o FCM de nível 5, mas implementaria o FCM de nível 6 ou mais recente, que vem com vários outros requisitos especificados nas matrizes de compatibilidade. Os níveis compatíveis 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 |
Quando o Android descontinua um nível do FCM, ele ainda é compatível com os dispositivos atuais.
Como desenvolver uma nova versão do FCM
O Android incrementa a versão do FCM a cada versão do framework (como Android 8,
8.1 etc.). Durante o desenvolvimento, o novo compatibility_matrix.F.xml
é criado e
o compatibility_matrix.f.xml
existente (em que f
< F
) não é mais alterado.
Para começar a desenvolver em uma nova versão do FCM, F
:
- Copie o
compatibility_matrix.<F-1>.xml
mais recente paracompatibility_matrix.F.xml
. - Atualize o atributo
level
no arquivo paraF
. - Adicione regras de build correspondentes para instalar essa matriz de compatibilidade no dispositivo.
Introdução de uma nova HAL
Durante o desenvolvimento, ao introduzir uma nova HAL (Wi-Fi, NFC etc.) no Android
na versão atual F
do FCM, adicione a HAL a compatibility_matrix.F.xml
com
as seguintes configurações de optional
:
optional="false"
se os dispositivos que vêm comV = F
precisarem ser iniciados com essa HAL,optional="true"
se os dispositivos que vêm com oV = F
puderem ser iniciados sem essa HAL.
Por exemplo, o Android 8.1 introduziu a cas@1.0
como uma HAL opcional. Os dispositivos lançados
com o Android 8.1 não precisam implementar essa HAL. Portanto, a entrada abaixo foi
adicionada a compatibility_matrix.F.xml
(que costumava ser chamada de
compatibility_matrix.current.xml
temporariamente durante o desenvolvimento dessa versão):
<hal format="hidl" optional="true">
<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)
Durante o desenvolvimento, quando uma HAL tiver um upgrade de versão secundária de x.z
para x.(z+1)
na versão atual F
do FCM, se essa versão for:
- Obrigatório em dispositivos lançados com
V = F
, ocompatibility_matrix.F.xml
precisa declararx.(z+1)
eoptional="false"
. - Não é necessário em dispositivos iniciados com
V = F
, ocompatibility_matrix.F.xml
precisa copiarx.y-z
e a opção decompatibility_matrix.<F-1>.xml
e mudar a versão parax.w-(z+1)
(em quew >= y
).
Por exemplo, o Android 8.1 introduziu broadcastradio@1.1
como uma atualização de versão secundária
da HAL 1.0. A versão mais antiga, broadcastradio@1.0
, é opcional para dispositivos
iniciados com o Android 8.0. Já a versão mais recente, broadcastradio@1.1
, é
opcional para dispositivos lançados com o Android 8.1. Em
compatibility_matrix.1.xml
:
<hal format="hidl" optional="true">
<name>android.hardware.broadcastradio</name>
<version>1.0</version>
<interface>
<name>IBroadcastRadioFactory</name>
<instance>default</instance>
</interface>
</hal>
Esta entrada foi copiada para compatibility_matrix.F.xml
e modificada da seguinte forma:
<hal format="hidl" optional="true">
<name>android.hardware.broadcastradio</name>
<version>1.0-1</version>
<interface>
<name>IBroadcastRadioFactory</name>
<instance>default</instance>
</interface>
</hal>
Fazer upgrade de uma HAL (principal)
Durante o desenvolvimento, quando uma HAL tem um upgrade na versão principal F
, a nova versão principal x.0
é adicionada a compatibility_matrix.F.xml
com as seguintes configurações de optional
:
optional="false"
apenas com a versãox.0
, se os dispositivos que vêm comV = F
precisarem ser iniciados comx.0
.optional="false"
, mas junto com versões principais mais antigas na mesma tag<hal>
, se os dispositivos que vêm comV = F
precisarem ser lançados com essa HAL, mas puderem ser iniciados com uma versão principal mais antiga.optional="true"
se os dispositivos que vêm com oV = F
não precisarem iniciar a HAL.
Por exemplo, o Android 9 apresenta a health@2.0
como uma
atualização da versão principal da HAL 1.0 e descontinua a HAL 1.0. A versão mais antiga,
health@1.0
, é opcional para dispositivos lançados com o Android 8.0 e o Android 8.1.
Os dispositivos lançados com o Android 9 não podem fornecer a
HAL 1.0 descontinuada e, em vez disso, precisam fornecer a nova versão 2.0. Eu
compatibility_matrix.legacy.xml
,
compatibility_matrix.1.xml
e
compatibility_matrix.2.xml
:
<hal format="hidl" optional="true">
<name>android.hardware.health</name>
<version>1.0</version>;
<interface>
<name>IHealth</name>
<instance>default</instance>
</interface>
</hal>
Esta entrada foi copiada para compatibility_matrix.F.xml
e modificada da seguinte maneira:
<hal format="hidl" optional="false">
<name>android.hardware.health</name>
<version>2.0</version>
<interface>
<name>IHealth</name>
<instance>default</instance>
</interface>
</hal>
Restrições:
- Como a HAL 2.0 está em
compatibility_matrix.3.xml
comoptional="false"
, os dispositivos iniciados com o Android 9 precisam ser enviados com a HAL 2.0. - Como a HAL 1.0 não está na
compatibility_matrix.3.xml
, os dispositivos lançados com o Android 9 não podem fornecer a HAL 1.0, já que ela é considerada obsoleta. - Como a HAL 1.0 está presente no legacy/1/2.xml (versões mais antigas do FCM com as quais o Android 9 pode trabalhar) como uma HAL opcional, o framework do Android 9 ainda pode funcionar com a HAL 1.0 (que não é considerada uma versão removida da HAL).
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
compatibility_matrix.F.xml
tem o atributolevel="F"
. - Garanta que todos os dispositivos sejam criados e inicializados.
- Atualize os testes VTS para garantir que os dispositivos lançados com o framework mais recente (com base
no nível da API Shipping) tenham a versão de destino do FCM
V >= F
. - Publicar arquivo no AOSP.
Por exemplo, os testes VTS garantem que os dispositivos lançados com o Android 9 tenham a versão 3 ou mais recente do FCM de destino.
Além disso, os FCMs de produto e system_ext também podem listar os requisitos de cada versão do FCM de cada plataforma. O lançamento de versões do FCM nas partições do produto e system_ext é feito pelo proprietário dessas imagens, respectivamente. Os números de versão do FCM nas partições 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 system_ext reflete os requisitos em um dispositivo com a versão F de destino do FCM.
Descontinuação da versão da HAL
A descontinuação de uma versão da HAL é uma decisão do desenvolvedor. Para HALs do AOSP, o Google toma essa decisão. Isso pode acontecer quando uma versão mais recente da HAL (secundária ou principal) é lançada.
Descontinuação do uso da HAL de dispositivo
Quando a HAL de determinado dispositivo foo@x.y
é descontinuada na versão F
do FCM, isso significa
que qualquer dispositivo iniciado com a versão V = F
ou mais recente do FCM de destino não pode
implementar foo
na versão x.y
ou em qualquer versão anterior a x.y
. Uma versão
de HAL descontinuada ainda tem suporte do framework para fazer upgrade de dispositivos.
Quando a versão F
do FCM for lançada, a versão foo@x.y
da HAL será considerada
obsoleta se a versão específica da HAL não for explicitamente declarada na versão mais recente
do FCM para a versão de destino V = F
do FCM. Para dispositivos lançados com V = F
, uma das
condições abaixo é verdadeira:
- a estrutura requer uma versão superior (principal ou secundária);
- O framework não exige mais a HAL.
Por exemplo, no Android 9, health@2.0
é apresentado
como um upgrade principal da versão 1.0 da HAL. 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. Por isso, o uso de health@1.0
é considerado descontinuado.
Suspensão do uso de uma HAL de framework
Quando o uso de uma determinada HAL de framework foo@x.y
é suspenso na versão F
do FCM, isso significa que os dispositivos iniciados com a versão V = F
ou mais recente do FCM não podem esperar que o framework forneça foo
na versão x.y
ou em qualquer versão anterior a x.y
. Uma versão descontinuada da HAL ainda é fornecida pelo framework para
fazer upgrade de dispositivos.
Quando a versão F
do FCM for lançada, a versão foo@x.y
da HAL será considerada
obsoleta se o manifesto do framework especificar
max-level="F - 1"
para foo@x.y
. Para dispositivos lançados
com V = F
, o framework não fornece o foo@x.y
da HAL. A matriz
de compatibilidade do dispositivo em dispositivos iniciados com V = F
não pode listar as HALs de framework
com max-level < V
.
Por exemplo, no Android 12, o uso de schedulerservice@1.0
foi
descontinuado. O atributo max-level
está definido como 5
, a versão do FCM introduzida
no Android 11. Consulte o
manifesto do framework do Android 12.
Remoção do suporte para versões de destino do FCM
Quando os dispositivos ativos de uma determinada V
versão de destino do FCM ficam abaixo de um determinado
limite, a versão de destino do FCM é removida do SF definido da
próxima versão do framework. Para isso, siga estas duas etapas:
Remover
compatibility_matrix.V.xml
das regras de build (para que ele não seja instalado na imagem do sistema) e excluir qualquer código que tenha implementado ou dependente da funcionalidade removida.Remoção das HALs de framework com
max-level
menor ou igual aV
do manifesto do framework e exclusão de qualquer código que implemente as HALs de framework removidas.
Os dispositivos com uma versão de destino do FCM fora do SF para uma determinada versão do framework não podem ser atualizados.
Status da versão da HAL
As seções a seguir descrevem, em ordem cronológica, os estados possíveis de uma versão da HAL.
Inéditos
Para HALs de dispositivo, se uma versão da 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 da HAL que estão apenas em compatibility_matrix.F.xml
.
Exemplos:
- Durante o desenvolvimento do Android 9, a
HAL
health@2.0
foi considerada uma HAL de lançamento 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 ainda não lançada.
Para HALs de framework, se uma versão dela estiver apenas no manifesto do framework de uma ramificação de desenvolvimento não relacionada, ela será considerada não lançada.
Lançados e atuais
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 for congelada e publicada
no AOSP, a HAL health@2.0
será considerada uma versão lançada e atual da HAL.
Se uma versão da HAL estiver em uma matriz de compatibilidade pública e congelada que tenha a
versão mais alta do FCM, a versão da HAL é atual (ou seja, não foi descontinuada). Por
exemplo, as versões da HAL existentes, como nfc@1.0
introduzidas em
compatibility_matrix.legacy.xml
,
que continuam a existir em compatibility_matrix.3.xml
também são consideradas
como versões lançadas e atuais da HAL.
Para as HALs do framework, se uma versão da HAL estiver no manifesto do framework
da ramificação lançada mais recente sem o atributo max-level
ou (normalmente) uma
max-level
igual ou superior à versão do FCM lançada nessa ramificação, ela
será considerada uma versão lançada e atual da HAL. Por exemplo, a
HAL displayservice
foi lançada e está atualizada no Android
12, conforme especificado pelo
manifesto do framework do Android 12.
Lançado, mas descontinuado
Para HALs de dispositivos, uma versão da HAL será descontinuada somente se todos os requisitos a seguir forem atendidos:
- Ela é lançada.
- Ele não está na matriz de compatibilidade pública e congelada que tem a versão mais alta do FCM.
- Ele está em uma matriz de compatibilidade pública e congelada que o framework ainda aceita.
Exemplos:
- A 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, o uso dela é considerado descontinuado no Android 9. - A HAL de energia tem um upgrade 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 está descontinuado no Android
9.
Para HALs do framework, se uma versão da HAL estiver no manifesto do framework da ramificação
lançada mais recente com um atributo max-level
menor que o lançamento da versão do FCM
nessa ramificação, ela será considerada uma versão da HAL lançada, mas descontinuada. Por
exemplo, a HAL schedulerservice
foi lançada, mas descontinuada no
Android 12, conforme especificado pelo
manifesto do framework do Android 12.
Vídeo removido
Para HALs de dispositivos, uma versão da HAL será removida somente se o seguinte for verdadeiro:
- Ele já foi lançado.
- Ele não está em nenhuma matriz de compatibilidade pública e congelada compatível com o framework.
As matrizes de compatibilidade que são públicas, congeladas, mas não têm suporte do framework são mantidas na base do código para definir as versões da HAL removidas. Assim, os testes VTS podem ser programados para garantir que as HALs removidas não estejam em novos dispositivos.
Para as HALs de framework, uma versão dela será removida somente se os seguintes itens forem atendidos:
- Ele já foi lançado.
- Ele não está em nenhum manifesto de framework da ramificação lançada mais recentemente.
FCMs legados
A versão legada da versão do FCM de destino é um valor especial para todos os dispositivos não 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 não Treble poderá
ser atualizado para F
, desde que o manifesto do dispositivo seja compatível com o arquivo. A
remoção segue o mesmo procedimento que os FCMs para outras versões de destino do FCM.
Elas são removidas quando o número de dispositivos ativos anteriores à versão 8.0 fica abaixo de um determinado
limite.
Versões lançadas do FCM
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
.