Ciclo de vida do FCM

Uma versão da estrutura Android tem várias matrizes de compatibilidade de estrutura (FCMs), uma para cada versão atualizável do Target FCM, que definem o que a estrutura pode usar e os requisitos da versão do Target FCM. Como parte do ciclo de vida do FCM, o Android descontinua e remove HALs HIDL e, em seguida, modifica os arquivos FCM para refletir o status da versão HAL .

Para habilitar OTAs somente de estrutura em seus próprios ecossistemas, os parceiros que estendem as interfaces dos fornecedores também devem descontinuar e remover HALs HIDL usando os mesmos métodos.

Terminologia

Matriz de compatibilidade de estrutura (FCM)
Um arquivo XML que especifica os requisitos da estrutura nas 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 da estrutura contém vários FCMs.
Versões da plataforma FCM (S F )
O conjunto de todas as versões do FCM em uma versão do framework. A estrutura pode funcionar com qualquer implementação de fornecedor que satisfaça um desses FCMs.
Versão FCM (F)
A versão mais recente entre todos os FCMs em uma versão do framework.
Versão alvo do FCM (V)
A versão do FCM de destino (de SF ), declarada explicitamente no manifesto do dispositivo, que uma implementação do fornecedor satisfaz. Uma implementação do fornecedor deve ser gerada em um FCM publicado, embora possa declarar versões mais recentes do HAL em seu Manifesto do Dispositivo.
Versão HAL
Uma versão HAL possui o formato foo@xy , onde foo é o nome HAL e xy é 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 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 é limitado pela versão Target FCM do dispositivo, mas pode listar HALs que são estritamente mais recentes em relação ao FC correspondente a V.
HALs de dispositivos
HALs listados (fornecidos) no manifesto do dispositivo e listados (obrigatórios ou opcionais) na matriz de compatibilidade de estrutura (FCM).
Matriz de compatibilidade de dispositivos (DCM)
Um arquivo XML que especifica os requisitos do fornecedor nas implementações de estrutura em conformidade. Cada dispositivo contém um DCM.
Manifesto Estrutural
Um arquivo XML que especifica quais versões HAL são fornecidas pelo lado da estrutura da interface do fornecedor, incluindo sistema, system_ext e imagens do produto. HALs no manifesto da estrutura são desabilitados dinamicamente de acordo com a versão do Target FCM do dispositivo.
Estrutura HALs
HALs listados conforme fornecido no manifesto da estrutura e listados como obrigatórios ou opcionais 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 de forma abstrata. Para ver os manifestos atualmente suportados, consulte hardware/interfaces/compatibility_matrix.<FCM>.xml onde o FCM pode ser encontrado em system/libvintf/include/vintf/Level.h .

A partir do Android 14, os níveis suportados são:

FCM Versão Android
4 Android 10/Q
5 Android 11/R
6 Android 12/S
7 Andróide 13/T
8 Android 14/U

Desenvolvendo em uma nova versão do FCM

O Android incrementa a versão do FCM para 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 (onde f < F ) não é mais alterado.

Para começar a desenvolver uma nova versão F do FCM:

  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 compilação correspondentes para instalar esta matriz de compatibilidade no dispositivo.

Apresentando um novo HAL

Durante o desenvolvimento, ao introduzir um novo HAL (Wi-Fi, NFC, etc.) no Android na versão atual do FCM F , adicione o HAL a compatibility_matrix.F.xml com as seguintes configurações optional :

  • optional="false" se os dispositivos fornecidos com V = F devem ser iniciados com este HAL,
  • optional="true" se os dispositivos fornecidos com V = F puderem ser iniciados sem este HAL.

Por exemplo, o Android 8.1 introduziu cas@1.0 como um HAL opcional. Os dispositivos lançados com Android 8.1 não são obrigados a implementar este HAL, portanto, a seguinte entrada 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>

Atualizar um HAL (menor)

Durante o desenvolvimento, quando um HAL tem uma atualização de versão secundária de xz para x.(z+1) na versão F do FCM atual, se essa versão for:

  • Obrigatório em dispositivos iniciados com V = F , compatibility_matrix.F.xml deve indicar x.(z+1) e optional="false" .
  • Não é necessário em dispositivos iniciados com V = F , o compatibility_matrix.F.xml deve copiar xy-z e opcionalidade de compatibility_matrix.<F-1>.xml e alterar a versão para xw-(z+1) (onde w >= y ).

Por exemplo, o Android 8.1 introduziu broadcastradio@1.1 como uma atualização de versão secundária do 1.0 HAL. A versão mais antiga, broadcastradio@1.0 , é opcional para dispositivos lançados com Android 8.0, enquanto a versão mais recente, broadcastradio@1.1 , é opcional para dispositivos lançados com 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>

Atualizar um HAL (principal)

Durante o desenvolvimento, quando um HAL tem uma atualização de versão principal na versão F do FCM atual, a nova versão principal x.0 é adicionada compatibility_matrix.F.xml com as seguintes configurações optional :

  • optional="false" apenas com a versão x.0 , se os dispositivos fornecidos 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 fornecidos com V = F devem ser lançados com este HAL, mas podem ser lançados com uma versão principal mais antiga.
  • optional="true" se os dispositivos fornecidos com V = F não precisarem iniciar o HAL.

Por exemplo, o Android 9 apresenta health@2.0 como uma atualização de versão principal do HAL 1.0 e descontinua o HAL 1.0. A versão mais antiga, health@1.0 , é opcional para dispositivos lançados com Android 8.0 e Android 8.1. Os dispositivos lançados com Android 9 não devem fornecer o HAL 1.0 obsoleto e, em vez disso, devem 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 é copiada para compatibility_matrix.F.xml e modificada da seguinte forma:

<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 o HAL 2.0 está em compatibility_matrix.3.xml com optional="false" , os dispositivos lançados com Android 9 devem ser fornecidos com HAL 2.0.`
  • Como o HAL 1.0 não está em compatibility_matrix.3.xml , os dispositivos iniciados com Android 9 não devem fornecer o HAL 1.0 (já que esse HAL é considerado obsoleto).
  • Como o HAL 1.0 está presente em legacy/1/2.xml (versões FCM mais antigas com as quais o Android 9 pode funcionar) como um HAL opcional, a estrutura do Android 9 ainda pode funcionar com o HAL 1.0 (que não é considerado uma versão HAL removida ).

Novas versões do FCM

O processo de lançamento de uma versão FCM na partição do sistema é feito exclusivamente pelo Google como parte de uma versão AOSP e inclui as seguintes etapas:

  1. Certifique-se de que compatibility_matrix.F.xml tenha o atributo level="F" .
  2. Certifique-se de que todos os dispositivos sejam construídos e inicializados.
  3. Atualize os testes VTS para garantir que os dispositivos lançados com a estrutura mais recente (com base no nível da API de envio) tenham Target FCM Version V >= F .
  4. Publicar arquivo no AOSP.

Por exemplo, os testes VTS garantem que os dispositivos lançados com Android 9 tenham versão Target FCM >= 3.

Além disso, os FCMs product e system_ext também podem listar requisitos para cada versão do FCM da plataforma. A liberação das versões FCM nas partições product e system_ext é feita pelo proprietário dessas imagens, respectivamente. Os números de versão do FCM nas partições product e system_ext devem estar alinhados com os da partição do sistema. Semelhante às versões do FCM na partição do sistema, a matriz de compatibilidade na versão F do FCM nas partições product e system_ext reflete os requisitos em um dispositivo com a versão F do FCM de destino.

Suspensão da versão HAL

A descontinuação de uma versão HAL é uma decisão do desenvolvedor (ou seja, para HALs AOSP, o Google toma a decisão). Isso pode acontecer quando uma versão HAL superior (menor ou maior) for lançada.

Descontinuar um dispositivo HAL

Quando um determinado dispositivo HAL foo@xy é obsoleto no FCM Versão F , significa que qualquer dispositivo iniciado com Target FCM Versão V = F ou posterior não deve implementar foo na versão xy ou qualquer versão anterior a xy . Uma versão HAL obsoleta ainda é suportada pela estrutura para atualização de dispositivos.

Quando a versão F do FCM é lançada, uma versão do HAL foo@xy é considerada obsoleta se a versão do HAL específica não for explicitamente declarada no FCM mais recente para a versão do FCM de destino V = F . Para dispositivos inicializados com V = F , uma das seguintes condições é verdadeira:

  • A estrutura requer uma versão superior (maior ou secundária);
  • A estrutura não requer mais o HAL.

Por exemplo, no Android 9, health@2.0 é introduzido como uma atualização de versão principal do 1.0 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 . Portanto, health@1.0 é considerado obsoleto.

Descontinuar uma estrutura HAL

Quando uma determinada estrutura HAL foo@xy é obsoleta no FCM versão F , significa que qualquer dispositivo iniciado com Target FCM versão V = F ou posterior não deve esperar que a estrutura forneça foo na versão xy ou em qualquer versão anterior a xy . Uma versão HAL obsoleta ainda é fornecida pela estrutura para atualização de dispositivos.

Quando a versão F do FCM é lançada, uma versão HAL foo@xy é considerada obsoleta se o manifesto da estrutura especificar max-level=" F - 1 " para foo@xy . Para dispositivos iniciados com V = F , a estrutura não fornece o HAL foo@xy . A matriz de compatibilidade de dispositivos em dispositivos iniciados com V = F não deve listar HALs de estrutura com max-level < V .

Por exemplo, no Android 12, schedulerservice@1.0 está obsoleto. Seu atributo max-level está definido como 5 , a versão do FCM introduzida no Android 11. Consulte o manifesto da estrutura do Android 12 .

Remoção do suporte para versões alvo do FCM

Quando os dispositivos ativos de uma determinada versão V do Target FCM caem abaixo de um determinado limite, a versão do Target FCM é removida do conjunto S F da próxima versão da estrutura. Isso é feito pelas duas etapas a seguir:

  1. Removendo compatibility_matrix.V.xml das regras de construção (para que não seja instalado na imagem do sistema) e excluindo qualquer código que implementasse ou dependesse da funcionalidade removida.

  2. Remover HALs da estrutura com max-level inferior ou igual a V do manifesto da estrutura e excluir qualquer código que implemente as HALs da estrutura removidas.

Dispositivos com uma versão do FCM de destino fora de SF para uma determinada versão da estrutura não podem atualizar para essa versão.

Status da versão HAL

As seções a seguir descrevem (em ordem cronológica) os possíveis estados de uma versão HAL.

Não lançado

Para HALs de dispositivos, se uma versão HAL não estiver em nenhuma das matrizes de compatibilidade pública e congelada, ela será considerada não lançada e possivelmente em desenvolvimento. Isso inclui versões HAL que estão apenas em compatibility_matrix.F.xml . Exemplos:

  • Durante o desenvolvimento do Android 9, o HAL health@2.0 foi considerado um HAL não lançado e estava presente apenas em compatibility_matrix.3.xml .
  • O HAL teleportation@1.0 não está em nenhuma matriz de compatibilidade lançada e também é considerado um HAL não lançado.

Para HALs de estrutura, se uma versão HAL estiver apenas no manifesto de estrutura de uma ramificação de desenvolvimento não relacionada, ela será considerada não lançada.

Lançado e Atual

Para HALs de dispositivos, se uma versão HAL estiver em qualquer matriz de compatibilidade pública e congelada, ela será lançada. Por exemplo, após o FCM versão 3 ser congelado e publicado no AOSP, o HAL health@2.0 é considerado uma versão HAL lançada e atual.

Se uma versão HAL estiver em uma matriz de compatibilidade pública e congelada que tenha a versão FCM mais alta, a versão HAL será a atual (ou seja, não obsoleta). Por exemplo, versões 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 versões HAL lançadas e atuais.

Para HALs de estrutura, se uma versão HAL estiver no manifesto da estrutura da última ramificação lançada sem o atributo max-level ou (excepcionalmente) um max-level igual ou superior à versão do FCM lançada nesta ramificação, ela será considerada uma versão liberada. e versão atual do HAL. Por exemplo, o displayservice HAL foi lançado e atualizado no Android 12, conforme especificado pelo manifesto da estrutura do Android 12 .

Lançado, mas obsoleto

Para HALs de dispositivo, uma versão HAL será obsoleta se e somente se todos os itens a seguir forem atendidos:

  • Está liberado.
  • Não está na matriz de compatibilidade pública e congelada que possui a versão FCM mais alta.
  • É numa matriz de compatibilidade pública e congelada que o framework ainda suporta.

Exemplos:

Portanto, power@1.0 é atual, mas NÃO obsoleto, no Android 9.

Para HALs de estrutura, se uma versão HAL estiver no manifesto de estrutura da última ramificação lançada com um atributo max-level inferior ao lançamento da versão FCM nesta ramificação, ela será considerada uma versão HAL liberada, mas obsoleta. Por exemplo, o HAL schedulerservice foi lançado, mas foi descontinuado no Android 12, conforme especificado pelo manifesto da estrutura do Android 12 .

Removido

Para HALs de dispositivos, uma versão HAL será removida se e somente se o seguinte for verdadeiro:

  • Foi lançado anteriormente.
  • Não está em nenhuma matriz de compatibilidade pública e congelada que a estrutura suporta.

Matrizes de compatibilidade que são públicas, congeladas, mas não suportadas pela estrutura, são mantidas na base de código para definir o conjunto de versões HAL removidas, para que os testes VTS possam ser gravados para garantir que HALs removidos não estejam em novos dispositivos.

Para HALs de estrutura, uma versão HAL será removida se e somente se o seguinte for atendido:

  • Foi lançado anteriormente.
  • Não está em nenhum manifesto de estrutura da última ramificação lançada.

FCMs legados

A versão legado do FCM alvo é um valor especial para todos os dispositivos não Treble. O FCM legado, compatibility_matrix.legacy.xml , lista os requisitos da estrutura em dispositivos legados (ou seja, dispositivos lançados antes do Android 8.0).

Se este arquivo existir para um FCM com versão F , qualquer dispositivo não Treble poderá ser atualizado para F , desde que seu manifesto de dispositivo seja compatível com este arquivo. Sua remoção segue o mesmo procedimento dos FCMs para outras versões do Target FCM (removido após o número de dispositivos ativos anteriores à 8.0 cair abaixo de um determinado limite).

Versões 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 .