Ciclo di vita di FCM

Una release del framework Android ha più matrici di compatibilità del framework (FCM), una per ogni versione FCM target eseguibile in un upgrade, che definiscono cosa può utilizzare il framework e i requisiti della versione FCM target. Nell'ambito del ciclo di vita di FCM, Android ritira e rimuove le HAL HIDL, quindi modifica i file FCM in modo da riflettere lo stato della versione HAL.

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

Terminologia

FCM (Framework Compatibility Matrix)
Un file XML che specifica i requisiti del framework per le implementazioni dei fornitori conformi. La matrice di compatibilità è associata a una versione e una nuova versione viene bloccata per ogni release del framework. Ogni release del framework contiene più FCM.
Versioni FCM della piattaforma (SF)
L'insieme di tutte le versioni di FCM in una release del framework. Il framework può funzionare con qualsiasi implementazione del fornitore che soddisfi uno di questi FCM.
Versione FCM (F)
La versione più recente di tutti gli FCM in una release del framework.
Versione FCM target (V)
La versione FCM target (da SF), dichiarata esplicitamente nel manifest del dispositivo, soddisfatta da un'implementazione del fornitore. L'implementazione di un fornitore deve essere generata in base a un FCM pubblicato, anche se può dichiarare versioni HAL più recenti nel suo 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 principale, ad esempio android.hardware, è omesso in tutto questo documento).
File manifest del dispositivo
File XML che specificano le versioni HAL fornite dal lato del dispositivo dell'interfaccia del fornitore, incluse le immagini del fornitore e dell'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 del dispositivo
HAL elencati (forniti) nel manifest del dispositivo e elencati (obbligatori o facoltativi) nella matrice di compatibilità del framework (FCM).
Device Compatibility Matrix (DCM)
Un file XML che specifica i requisiti del fornitore per le implementazioni di framework conformi. Ogni dispositivo contiene un DCM.
Manifest del framework
Un file XML che specifica le versioni HAL fornite dal lato framework dell'interfaccia del fornitore, tra cui system, system_ext e le immagini dei prodotti. Gli HAL nel file manifest del framework vengono disattivati in modo dinamico a seconda della versione Target FCM del dispositivo.
HAL di framework
HAL elencati come forniti nel manifest del framework e indicati come obbligatori o facoltativi nella matrice di compatibilità del dispositivo (DCM).

Ciclo di vita di FCM nel codebase

Questo documento descrive in modo astratto il ciclo di vita di FCM. Per visualizzare i manifest supportati, consulta hardware/interfaces/compatibility_matrix.<FCM>.xml, dove puoi trovare FCM in system/libvintf/include/vintf/Level.h.

Un dispositivo con la versione di rilascio di 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

Il livello FCM è uguale o successivo al livello API del fornitore.

Quando Android ritira un livello FCM, questo è ancora supportato per i dispositivi esistenti. I dispositivi che hanno come target livelli FCM inferiori sono implicitamente autorizzati a utilizzare gli HAL elencati nei livelli FCM più recenti, a condizione che siano disponibili nel ramo.

Sviluppa in una nuova versione di FCM

Android incrementa la versione FCM per ogni release del framework (ad es. Android 8 e 8.1). Durante lo sviluppo, viene creato il nuovo compatibility_matrix.F.xml e il valore compatibility_matrix.f.xml esistente (dove f < F) non viene più modificato.

Per iniziare a sviluppare in una nuova versione 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 su F.
  3. Aggiungi le regole di compilazione corrispondenti per installare questa matrice di compatibilità sul dispositivo.

Presenta un nuovo HAL

Durante lo sviluppo, quando introduci un nuovo HAL (Wi-Fi, NFC e così via) in Android sulla versione corrente di FCM F, aggiungi l'HAL a compatibility_matrix.F.xml con le seguenti impostazioni 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, pertanto la voce seguente è stata aggiunta a compatibility_matrix.F.xml (che in precedenza era compatibility_matrix.current.xml temporaneamente durante lo sviluppo di questa 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 (secondario)

Durante lo sviluppo, quando un HAL esegue l'upgrade di una versione secondaria da x.z a x.(z+1) con la versione FCM F corrente, se questa versione è:

  • Obbligatorio sui dispositivi che vengono lanciati con V = F, il valore compatibility_matrix.F.xml deve avere lo stato x.(z+1) e optional="false".
  • Non è richiesto sui dispositivi lanciati con V = F, compatibility_matrix.F.xml deve copiare x.y-z e l'opzione da compatibility_matrix.<F-1>.xml e modificare la versione in x.w-(z+1) (dove w >= y).

Ad esempio, Android 8.1 ha introdotto broadcastradio@1.1 come upgrade della versione minore dell'HAL 1.0. La versione precedente, broadcastradio@1.0, è facoltativa per i dispositivi lanciati con Android 8.0, mentre la versione più recente, broadcastradio@1.1, è facoltativa per i dispositivi 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>

Eseguire l'upgrade di un HAL (importante)

Durante lo sviluppo, quando un HAL esegue l'upgrade a una versione principale nella versione F di FCM, la nuova versione principale x.0 viene aggiunta a compatibility_matrix.F.xml con le seguenti impostazioni optional:

  • optional="false" solo con la versione x.0, se i dispositivi 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 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 lanciati con Android 9 devono fornire la nuova versione 2.0. Ad esempio, supponiamo che compatibility_matrix.legacy.xml, compatibility_matrix.1.xml e compatibility_matrix.2.xml contengano questa voce:

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

Copia questa voce in compatibility_matrix.F.xml e modificala 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 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 lanciati con Android 9 non devono fornire l'HAL 1.0 (poiché questo HAL è considerato deprecato).
  • Poiché l'HAL 1.0 è presente in legacy/1/2.xml (versioni FCM precedenti con cui Android 9 può funzionare) 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

La procedura di rilascio di una versione FCM nella partizione di sistema viene eseguita esclusivamente da Google nell'ambito di una release AOSP e include i seguenti passaggi:

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

Ad esempio, i test VTS garantiscono 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. La release delle versioni FCM nelle partizioni product e system_ext viene eseguita rispettivamente dal proprietario di queste immagini. I numeri della versione FCM nelle partizioni product e system_ext devono essere in linea con quelli della partizione system. Analogamente alle versioni di FCM nella partizione di sistema, la matrice di compatibilità nella versione FCM F nelle partizioni product e system_ext riflette i requisiti di un dispositivo con la versione FCM F di destinazione.

Ritiro della versione HAL

Il ritiro di una versione HAL è una decisione dello sviluppatore (ad es. per gli HAL AOSP, la decisione spetta a Google). Ciò può accadere quando viene rilasciata una versione HAL successiva (minor o major).

Rifiutare un HAL del dispositivo

Quando un determinato HAL del dispositivo foo@x.y viene ritirato nella versione FCM F, significa che qualsiasi dispositivo lanciato con la versione FCM di destinazione V = F o successiva non deve implementare foo nella versione x.y o in una versione precedente a x.y. Una versione HAL ritirata è 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 lanciati con V = F, è vera una delle seguenti condizioni:

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

Ad esempio, in Android 9 viene introdotto health@2.0 come upgrade della versione principale dell'HAL 1.0. health@1.0 viene 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 HAL del framework foo@x.y viene ritirato nella versione FCM F, significa che qualsiasi dispositivo lanciato con la versione FCM di destinazione V = F o successiva non deve aspettarsi che il framework fornisca foo nella versione x.y o in una versione precedente a x.y. Il framework fornisce ancora 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 lanciati con V = F, il framework non fornisce l'HAL foo@x.y. La matrice di compatibilità dei dispositivi sui dispositivi lanciati con V = F non deve elencare le HAL del framework con max-level < V.

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

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. Questo viene fatto seguendo entrambi i passaggi che seguono:

  1. Rimuovi compatibility_matrix.V.xml dalle regole di compilazione (in modo che non venga installato nell'immagine di sistema) ed elimina qualsiasi codice che abbia implementato o dependa dalle funzionalità rimosse.

  2. Rimuovere dal manifest del framework le HAL di framework con max-level inferiore o uguale a V ed eliminare qualsiasi codice che implementi le HAL di framework rimosse.

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

Stato versione HAL

Le sezioni seguenti 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 disponibili 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 solo in compatibility_matrix.3.xml.
  • L'HAL teleportation@1.0 non è presente in nessuna matrice di compatibilità rilasciata ed è anche considerato un HAL non rilasciato.

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

Rilasciato e attuale

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 è stata bloccata e pubblicata in AOSP, l'HAL health@2.0 è considerata una versione HAL rilasciata e corrente.

Se una versione HAL si trova in una matrice di compatibilità pubblica e bloccata che ha la versione FCM più recente, la versione HAL è corrente (ovvero non è deprecata). Ad esempio, le versioni HAL esistenti (ad esempio nfc@1.0 introdotta in compatibility_matrix.legacy.xml) che continuano a esistere in compatibility_matrix.3.xml sono considerate anche come 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.

Rilasciato, ma deprecato

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

  • Viene rilasciato.
  • Non è presente nella matrice di compatibilità pubblica e bloccata con la versione FCM più recente.
  • 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 del ramo di release più recente con un attributo max-level inferiore alla versione FCM rilasciata in questo ramo, è considerata una versione HAL rilasciata, ma deprecata. Ad esempio, l'HAL schedulerservice è stato rilasciato, ma è deprecato in Android 12, come specificato dal manifest del framework Android 12.

Rimosso

Per gli HAL del dispositivo, una versione HAL viene rimossa se e solo se le seguenti condizioni sono vere:

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

Le matrici di compatibilità pubbliche e bloccate, ma non supportate dal framework, vengono conservate nella base di codice per definire l'insieme delle versioni HAL rimosse in modo da poter scrivere i test VTS per garantire che gli HAL rimossi non siano presenti sui nuovi dispositivi.

Per gli HAL di framework, una versione HAL viene rimossa se e solo se vengono soddisfatti i seguenti requisiti:

  • È stato rilasciato in precedenza.
  • Non è presente in nessun manifest del framework dell'ultimo ramo rilasciato.

FCM precedenti

La versione precedente di FCM di destinazione è 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 la versione F, è possibile eseguire l'upgrade a F di qualsiasi dispositivo non Treble, a condizione che il manifest del dispositivo sia compatibile con questo file. La sua rimozione segue la stessa procedura delle notifiche push per le altre versioni di FCM target (vengono rimosse quando il numero di dispositivi pre-8.0 attivi scende al di sotto di una determinata soglia).

Versioni FCM rilasciate

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

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