Ciclo de vida do FCM

Uma versão de estrutura do 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 de versão do Target FCM. Como parte do ciclo de vida do FCM, o Android deprecia 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 do fornecedor também devem descontinuar e remover HIDL HALs usando os mesmos métodos.

Terminologia

Matriz de Compatibilidade de Estrutura (FCM) Um arquivo XML que especifica requisitos de estrutura em implementações de fornecedor em conformidade. A matriz de compatibilidade é versionada e uma nova versão é congelada para cada lançamento da estrutura. 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 de estrutura. A estrutura pode funcionar com qualquer implementação de fornecedor que satisfaça um desses FCMs.
Versão FCM (F) A versão mais alta entre todos os FCMs em uma versão de estrutura.
Versão do FCM alvo (V) A versão de destino do FCM (de S F ), declarada explicitamente no manifesto do dispositivo, que uma implementação do fornecedor satisfaz. Uma implementação de fornecedor deve ser gerada em um FCM publicado, embora possa declarar versões HAL mais recentes em seu manifesto de dispositivo.
Versão HAL Uma versão HAL tem 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 neste documento.)
Manifesto do dispositivo Arquivos XML que especificam quais versões HAL o lado do dispositivo da interface do fornecedor, incluindo o fornecedor e as imagens ODM, fornece. O conteúdo de um manifesto de dispositivo é limitado pela versão Target FCM do dispositivo, mas pode listar HALs estritamente mais recentes em relação ao FCM correspondente a V.
Dispositivo HAL HALs listados (fornecidos) no manifesto do dispositivo e listados (necessá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 em implementações de estrutura em conformidade. Cada dispositivo contém um DCM.
Manifesto da Estrutura Um arquivo XML que especifica quais versões HAL o lado da estrutura da interface do fornecedor, incluindo sistema, system_ext e imagens do produto, fornece. Os HALs no manifesto da estrutura são desabilitados dinamicamente de acordo com a versão Target FCM do dispositivo.
Estrutura HAL HALs listados conforme fornecido no manifesto da estrutura e listados como obrigatórios ou opcionais na matriz de compatibilidade de dispositivos (DCM).

Desenvolvendo em uma nova versão do FCM

O Android incrementa a versão do FCM para cada versão da estrutura (como Android 8, 8.1 etc.). Durante o desenvolvimento, a nova compatibility_matrix.F.xml é criada e a compatibility_matrix.f.xml existente (onde f < F ) não é mais alterada.

Para começar a desenvolver em um novo FCM Versão F :

  1. Copie a compatibility_matrix.<F-1>.xml mais recente para compatibility_matrix.F.xml .
  2. Atualize o atributo level no arquivo para F .
  3. Adicione as regras de construção correspondentes para instalar esta matriz de compatibilidade no dispositivo.

Apresentando um novo HAL

Durante o compatibility_matrix.F.xml , ao introduzir um novo HAL ( F optional Fi, NFC etc.)

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

    OU
  • 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 que iniciam com o Android 8.1 não são necessários para implementar este HAL, então a seguinte entrada foi adicionada a compatibility_matrix.F.xml (que costumava ser chamado 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>

Atualizando um HAL (menor)

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

  • Obrigatório em dispositivos que iniciam com V = F , a compatibility_matrix.F.xml deve indicar x.(z+1) e optional="false" .
  • Não é necessário em dispositivos iniciados com V = F , a compatibility_matrix.F.xml deve copiar xy-z e a opcionalidade da 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 de 1.0 HAL. A versão mais antiga, broadcastradio@1.0 , é opcional para dispositivos iniciados com Android 8.0, enquanto a versão mais recente, broadcastradio@1.1 , é opcional para dispositivos iniciados 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>

Atualizando um HAL (principal)

Durante o desenvolvimento, quando um HAL tem uma atualização de versão principal no atual FCM Versão F , a nova versão principal x.0 é adicionada a 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 iniciados com este HAL, mas podem ser iniciados 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 introduz health@2.0 como uma atualização de versão principal do 1.0 HAL e substitui o 1.0 HAL. A versão mais antiga, health@1.0 , é opcional para dispositivos lançados com Android 8.0 e Android 8.1. Os dispositivos iniciados com o Android 9 não devem fornecer o HAL 1.0 obsoleto e, em vez disso, devem fornecer a nova versão 2.0. Em 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 2.0 HAL está em compatibility_matrix.3.xml com optional="false" , os dispositivos iniciados com Android 9 devem ser fornecidos com 2.0 HAL.
  • Como o 1.0 HAL não está em compatibility_matrix.3.xml , os dispositivos iniciados com o Android 9 não devem fornecer o 1.0 HAL (já que este HAL é considerado obsoleto).
  • Como o 1.0 HAL está presente em legacy/1/2.xml (versões mais antigas do FCM com as quais o Android 9 pode funcionar) como um HAL opcional, a estrutura do Android 9 ainda pode funcionar com o 1.0 HAL (que não é considerado uma versão HAL removida ).

Novas versões do FCM

O processo de liberação 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 a compatibility_matrix.F.xml tenha o atributo level="F" .
  2. Certifique-se de que todos os dispositivos sejam compilados 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 o FCM de destino Versão V >= F .
  4. Publicar arquivo no AOSP.

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

Além disso, os FCMs product e system_ext também podem listar requisitos para cada versão de plataforma FCM. A liberação das versões do 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 do produto 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.

Descontinuação da versão HAL

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

Reprovar um dispositivo HAL

Quando um determinado dispositivo HAL foo@xy é descontinuado 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 obsoleta do HAL ainda é suportada pela estrutura para atualização de dispositivos.

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

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

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

Reprovar um framework HAL

Quando uma determinada estrutura HAL foo@xy é preterida no FCM Versão F , significa que qualquer dispositivo iniciado com o 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 obsoleta do HAL 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 é 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 as versões Target FCM

Quando os dispositivos ativos de um determinado Target FCM Version V caem abaixo de um determinado limite, o Target FCM Version é removido do conjunto S F da próxima versão da estrutura. Isso é feito por ambas as etapas a seguir:

  • Remoção compatibility_matrix.V.xml das regras de compilação (para que não seja instalado na imagem do sistema) e exclusão de qualquer código que implementasse ou dependesse da funcionalidade removida.
  • Remoção de HALs de estrutura com max-level inferior ou igual a V do manifesto de estrutura e exclusão de qualquer código que implemente as HALs de estrutura removidas.

Os dispositivos com uma versão FCM de destino fora de S F para uma determinada versão de 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.

inédito

Para HALs de dispositivo, se uma versão HAL não estiver em nenhuma das matrizes de compatibilidade públicas e congeladas, ela será considerada inédita e possivelmente em desenvolvimento. Isso inclui as versões HAL que estão apenas em compatibility_matrix.F.xml . Exemplos:

  • Durante o desenvolvimento do Android 9, o health@2.0 HAL foi considerado um HAL inédito e estava presente apenas em compatibiility_matrix.3.xml .
  • O teleportation@1.0 HAL 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 de 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 dispositivo, se uma versão HAL estiver em qualquer matriz de compatibilidade pública e congelada, ela será liberada. Por exemplo, depois que o FCM Versão 3 é congelado e publicado no AOSP, o health@2.0 HAL é 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 é 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 como lançadas e versões HAL atuais.

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

Lançado, mas obsoleto

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

  • Está liberado.
  • Não é na matriz de compatibilidade pública e congelada que tem a versão FCM mais alta.
  • É em uma matriz de compatibilidade pública e congelada que a estrutura ainda oferece suporte.

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 da estrutura da ramificação lançada mais recentemente com um atributo max-level inferior à versão FCM lançada nesta ramificação, ela será considerada uma versão HAL lançada, mas obsoleta. Por exemplo, o schedulerservice HAL foi lançado, mas obsoleto no Android 12, conforme especificado pelo Android 12framework manifest .

Removido

Para HALs de dispositivo, uma versão HAL é removida se e somente se o seguinte for verdadeiro:

  • Foi lançado anteriormente.
  • Não é em nenhuma matriz de compatibilidade pública e congelada que o framework suporta.

As 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 escritos para garantir que as HALs removidas não estejam em novos dispositivos.

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

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

FCMs herdados

O legado da versão FCM de destino é 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 pode 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 de FCM de destino (removido após o número de dispositivos pré-8.0 ativos cair 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 .

,

Uma versão de estrutura do 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 de versão do Target FCM. Como parte do ciclo de vida do FCM, o Android deprecia 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 do fornecedor também devem descontinuar e remover HIDL HALs usando os mesmos métodos.

Terminologia

Matriz de Compatibilidade de Estrutura (FCM) Um arquivo XML que especifica requisitos de estrutura em implementações de fornecedor em conformidade. A matriz de compatibilidade é versionada e uma nova versão é congelada para cada lançamento da estrutura. 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 de estrutura. A estrutura pode funcionar com qualquer implementação de fornecedor que satisfaça um desses FCMs.
Versão FCM (F) A versão mais alta entre todos os FCMs em uma versão de estrutura.
Versão do FCM alvo (V) A versão de destino do FCM (de S F ), declarada explicitamente no manifesto do dispositivo, que uma implementação do fornecedor satisfaz. Uma implementação de fornecedor deve ser gerada em um FCM publicado, embora possa declarar versões HAL mais recentes em seu manifesto de dispositivo.
Versão HAL Uma versão HAL tem 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 neste documento.)
Manifesto do dispositivo Arquivos XML que especificam quais versões HAL o lado do dispositivo da interface do fornecedor, incluindo o fornecedor e as imagens ODM, fornece. O conteúdo de um manifesto de dispositivo é limitado pela versão Target FCM do dispositivo, mas pode listar HALs estritamente mais recentes em relação ao FCM correspondente a V.
Dispositivo HAL HALs listados (fornecidos) no manifesto do dispositivo e listados (necessá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 em implementações de estrutura em conformidade. Cada dispositivo contém um DCM.
Manifesto da Estrutura Um arquivo XML que especifica quais versões HAL o lado da estrutura da interface do fornecedor, incluindo sistema, system_ext e imagens do produto, fornece. Os HALs no manifesto da estrutura são desabilitados dinamicamente de acordo com a versão Target FCM do dispositivo.
Estrutura HAL HALs listados conforme fornecido no manifesto da estrutura e listados como obrigatórios ou opcionais na matriz de compatibilidade de dispositivos (DCM).

Desenvolvendo em uma nova versão do FCM

O Android incrementa a versão do FCM para cada versão da estrutura (como Android 8, 8.1 etc.). Durante o desenvolvimento, a nova compatibility_matrix.F.xml é criada e a compatibility_matrix.f.xml existente (onde f < F ) não é mais alterada.

Para começar a desenvolver em um novo FCM Versão F :

  1. Copie a compatibility_matrix.<F-1>.xml mais recente para compatibility_matrix.F.xml .
  2. Atualize o atributo level no arquivo para F .
  3. Adicione as regras de construção correspondentes para instalar esta matriz de compatibilidade no dispositivo.

Apresentando um novo HAL

Durante o compatibility_matrix.F.xml , ao introduzir um novo HAL ( F optional Fi, NFC etc.)

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

    OU
  • 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 que iniciam com o Android 8.1 não são necessários para implementar este HAL, então a seguinte entrada foi adicionada a compatibility_matrix.F.xml (que costumava ser chamado 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>

Atualizando um HAL (menor)

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

  • Obrigatório em dispositivos que iniciam com V = F , a compatibility_matrix.F.xml deve indicar x.(z+1) e optional="false" .
  • Não é necessário em dispositivos iniciados com V = F , a compatibility_matrix.F.xml deve copiar xy-z e a opcionalidade da 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 de 1.0 HAL. A versão mais antiga, broadcastradio@1.0 , é opcional para dispositivos iniciados com Android 8.0, enquanto a versão mais recente, broadcastradio@1.1 , é opcional para dispositivos iniciados 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>

Atualizando um HAL (principal)

Durante o desenvolvimento, quando um HAL tem uma atualização de versão principal no atual FCM Versão F , a nova versão principal x.0 é adicionada a 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 iniciados com este HAL, mas podem ser iniciados 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 introduz health@2.0 como uma atualização de versão principal do 1.0 HAL e substitui o 1.0 HAL. A versão mais antiga, health@1.0 , é opcional para dispositivos lançados com Android 8.0 e Android 8.1. Os dispositivos iniciados com o Android 9 não devem fornecer o HAL 1.0 obsoleto e, em vez disso, devem fornecer a nova versão 2.0. Em 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 2.0 HAL está em compatibility_matrix.3.xml com optional="false" , os dispositivos iniciados com Android 9 devem ser fornecidos com 2.0 HAL.
  • Como o 1.0 HAL não está em compatibility_matrix.3.xml , os dispositivos iniciados com o Android 9 não devem fornecer o 1.0 HAL (já que este HAL é considerado obsoleto).
  • Como o 1.0 HAL está presente em legacy/1/2.xml (versões mais antigas do FCM com as quais o Android 9 pode funcionar) como um HAL opcional, a estrutura do Android 9 ainda pode funcionar com o 1.0 HAL (que não é considerado uma versão HAL removida ).

Novas versões do FCM

O processo de liberação 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 a compatibility_matrix.F.xml tenha o atributo level="F" .
  2. Certifique-se de que todos os dispositivos sejam compilados 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 o FCM de destino Versão V >= F .
  4. Publicar arquivo no AOSP.

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

Além disso, os FCMs product e system_ext também podem listar requisitos para cada versão de plataforma FCM. A liberação das versões do 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 do produto 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.

Descontinuação da versão HAL

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

Reprovar um dispositivo HAL

Quando um determinado dispositivo HAL foo@xy é descontinuado 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 obsoleta do HAL ainda é suportada pela estrutura para atualização de dispositivos.

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

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

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

Reprovar um framework HAL

Quando uma determinada estrutura HAL foo@xy é preterida no FCM Versão F , significa que qualquer dispositivo iniciado com o 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 obsoleta do HAL 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 é 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 as versões Target FCM

Quando os dispositivos ativos de um determinado Target FCM Version V caem abaixo de um determinado limite, o Target FCM Version é removido do conjunto S F da próxima versão da estrutura. Isso é feito por ambas as etapas a seguir:

  • Remoção compatibility_matrix.V.xml das regras de compilação (para que não seja instalado na imagem do sistema) e exclusão de qualquer código que implementasse ou dependesse da funcionalidade removida.
  • Remoção de HALs de estrutura com max-level inferior ou igual a V do manifesto de estrutura e exclusão de qualquer código que implemente as HALs de estrutura removidas.

Os dispositivos com uma versão FCM de destino fora de S F para uma determinada versão de 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.

inédito

Para HALs de dispositivo, se uma versão HAL não estiver em nenhuma das matrizes de compatibilidade públicas e congeladas, ela será considerada inédita e possivelmente em desenvolvimento. Isso inclui as versões HAL que estão apenas em compatibility_matrix.F.xml . Exemplos:

  • Durante o desenvolvimento do Android 9, o health@2.0 HAL foi considerado um HAL inédito e estava presente apenas em compatibiility_matrix.3.xml .
  • O teleportation@1.0 HAL 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 de 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 dispositivo, se uma versão HAL estiver em qualquer matriz de compatibilidade pública e congelada, ela será liberada. Por exemplo, depois que o FCM Versão 3 é congelado e publicado no AOSP, o health@2.0 HAL é 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 é 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 como lançadas e versões HAL atuais.

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

Lançado, mas obsoleto

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

  • Está liberado.
  • Não é na matriz de compatibilidade pública e congelada que tem a versão FCM mais alta.
  • É em uma matriz de compatibilidade pública e congelada que a estrutura ainda oferece suporte.

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 da estrutura da ramificação lançada mais recentemente com um atributo max-level inferior à versão FCM lançada nesta ramificação, ela será considerada uma versão HAL lançada, mas obsoleta. Por exemplo, o schedulerservice HAL foi lançado, mas obsoleto no Android 12, conforme especificado pelo Android 12framework manifest .

Removido

Para HALs de dispositivo, uma versão HAL é removida se e somente se o seguinte for verdadeiro:

  • Foi lançado anteriormente.
  • Não é em nenhuma matriz de compatibilidade pública e congelada que o framework suporta.

As 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 escritos para garantir que as HALs removidas não estejam em novos dispositivos.

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

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

FCMs herdados

O legado da versão FCM de destino é 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 pode 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 de FCM de destino (removido após o número de dispositivos pré-8.0 ativos cair 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 .