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

Esta página foi traduzida pela API Cloud Translation.

Ciclo de vida do FCM

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

Para possibilitar OTAs somente de framework nos próprios ecossistemas, os parceiros que estendem também devem descontinuar e remover as HALs HIDL usando a mesma métodos.

Terminologia

Matriz de compatibilidade de framework (FCM, na sigla em inglês): Um arquivo XML que especifica os requisitos do framework sobre o fornecedor em conformidade e implementações. A matriz de compatibilidade tem controle de versão, e uma nova versão congelados para cada versão do framework. Cada versão de framework contém vários FCMs.
Versões do FCM da plataforma (S_F): O conjunto de todas as versões do FCM em uma versão do framework. O framework pode funcionar a qualquer implementação de fornecedor que satisfaç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 de destino do FCM (de S_F), declarada explicitamente no dispositivo que uma implementação do fornecedor satisfaça. A implementação de um fornecedor precisa ser gerados em relação a um FCM publicado, embora possa declarar versões mais recentes da HAL em sua 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 neste documento.)
Manifesto do dispositivo: Arquivos XML que especificam em quais versões da HAL o dispositivo da interface do fornecedor incluindo as imagens do fornecedor e do ODM. O conteúdo do manifesto de um dispositivo é limitadas pela versão de destino do FCM do dispositivo, mas podem listar as HALs que estão estritamente mais recentes em relação à FC correspondente a V.
HALs do dispositivo: HALs listadas (fornecidas) no manifesto do dispositivo e listadas (obrigatório ou opcional) na matriz de compatibilidade do framework (FCM).
Matriz de compatibilidade de dispositivos (DCM): Um arquivo XML que especifica os requisitos do fornecedor em relação ao framework em conformidade e implementações. Cada dispositivo contém um DCM.
Manifesto do framework: Um arquivo XML que especifica para quais versões de HAL o lado do framework do fornecedor interface, incluindo system, system_ext e imagens de produtos. HALs na manifesto do framework são desativados dinamicamente de acordo com o padrão do FCM de destino versão.
HALs de framework: HALs que são listadas conforme fornecidos no manifesto do framework e listadas como obrigatório ou opcional na matriz de compatibilidade do dispositivo (DCM).

Ciclo de vida do FCM na base de código

Neste documento, descrevemos o ciclo de vida do FCM no resumo. Para conferir manifestos compatíveis, consulte hardware/interfaces/compatibility_matrix.<FCM>.xml em que o FCM pode ser encontrado system/libvintf/include/vintf/Level.h.

Espera-se que um dispositivo que envie a versão correspondente do Android tenha um valor do FCM maior ou igual ao nível equivalente. Por exemplo, o envio de dispositivos com o Android 11 geralmente teria o FCM de nível 5, mas implemente FCM de nível 6 ou superior, que vem com vários requisitos adicionais 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.

Desenvolver em uma nova versão do FCM

O Android incrementa a versão do FCM a cada versão do framework (como o Android 8 e 8.1). Durante o desenvolvimento, o novo compatibility_matrix.F.xml é criado, e o compatibility_matrix.f.xml existente (em que f < F) não é mudou.

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

Copiar o compatibility_matrix.<F-1>.xml mais recente para compatibility_matrix.F.xml.
Atualize o atributo level no arquivo para F.
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. Dispositivos lançados com o Android 8.1 não precisam implementar essa HAL. entrada a seguir foi adicionada a compatibility_matrix.F.xml (que era chamada compatibility_matrix.current.xml temporariamente durante o desenvolvimento lançamento):

<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 tem um upgrade de versão secundária de x.z para x.(z+1) na versão atual F do FCM, se ela for:

Obrigatório em dispositivos lançados com V = F e compatibility_matrix.F.xml precisa declarar x.(z+1) e optional="false".
Não é necessário em dispositivos lançados com V = F. 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 versão secundária atualização de 1.0 HAL. A versão mais antiga, broadcastradio@1.0, é opcional para dispositivos lançados com o Android 8.0, enquanto a versão mais recente O 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 uma atualização de versão principal no FCM atual Versão F, a nova versão principal x.0 foi adicionada 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 o modelo O V = F precisa ser iniciado com x.0.
optional="false", mas junto com versões principais mais antigas no mesmo <hal> tag, se os dispositivos que vêm com V = F precisarem ser iniciados com essa HAL, mas poderão iniciar com uma versão principal mais antiga.
optional="true" se os dispositivos que vêm com o V = F não precisarem ser iniciados o HAL.

Por exemplo, o Android 9 introduz a health@2.0 como uma atualização da versão principal da HAL 1.0 e descontinua a HAL 1.0. Os mais antigos health@1.0, é opcional para dispositivos lançados com o Android 8.0 e Android 8.1 Os dispositivos lançados com o Android 9 precisam forneça a nova versão 2.0. Por exemplo, suponha compatibility_matrix.legacy.xml, compatibility_matrix.1.xml e compatibility_matrix.2.xml contêm esta entrada:

<hal format="hidl" optional="true">
    <name>android.hardware.health</name>
    <version>1.0</version>;
    <interface>
        <name>IHealth</name>
        <instance>default</instance>
    </interface>
</hal>

Copie esta entrada para compatibility_matrix.F.xml e modifique como 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 a HAL 2.0 está em compatibility_matrix.3.xml com optional="false", dispositivos que são lançados com o Android 9 deve ser enviado com 2.0 HAL.`
Como a HAL 1.0 não está no compatibility_matrix.3.xml, dispositivos lançados com o Android 9 não devem 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 que o Android 9 pode funcionar) como uma HAL opcional, a 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 é realizado exclusivamente pelo Google como parte de uma versão do AOSP e inclui as seguintes etapas:

Verifique se compatibility_matrix.F.xml tem o atributo level="F".
Garanta que todos os dispositivos sejam criados e inicializados.
Atualizar testes VTS para garantir que os dispositivos sejam lançados com o framework mais recente (baseado no nível da API Shipping) têm a versão desejada do FCM V >= F.
Publicar arquivo no AOSP.

Por exemplo, testes VTS garantir que os dispositivos lançados com o Android 9 têm versão de destino do FCM maior ou igual a 3.

Além disso, os FCMs de produto e system_ext também podem listar os requisitos para cada e versões mais recentes do FCM. Lançamento de versões do FCM no produto e system_ext partições diferentes é feito pelo proprietário dessas imagens, respectivamente. Versão do FCM Os números nas partições produto e system_ext precisam estar alinhados com os 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 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. Por exemplo, para as HALs do AOSP, o Google toma a decisão). Isso pode acontecer quando uma versão da HAL superior (seja pequena ou principal) é lançado.

Descontinuação do uso da HAL de dispositivo

Quando a HAL foo@x.y de um determinado dispositivo for descontinuada na versão F do FCM, isso significa que que os dispositivos iniciados com a versão de destino V = F ou posterior do FCM não podem implementar foo na versão x.y ou qualquer versão anterior a x.y. Um descontinuado A versão da HAL ainda tem suporte do framework para fazer upgrade de dispositivos.

Quando a versão F do FCM é lançada, a versão foo@x.y da HAL é considerada descontinuada se a versão específica da HAL não for explicitamente declarada na versão FCM para a versão de destino V = F do FCM. Para dispositivos lançados com V = F, um dos seguintes condições é 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 é introduzido como uma atualização principal da HAL 1.0. 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 de destino V = F ou posterior do FCM não podem espera que o framework forneça foo na versão x.y ou em qualquer versão anterior de x.y. Uma versão descontinuada da HAL ainda é fornecida pelo framework para fazer o upgrade de dispositivos.

Quando a versão F do FCM é lançada, a versão foo@x.y da HAL é considerada será descontinuado se o manifesto do framework especificar max-level="F - 1" para foo@x.y. Para dispositivos que estão sendo lançados com V = F, o framework não fornece o foo@x.y da HAL. O dispositivo matriz de compatibilidade em dispositivos lançados com V = F não pode listar o framework HALs com max-level < V.

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

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

Quando os dispositivos ativos de uma determinada versão de destino do FCM V ficam abaixo de uma determinada a versão de destino do FCM será removida do S_F definido do na 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 excluindo qualquer código que tenha implementado ou dependiam dos recursos removidos.
Remoção das HALs de framework com max-level menor ou igual a V da manifesto do framework e excluindo qualquer código que implemente a HALs de framework.

Dispositivos com uma versão segmentada do FCM fora do S_F para um determinado framework não podem fazer o upgrade para essa versão.

Status da versão da HAL

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

Inéditos

Para HALs de dispositivo, se uma versão da HAL não estiver em nenhum dos locais públicos e matriz de compatibilidade, ela será considerada ainda 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 era 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. também é considerada uma HAL ainda não lançada.

Para HALs do framework, se uma versão da HAL estiver apenas no manifesto do framework de uma ramificação de desenvolvimento não relacionada, ela é considerada como não lançada.

Liberado e atual

Para HALs de dispositivo, se uma versão da HAL estiver em qualquer compatibilidade pública e congelada matricial, ele é liberado. Por exemplo, depois que a versão 3 do FCM for congelada e publicada para o 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 que a HAL é atual (ou seja, não descontinuada). Para exemplo, versões de HAL existentes (como nfc@1.0 introduzidas no compatibility_matrix.legacy.xml). que continuam a existir em compatibility_matrix.3.xml também são considerados como lançadas e com as versões atuais da HAL.

Para HALs do framework, se uma versão da HAL estiver no manifesto do framework da ramificação mais recente lançada sem o atributo max-level ou, normalmente, uma max-level igual ou superior à versão do FCM lançada nesta ramificação, ela é considerada uma versão lançada e atual da HAL. Por exemplo, o A HAL displayservice já foi lançada e está disponível no Android 12, conforme especificado pela Framework do Android 12 manifesto do app.

Lançado, mas descontinuado

Para HALs de dispositivos, uma versão da HAL será descontinuada somente se todas as sejam atendidos:

Ela é lançada.
Não é na matriz de compatibilidade pública e congelada que tem a maior Versão do FCM.
É em uma matriz de compatibilidade pública e congelada que o framework suporta.

Exemplos:

A HAL health@1.0 está em compatibility_matrix.legacy.xml, compatibility_matrix.1.xml, e compatibility_matrix.2.xml, mas não em compatibility_matrix.3.xml. Por isso, ele é considerado descontinuado em Android 9.
A HAL de energia tem um upgrade de versão secundária no Android 9, mas power@1.0 ainda está em compatibility_matrix.3.xml.
power@1.0 compatibility_matrix.legacy.xml, compatibility_matrix.1.xml, e compatibility_matrix.2.xml.
compatibility_matrix.3.xml tem power@1.0-1.

Portanto, power@1.0 é atual, mas NÃO está obsoleta no Android. 9.

Para HALs do framework, se uma versão da HAL estiver no manifesto do framework da versão ramificação lançada com um atributo max-level menor que a versão de lançamento do FCM nessa ramificação, ela é considerada uma versão da HAL lançada, mas descontinuada. Para exemplo, a HAL schedulerservice foi lançada, mas descontinuada em Android 12, conforme especificado pela Manifesto do framework do Android 12.

Vídeo removido

Para HALs de dispositivo, uma versão de HAL é removida somente se os seguintes são verdadeiras:

Ele já foi lançado.
Não é em nenhuma matriz de compatibilidade pública e congelada que o framework suporta.

Matrizes de compatibilidade que são públicas, congeladas, mas não são compatíveis com a são mantidos na base de código para definir as versões da HAL removidas que foram definidas que os testes VTS possam ser escritos para garantir que as HALs removidas não estejam em dispositivos novos.

Para HALs de framework, uma versão de HAL será removida somente se os itens a seguir forem atendidas:

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. A 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 upgrade para F desde que o manifesto do dispositivo seja compatível com este arquivo. Seu a remoção segue o mesmo procedimento que o FCM para outras versões de destino do FCM. (removido depois que o número de dispositivos ativos com versões anteriores à 8.0 ficar 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