O Google tem o compromisso de promover a igualdade racial para as comunidades negras. Saiba como.

Ciclo de Vida FCM

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

Para habilitar OTAs apenas 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 os requisitos da estrutura em implementações de fornecedores em conformidade. A matriz de compatibilidade é versionada e uma nova versão é congelada para cada lançamento do framework. Cada versão do framework contém vários FCMs.
Versões 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 alta entre todos os FCMs em uma versão do framework.
Versão de destino do FCM (V) A versão FCM alvo (a partir de S F), declarado explicitamente no manifesto do dispositivo, que satisfaçam implementação do fornecedor. A implementação de um fornecedor deve ser gerada em relação a um FCM publicado, embora possa declarar versões HAL mais recentes em seu Manifesto de dispositivo.
Versão HAL A HAL Versão 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 de raiz, por exemplo, android.hardware , é omitido ao longo deste documento.)
Manifesto do dispositivo Arquivos XML que especificam quais versões de HAL o lado do dispositivo da interface do fornecedor, incluindo o fornecedor e imagens ODM, fornece. O conteúdo de um manifesto de dispositivo é restringido pela versão do FCM de destino do dispositivo, mas pode listar HALs que são estritamente mais recentes em relação ao FCM correspondente a V.
HALs do dispositivo HALs listados (fornecidos) no manifesto do dispositivo e listados (obrigatórios ou opcionais) na matriz de compatibilidade da estrutura (FCM).
Matriz de compatibilidade de dispositivo (DCM) Um arquivo XML que especifica os requisitos do fornecedor sobre as implementações de estrutura em conformidade. Cada dispositivo contém um DCM.
Manifesto de estrutura Um arquivo XML que especifica quais versões HAL são fornecidas pelo lado da estrutura da interface do fornecedor, incluindo system, system_ext e product images. Os HALs no manifesto da estrutura são desativados dinamicamente de acordo com a versão do FCM de destino do dispositivo.
Framework HALs HALs listados conforme fornecidos no manifesto da estrutura e listados como obrigatórios ou opcionais na matriz de compatibilidade do dispositivo (DCM).

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.current.xml é criado ( F ) eo existente compatibility_matrix.f.xml (onde f < F ) não é mais alterado.

Para iniciar o desenvolvimento de uma nova FCM Versão F :

  1. Copie o mais recente compatibility_matrix.<F-1>.xml para compatibility_matrix.current.xml .
  2. Atualizar o level atributo no arquivo para F .
  3. Adicione regras de construçã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.) para Android no atual FCM Versão F , adicione o HAL para compatibility_matrix.current.xml com os seguintes optional configurações:

  • optional="false" se os dispositivos que vêm com o V = F deve lançar com este HAL,

    OU
  • optional="true" se os dispositivos que vêm com o V = F pode iniciar sem esse HAL.

Por exemplo, o Android 8.1 introduziu cas@1.0 como um HAL opcional. Dispositivos de lançamento com o Android 8.1 não são obrigados a implementar este HAL, então a seguinte entrada foi adicionado em compatibility_matrix.current.xml (renomeado para compatibility_matrix.2.xml depois Android 8.1 lançado):

<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 tem uma pequena atualização da versão de xz para x.(z+1) na corrente FCM Versão F , se essa versão é:

  • Requerido em dispositivos de lançamento com V = F , o compatibility_matrix.current.xml estado mosto x.(z+1) e optional="false" .
  • Não é necessário nos dispositivos de lançamento com V = F , o compatibility_matrix.current.xml deve copiar xy-z e possibilidade de opção de compatibility_matrix.<F-1>.xml e alterar a versão para xw-(z+1) (em que w >= y ).

Por exemplo, o Android 8.1 introduziu broadcastradio@1.1 como uma versão menor atualizar de 1,0 HAL. A versão mais antiga, broadcastradio@1.0 , é opcional para dispositivos de lançamento com o Android 8.0, enquanto a versão mais recente, broadcastradio@1.1 , é opcional para dispositivos de lançamento 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 copiado para compatibility_matrix.current.xml (renomeado para compatibility_matrix.2.xml depois Android 8.1 lançado) e modificado 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 grande atualização da versão em corrente FCM Versão F , a nova versão principal x.0 é adicionado ao compatibility_matrix.current.xml com os seguintes optional configurações:

  • optional="false" com versão só x.0 , se os dispositivos que vêm com o V = F deve lançar com x.0 .
  • optional="false" , mas junto com versões principais mais velhos na mesma <hal> tag, se os dispositivos que vêm com o V = F devem lançar com este HAL, mas pode lançar com uma grande versão mais velha.
  • optional="true" se os dispositivos que vêm com o V = F não tem que lançar o HAL.

Por exemplo, Android 9 introduz health@2.0 como uma grande-versão de atualização do 1.0 HAL e despreza o HAL 1.0. A versão mais antiga, health@1.0 , é opcional para dispositivos de lançamento com o Android 8.0 e Android 8.1. Os dispositivos lançados 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 é copiado para compatibility_matrix.current.xml (renomeado para compatibility_matrix.3.xml com o 9 versão Android) e modificado 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:

  • Porque o HAL 2.0 está em compatibility_matrix.3.xml com optional="false" dispositivos, que lançamento com Android 9 deve enviar com 2,0 HAL.
  • Porque a 1,0 HAL não está na compatibility_matrix.3.xml , dispositivos que lançamento com Android 9 não deve fornecer o HAL 1.0 (como este HAL é considerado obsoleto).
  • Como o HAL 1.0 está presente no legado / 1 / 2.xml (versões anteriores do FCM 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 liberação de uma versão do FCM na partição do sistema é feito exclusivamente pelo Google como parte de uma versão AOSP e inclui as seguintes etapas:

  1. Renomeie compatibility_matrix.current.xml para compatibility_matrix.F.xml .
  2. Verifique se o arquivo tem o atributo level="F" .
  3. Editar correspondentes regras de compilação para refletir a mudança de nome de arquivo.
  4. Certifique-se de que todos os dispositivos sejam construídos e inicializados.
  5. Atualização VTS testes para garantir que os dispositivos de lançamento com o último quadro (com base no nível API envio) tem Alvo FCM Versão V >= F .
  6. Publique o arquivo no AOSP.

Este arquivo não pode ser alterada depois renomeado e publicado. Por exemplo, durante Android 9 desenvolvimento os seguintes arquivos são construídos para hardware/interfaces/compatibility_matrices/ :

  • compatibility_matrix.legacy.xml
  • compatibility_matrix.1.xml
  • compatibility_matrix.2.xml
  • compatibility_matrix.current.xml

Quando 9 Android é lançado, compatibility_matrix.current.xml é renomeado para compatibility_matrix.3.xml e os seguintes arquivos são construídos para hardware/interfaces/compatibility_matrices/ :

  • compatibility_matrix.legacy.xml
  • compatibility_matrix.1.xml
  • compatibility_matrix.2.xml
  • compatibility_matrix.3.xml

Testes VTS garantir que os dispositivos de lançamento com Android 9 têm Alvo FCM Version> = 3.

Além disso, os FCMs product e system_ext também podem listar os requisitos para cada versão do FCM da plataforma. 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 product e system_ext devem estar alinhados com os da partição do sistema. Semelhante às versões FCM na partição do sistema, a matriz de compatibilidade no FCM versão F nas partições product e system_ext reflete os requisitos em um dispositivo com a versão FCM de destino F.

Suspensão de uso da versão HAL

A suspensã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 superior do HAL (seja secundária ou principal) é lançada.

Obsoletar um HAL de dispositivo

Quando um determinado dispositivo HAL foo@xy é obsoleto na FCM Versão F , isso significa que qualquer lançamento dispositivo com alvo FCM Versão V = F ou posterior não deve implementar foo na versão xy ou qualquer versão mais antiga que xy . Uma versão obsoleta do HAL ainda é compatível com a estrutura para atualização de dispositivos.

Quando FCM Versão F é libertado, o HAL Versão foo@xy é considerado obsoleto se o específico HAL versão não é explicitamente declarado na última FCM para a Target FCM Versão V = F . Para dispositivos de lançamento com V = F , uma das seguintes condições:

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

Por exemplo, no Android 9, health@2.0 é introduzido como uma grande atualização versão 1.0 HAL. health@1.0 é removido compatibility_matrix.3.xml mas está presente em compatibility_matrix.legacy.xml , compatibility_matrix.1.xml , e compatibility_matrix.2.xml . Assim, health@1.0 é considerado obsoleto.

Obsoletar um HAL de estrutura

Quando um quadro dado HAL foo@xy é obsoleto na FCM Versão F , isso significa que qualquer lançamento dispositivo com alvo FCM Versão V = F ou posterior não deve esperar que o quadro para fornecer foo na versão xy , ou em qualquer versão mais antiga que xy . Uma versão obsoleta do HAL ainda é fornecida pela estrutura para atualização de dispositivos.

Quando FCM versão F é libertado, o HAL Versão foo@xy é considerado obsoleto se o quadro de manifesto especifica max-level=" F - 1 " para foo@xy . Para dispositivos de lançamento com V = F , o quadro não fornece a HAL foo@xy . A matriz de compatibilidade dispositivo em dispositivos de lançamento com V = F não deve lista HAL-quadro com max-level < V .

Por exemplo, no Android 12, schedulerservice@1.0 está obsoleta. Seu max-level atributo é definido como 5 , a versão FCM introduzido no Android 11. Ver Android 12 manifesto quadro .

Remoção do suporte para versões do FCM de destino

Quando os dispositivos activos de um determinado alvo FCM Versão V gota abaixo de um certo limiar, a FCM Versão alvo é removida do conjunto S F do quadro seguinte de libertação. Isso é feito por ambas as etapas a seguir:

  • Removendo compatibility_matrix.V.xml das regras de compilação (para que ele não está instalado na imagem do sistema), e excluir qualquer código que implementou ou depende da funcionalidade removido.
  • Removendo-quadro com HAL max-level menor do que ou igual a V a partir do manifesto quadro, e a exclusão de qualquer código que implementa as removidos HAL-quadro.

Dispositivos com um alvo FCM Versão fora da S F para um determinado lançamento quadro não pode 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édita

Para HALs de dispositivo, se uma versão de 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 são apenas em compatibility_matrix.current.xml . Exemplos:

  • Durante o desenvolvimento do Android 9 (antes compatibiility_matrix.current.xml é renomeado para compatibility_matrix.3.xml ), o health@2.0 HAL foi considerado um HAL inéditas.
  • O teleportation@1.0 HAL não está em nenhum matrizes de compatibilidade lançado, e também é considerado um HAL inéditas.

Para framework HALs, se uma versão do HAL estiver apenas no manifesto do framework de um branch de desenvolvimento não relacionado, ela é considerada não lançada.

Lançado e Atual

Para HALs de dispositivo, se uma versão de HAL estiver em qualquer matriz de compatibilidade pública e congelada, ela será lançada. Por exemplo, após FCM versão 3 está congelada (quando compatibiility_matrix.current.xml é renomeado para compatibility_matrix.3.xml ) e publicado para AOSP, o health@2.0 HAL é considerado um HAL versão lançada e atual.

Se uma versão HAL está em uma matriz pública e compatibilidade congelada que tem a maior FCM Version (excluindo compatibility_matrix.current.xml ), a versão HAL é atual (ou seja, não obsoleto). Por exemplo, versões HAL existentes (tais como nfc@1.0 introduzido em compatibility_matrix.legacy.xml ) que continuam a existir no compatibility_matrix.3.xml também são considerados como versões HAL libertados e correntes.

Para HAL-quadro, se uma versão HAL está no manifesto âmbito do mais recente ramo divulgados sem o max-level atributo ou (raramente) um max-level igual ou superior à versão FCM lançado neste ramo, é considerada uma liberado e a versão atual do HAL. Por exemplo, o displayservice HAL é liberado e atual em Android 12, conforme especificado pelo Android 12framework manifest .

Lançado, mas descontinuado

Para HALs de dispositivo, uma versão de HAL é descontinuada se e somente se todas as seguintes condições forem atendidas:

  • Ele é lançado.
  • Não está 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:

Daí power@1.0 é atual, mas não obsoleto, no Android 9.

Para HAL-quadro, se uma versão HAL está no manifesto âmbito do mais recente ramo lançado com um max-level atributo inferior à versão FCM lançado neste ramo, ele é considerado uma versão lançada mas em decadência HAL. Por exemplo, o schedulerservice HAL é liberado, mas preterido no Android 12, conforme especificado pelo Android 12framework manifest .

Removido

Para HALs de dispositivo, uma versão de HAL é 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 o framework oferece suporte.

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 as Versões HAL removidas definidas para que os testes VTS possam ser escritos para garantir que HALs removidos não estejam em novos dispositivos.

Para framework HALs, 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 do último branch lançado.

FCMs legados

Target FCM Version legacy é um valor especial para todos os dispositivos não Treble. A FCM legado, compatibility_matrix.legacy.xml , lista os requisitos do quadro em dispositivos legados (ou seja, dispositivos lançado antes do Android 8.0).

Se esse arquivo existir para um FCM com a versão F , qualquer dispositivo não-agudos pode ser atualizado para F desde que seu manifesto dispositivo é compatível com este arquivo. Sua remoção segue o mesmo procedimento que os FCMs para outras versões do FCM de destino (removidos após o número de dispositivos pré-8.0 ativos cair abaixo de um certo limite).

Versões FCM lançadas

A lista de versões FCM divulgados pode ser encontrado em hardware/interfaces/compatibility_matrices .

Para encontrar a versão FCM lançado com uma específica versão Android, consulte Level.h .