Ciclo di vita di FCM

Una versione del framework Android ha più matrici di compatibilità del framework (FCM), una per ogni versione di FCM target aggiornabile, che definiscono cosa può essere utilizzato dal framework e i requisiti della versione FCM target. Nell'ambito del ciclo di vita di FCM, Android ritira e rimuove gli HAL HIDL, quindi modifica i file FCM per riflettere lo stato della versione HAL.

Per abilitare le OTA solo framework nei propri ecosistemi, i partner che estendono le interfacce dei fornitori devono anche ritirare e rimuovere gli HAL HIDL utilizzando gli stessi metodi.

Terminologia

FCM (Framework Compatibility Matrix)
Un file XML che specifica i requisiti del framework per la conformità delle implementazioni dei fornitori. Viene eseguito il controllo delle versioni della matrice di compatibilità e una nuova versione viene bloccata per ogni release del framework. Ogni versione del framework contiene più FCM.
Versioni FCM della piattaforma (SF)
L'insieme di tutte le versioni di FCM in una versione del framework. Il framework può funzionare con implementazioni di qualsiasi fornitore che soddisfino uno di questi FCM.
Versione FCM (F)
La versione più recente di tutti gli FCM in una release del framework.
Versione FCM di destinazione (V)
La versione FCM target (da SF), dichiarata esplicitamente nel manifest del dispositivo, soddisfatta da un'implementazione del fornitore. Un'implementazione del fornitore deve essere generata in base a un FCM pubblicato, anche se potrebbe dichiarare versioni HAL più recenti nel file manifest del dispositivo.
Versione HAL
Una versione HAL ha il formato foo@x.y, dove foo è il nome dell'HAL e x.y è la versione specifica; ad esempio nfc@1.0, keymaster@3.0 (il prefisso radice, ad esempio android.hardware, viene omesso in questo documento).
File manifest del dispositivo
File XML che specificano le versioni HAL fornite dal lato dispositivo dell'interfaccia del fornitore, incluse le immagini del fornitore e ODM. I contenuti di un file manifest del dispositivo sono vincolati dalla versione FCM target del dispositivo, ma possono elencare HAL che sono strettamente più recenti rispetto alla FC corrispondente a V.
HAL per dispositivi
HAL elencati (forniti) nel file manifest del dispositivo e elencati (obbligatori o facoltativi) nel framework di compatibilità Matrix (FCM).
Matrice di compatibilità dei dispositivi (DCM)
Un file XML che specifica i requisiti del fornitore per le implementazioni del framework conforme. Ogni dispositivo contiene un solo DCM.
File manifest del framework
Un file XML che specifica le versioni HAL fornite dal lato del framework dell'interfaccia del fornitore, tra cui system, system_ext e immagini prodotto. Gli HAL nel file manifest del framework vengono disattivati in modo dinamico a seconda della versione Target FCM del dispositivo.
Framework HAL
HAL elencati come forniti nel file manifest del framework e indicati come obbligatori o facoltativi nella matrice di compatibilità dei dispositivi (DCM).

Ciclo di vita FCM nel codebase

Questo documento descrive in astratto il ciclo di vita di FCM. Per vedere i file manifest attualmente supportati, consulta hardware/interfaces/compatibility_matrix.<FCM>.xml, dove è disponibile FCM in system/libvintf/include/vintf/Level.h.

Un dispositivo che spedisce la versione di release Android corrispondente dovrebbe avere un valore FCM maggiore o uguale al livello equivalente. Ad esempio, la spedizione di un dispositivo con Android 11 avrà in genere un livello FCM 5, ma implementa FCM di livello 6 o successivo, che prevede vari requisiti aggiuntivi specificati nelle matrici di compatibilità. I livelli supportati sono:

FCM Versione di 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 Android ritira un livello FCM, questo è ancora supportato per i dispositivi esistenti.

Sviluppare in una nuova versione di FCM

Android incrementa la versione FCM per ogni release del framework (ad es. Android 8, 8.1 e così via). Durante lo sviluppo, viene creata la nuova compatibility_matrix.F.xml e compatibility_matrix.f.xml esistente (dove f < F) non viene più modificata.

Per iniziare a sviluppare in una nuova versione di FCM F:

  1. Copia l'ultima versione di compatibility_matrix.<F-1>.xml in compatibility_matrix.F.xml.
  2. Aggiorna l'attributo level nel file impostandolo su F.
  3. Aggiungi le regole di build corrispondenti per installare questa matrice di compatibilità sul dispositivo.

È disponibile un nuovo HAL

Durante lo sviluppo, quando introduci un nuovo HAL (Wi-Fi, NFC e così via) in Android nell'attuale versione di FCM F, aggiungi l'HAL a compatibility_matrix.F.xml con le seguenti impostazioni di optional:

  • optional="false" se i dispositivi inclusi con V = F devono essere lanciati con questo HAL,
  • optional="true" se i dispositivi con V = F possono essere lanciati senza questo HAL.

Ad esempio, Android 8.1 ha introdotto cas@1.0 come HAL facoltativo. I dispositivi che vengono lanciati con Android 8.1 non sono tenuti a implementare questo HAL, quindi è stata aggiunta la seguente voce a compatibility_matrix.F.xml (che in precedenza si chiamava compatibility_matrix.current.xml temporaneamente durante lo sviluppo di quella release):

<hal format="hidl" optional="true">
    <name>android.hardware.cas</name>
    <version>1.0</version>
    <interface>
        <name>IMediaCasService</name>
        <instance>default</instance>
    </interface>
</hal>

Eseguire l'upgrade di un HAL (minore)

Durante lo sviluppo, quando un HAL presenta un upgrade di una versione secondaria da x.z a x.(z+1) nell'attuale versione di FCM F, se la versione è:

  • Obbligatorio sui dispositivi che vengono lanciati con V = F, compatibility_matrix.F.xml deve indicare x.(z+1) e optional="false".
  • Non obbligatorio sui dispositivi che vengono lanciati con V = F, compatibility_matrix.F.xml deve copiare x.y-z e i valori facoltativi da compatibility_matrix.<F-1>.xml e cambiare la versione in x.w-(z+1) (dove w >= y).

Ad esempio, Android 8.1 ha introdotto broadcastradio@1.1 come upgrade della versione secondaria 1.0 HAL. La versione precedente, broadcastradio@1.0, è facoltativa per i dispositivi con Android 8.0, mentre la nuova versione, broadcastradio@1.1, è facoltativa per i dispositivi che vengono lanciati con Android 8.1. In 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>

Questa voce è stata copiata in compatibility_matrix.F.xml e modificata come segue:

<hal format="hidl" optional="true">
    <name>android.hardware.broadcastradio</name>
    <version>1.0-1</version>
    <interface>
        <name>IBroadcastRadioFactory</name>
        <instance>default</instance>
    </interface>
</hal>

Esegui l'upgrade di un HAL (importante)

Durante lo sviluppo, quando un HAL ha un upgrade della versione principale all'attuale versione FCM F, la nuova versione principale x.0 viene aggiunta a compatibility_matrix.F.xml con le seguenti impostazioni di optional:

  • optional="false" solo con la versione x.0, se i dispositivi vengono forniti con V = F devono essere lanciati con x.0.
  • optional="false", ma insieme alle versioni principali precedenti nello stesso tag <hal>, se i dispositivi forniti con V = F devono essere avviati con questo HAL, ma possono avviarsi con una versione principale precedente.
  • optional="true" se i dispositivi che vengono forniti con V = F non devono avviare l'HAL.

Ad esempio, Android 9 introduce health@2.0 come upgrade della versione principale dell'HAL 1.0 e ritira l'HAL 1.0. La versione precedente, health@1.0, è facoltativa per i dispositivi che vengono lanciati con Android 8.0 e Android 8.1. I dispositivi che vengono lanciati con Android 9 non devono fornire l'HAL 1.0 deprecato, ma devono fornire la nuova versione 2.0. Io 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>

Questa voce è stata copiata in compatibility_matrix.F.xml e modificata come segue:

<hal format="hidl" optional="false">
    <name>android.hardware.health</name>
    <version>2.0</version>
    <interface>
        <name>IHealth</name>
        <instance>default</instance>
    </interface>
</hal>

Restrizioni:

  • Poiché l'HAL 2.0 è in compatibility_matrix.3.xml con optional="false", i dispositivi che vengono lanciati con Android 9 devono essere forniti con l'HAL 2.0.`
  • Poiché l'HAL 1.0 non è in compatibility_matrix.3.xml, i dispositivi che vengono avviati con Android 9 non devono fornire l'HAL 1.0 (perché questo HAL è considerato deprecato).
  • Poiché l'HAL 1.0 è presente in legacy/1/2.xml (versioni FCM precedenti con cui può funzionare Android 9) come HAL facoltativo, il framework Android 9 può comunque funzionare con l'HAL 1.0 (che non è considerata una versione HAL rimossa).

Nuove versioni di FCM

Il processo di rilascio di una versione FCM nella partizione di sistema viene eseguito esclusivamente da Google come parte di una release AOSP e prevede i seguenti passaggi:

  1. Assicurati che compatibility_matrix.F.xml abbia l'attributo level="F".
  2. Assicurati che tutti i dispositivi siano creati e avviati.
  3. Aggiorna i test VTS per assicurarti che i dispositivi lanciati con il framework più recente (in base al livello dell'API Shipping) abbiano la versione FCM target V >= F.
  4. Pubblica il file in AOSP.

Ad esempio, i test VTS assicurano che i dispositivi che vengono lanciati con Android 9 abbiano una versione target FCM >= 3.

Inoltre, gli FCM product e system_ext possono anche elencare i requisiti per ciascuna versione di FCM della piattaforma. Il rilascio delle versioni FCM nelle partizioni product e system_ext viene effettuato rispettivamente dal proprietario di queste immagini. I numeri di versione FCM sulle partizioni product e system_ext devono essere allineati a quelli sulla partizione di sistema. Analogamente alle versioni FCM sulla partizione di sistema, la matrice di compatibilità con FCM versione F nelle partizioni product e system_ext riflette i requisiti su un dispositivo con FCM versione F di destinazione.

Ritiro della versione HAL

Il ritiro di una versione HAL è una decisione dello sviluppatore (ovvero, per gli HAL AOSP, è Google a prendere la decisione). Può accadere quando viene rilasciata una versione HAL superiore (minore o maggiore).

Ritirare l'HAL di un dispositivo

Quando un determinato dispositivo HAL foo@x.y viene deprecato nella versione FCM F, significa che i dispositivi che vengono lanciati con la versione FCM target V = F o successiva non devono implementare foo alla versione x.y o a qualsiasi versione precedente a x.y. Una versione HAL deprecata è ancora supportata dal framework per l'upgrade dei dispositivi.

Quando viene rilasciata la versione F di FCM, una versione dell'HAL foo@x.y viene considerata deprecata se la versione dell'HAL specifica non è indicata esplicitamente nell'ultima versione di FCM di destinazione V = F. Per i dispositivi che vengono avviati con V = F, si verifica una delle seguenti condizioni:

  • Il framework richiede una versione superiore (maggiore o minore);
  • Il framework non richiede più l'HAL.

Ad esempio, in Android 9, health@2.0 viene introdotto come upgrade della versione principale 1.0 HAL. health@1.0 è stato rimosso da compatibility_matrix.3.xml, ma è presente in compatibility_matrix.legacy.xml, compatibility_matrix.1.xml e compatibility_matrix.2.xml. Di conseguenza, health@1.0 è considerato deprecato.

Ritirare un HAL di framework

Quando un determinato framework HAL foo@x.y viene deprecato alla versione F di FCM, significa che qualsiasi dispositivo che viene lanciato con la versione V = F o successiva di FCM di destinazione non deve aspettarsi che il framework fornisca foo nella versione x.y o in qualsiasi versione precedente a x.y. Il framework fornisce comunque una versione HAL deprecata per l'upgrade dei dispositivi.

Quando viene rilasciata la versione F di FCM, una versione dell'HAL foo@x.y viene considerata deprecata se il manifest del framework specifica max-level="F - 1" per foo@x.y. Per i dispositivi che vengono lanciati con V = F, il framework non fornisce l'HAL foo@x.y. La matrice di compatibilità dei dispositivi sui dispositivi che vengono lanciati con V = F non deve elencare gli HAL di framework con max-level < V.

Ad esempio, in Android 12, schedulerservice@1.0 è deprecato. Il suo attributo max-level è impostato su 5, la versione FCM introdotta in Android 11. Vedi File manifest del framework Android 12.

Rimozione del supporto per le versioni FCM target

Quando i dispositivi attivi di una determinata versione di FCM target V scendono al di sotto di una determinata soglia, la versione di FCM target viene rimossa dall'SF impostato della prossima release del framework. Questa operazione può essere eseguita tramite entrambi i seguenti passaggi:

  1. Rimozione di compatibility_matrix.V.xml dalle regole di build (in modo che non sia installata nell'immagine di sistema) ed eliminazione di qualsiasi codice che ha implementato o dipendente dalla funzionalità rimossa.

  2. Rimozione degli HAL del framework con max-level inferiore o uguale a V dal file manifest del framework ed eliminazione di qualsiasi codice che implementa gli HAL del framework rimossi.

I dispositivi con una versione FCM target esterna a SF per una determinata release del framework non possono eseguire l'upgrade a quella release.

Stato versione HAL

Le seguenti sezioni descrivono (in ordine cronologico) i possibili stati di una versione HAL.

Non pubblicate

Per gli HAL dei dispositivi, se una versione HAL non è in nessuna delle matrici di compatibilità pubblica e congelata, viene considerata non rilasciata e potenzialmente in fase di sviluppo. Sono incluse le versioni HAL solo in compatibility_matrix.F.xml. Esempi:

  • Durante lo sviluppo di Android 9, l'HAL health@2.0 era considerato un HAL non ancora rilasciato ed era presente soltanto in compatibility_matrix.3.xml.
  • L'HAL teleportation@1.0 non è presente in alcuna matrice di compatibilità rilasciata ed è inoltre considerato un HAL non rilasciato.

Per gli HAL del framework, se una versione HAL si trova solo nel manifest del framework di un ramo di sviluppo non correlato, viene considerata non rilasciata.

Rilasciata e corrente

Per gli HAL dei dispositivi, se una versione HAL è in una qualsiasi matrice di compatibilità pubblica e bloccata, viene rilasciata. Ad esempio, dopo che la versione 3 di FCM viene bloccata e pubblicata in AOSP, l'HAL health@2.0 viene considerato una versione HAL rilasciata e attuale.

Se una versione HAL si trova in una matrice di compatibilità pubblica e bloccata che ha la versione FCM più alta, la versione HAL è corrente (ovvero non deprecata). Ad esempio, anche le versioni HAL esistenti (come nfc@1.0 introdotte in compatibility_matrix.legacy.xml che continuano a esistere in compatibility_matrix.3.xml sono considerate versioni HAL rilasciate e attuali.

Per gli HAL del framework, se una versione HAL si trova nel manifest del framework dell'ultimo ramo rilasciato senza l'attributo max-level o (insolitamente) un max-level uguale o superiore alla versione FCM rilasciata in questo ramo, viene considerata una versione HAL rilasciata e attuale. Ad esempio, l'HAL displayservice viene rilasciato e aggiornato in Android 12, come specificato dal file manifest del framework Android 12.

Rilascio, ma deprecato

Per gli HAL dei dispositivi, una versione HAL viene deprecata solo se vengono soddisfatte tutte le seguenti condizioni:

  • Viene rilasciato.
  • Non è nella matrice di compatibilità pubblica e bloccata che dispone della versione FCM più elevata.
  • Si trova in una matrice di compatibilità pubblica e bloccata che il framework supporta ancora.

Esempi:

Di conseguenza, in Android 9 l'elemento power@1.0 è aggiornato, ma NON è deprecato.

Per gli HAL del framework, se una versione HAL è nel manifest del framework dell'ultimo ramo rilasciato con un attributo max-level inferiore alla release FCM in questo ramo, viene considerata una versione HAL rilasciata ma deprecata. Ad esempio, l'HAL schedulerservice viene rilasciato, ma deprecato in Android 12, come specificato dal file manifest del framework Android 12.

Elemento rimosso

Per gli HAL dei dispositivi, viene rimossa una versione HAL solo se si verificano le seguenti condizioni:

  • precedentemente rilasciato.
  • Non è in alcuna matrice di compatibilità pubblica e bloccata supportata dal framework.

Le matrici di compatibilità pubbliche, bloccate, ma non supportate dal framework, vengono conservate nel codebase per definire le versioni HAL rimosse impostate in modo che i test VTS possano essere scritti in modo da garantire che gli HAL rimossi non vengano inseriti su nuovi dispositivi.

Per gli HAL del framework, viene rimossa una versione HAL solo se vengono soddisfatti i seguenti criteri:

  • precedentemente rilasciato.
  • Non è in alcun manifest del framework dell'ultimo ramo rilasciato.

FCM precedenti

Il valore precedente della versione FCM target è un valore speciale per tutti i dispositivi non Treble. La versione precedente di FCM, compatibility_matrix.legacy.xml, elenca i requisiti del framework sui dispositivi legacy (ovvero i dispositivi lanciati prima di Android 8.0).

Se questo file esiste per un FCM con versione F, può essere eseguito l'upgrade di qualsiasi dispositivo non Treble a F, a condizione che il relativo file manifest del dispositivo sia compatibile con questo file. La rimozione segue la stessa procedura utilizzata per gli FCM per le altre versioni di FCM di destinazione (rimossa dopo che il numero di dispositivi attivi precedenti alla versione 8.0 è sceso al di sotto di una determinata soglia).

Versioni FCM rilasciate

L'elenco delle versioni FCM rilasciate è disponibile nella sezione hardware/interfaces/compatibility_matrices.

Per trovare la versione FCM rilasciata con una release di Android specifica, visita la pagina Level.h.