Ciclo de vida do FCM

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 que foo é o nome da HAL e x.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:

  1. Copie o compatibility_matrix.<F-1>.xml mais recente para compatibility_matrix.F.xml.
  2. Atualize o atributo level no arquivo para F.
  3. 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 com V = F precisarem ser iniciados com essa HAL,
  • optional="true" se os dispositivos que vêm com o V = 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, o compatibility_matrix.F.xml precisa declarar x.(z+1) e optional="false".
  • Não é necessário em dispositivos iniciados com V = F, o compatibility_matrix.F.xml precisa copiar x.y-z e a opção de compatibility_matrix.<F-1>.xml e mudar a versão para x.w-(z+1) (em que w >= 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ão x.0, se os dispositivos que vêm com V = F precisarem ser iniciados com x.0.
  • optional="false", mas junto com versões principais mais antigas na mesma tag <hal>, se os dispositivos que vêm com V = 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 o V = 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 com optional="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:

  1. Verifique se compatibility_matrix.F.xml tem o atributo level="F".
  2. Garanta que todos os dispositivos sejam criados e inicializados.
  3. 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.
  4. 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:

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

  2. Remoção das HALs de framework com max-level menor ou igual a V 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 em compatibility_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:

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.