Ciclo di vita FCM

Una versione del framework Android dispone di più Framework Compatibility Matrix (FCM), una per ogni versione di FCM di destinazione aggiornabile, che definiscono ciò che il framework può utilizzare e i requisiti della versione di FCM di destinazione. Come parte del ciclo di vita di FCM, Android depreca 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 dovrebbero anche deprecare e rimuovere gli HAL HIDL usando gli stessi metodi.

Terminologia

Matrice di compatibilità del quadro (FCM) Un file XML che specifica i requisiti del framework per le implementazioni dei fornitori conformi. La matrice di compatibilità ha una versione e una nuova versione viene bloccata per ogni versione 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 qualsiasi implementazione del fornitore che soddisfi uno di questi FCM.
Versione FCM (F) La versione più alta tra tutti gli FCM in una versione del framework.
Versione FCM target (V) La versione FCM di destinazione (da SF ), dichiarata esplicitamente nel manifest del dispositivo, soddisfatta da un'implementazione del fornitore. Un'implementazione del fornitore deve essere generata rispetto a un FCM pubblicato, sebbene possa dichiarare versioni HAL più recenti nel relativo Device Manifest.
Versione HAL Una versione HAL ha il formato foo@xy , dove foo è il nome HAL e xy è la versione specifica; ad esempio nfc@1.0 , keymaster@3.0 (il prefisso di root, ad esempio android.hardware , è omesso in questo documento.)
Manifesto del dispositivo File XML che specificano le versioni HAL fornite dal lato dispositivo dell'interfaccia del fornitore, incluse le immagini del fornitore e dell'ODM. I contenuti di un manifest del dispositivo sono vincolati dalla versione FCM di destinazione del dispositivo, ma possono elencare HAL strettamente più recenti rispetto all'FCM corrispondente a V.
HAL del dispositivo HAL elencati (forniti) nel manifest del dispositivo ed elencati (obbligatorio o facoltativo) nella matrice di compatibilità del framework (FCM).
Matrice di compatibilità del dispositivo (DCM) Un file XML che specifica i requisiti del fornitore sulle implementazioni del framework conformi. Ogni dispositivo contiene un DCM.
Manifesto quadro Un file XML che specifica quali versioni HAL fornisce il lato framework dell'interfaccia del fornitore, incluse le immagini di sistema, system_ext e prodotto. Gli HAL nel manifesto del framework vengono disabilitati dinamicamente in base alla versione FCM di destinazione del dispositivo.
HAL quadro HAL elencati come forniti nel manifesto del framework ed elencati come obbligatori o facoltativi nella matrice di compatibilità dei dispositivi (DCM).

Sviluppo in una nuova versione FCM

Android incrementa la versione FCM per ogni versione del framework (come Android 8, 8.1, ecc.). Durante lo sviluppo, viene creata la nuova compatibility_matrix.current.xml ( F ) e la compatibility_matrix.f.xml esistente.f.xml (dove f < F ) non viene più modificata.

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

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

Presentazione di un nuovo HAL

Durante lo sviluppo, quando si introduce un nuovo HAL (Wi-Fi, NFC, ecc.) in Android sull'attuale versione F di FCM, aggiungere l'HAL a compatibility_matrix.current.xml con le seguenti impostazioni optional :

  • optional="false" se i dispositivi forniti con V = F devono essere avviati con questo HAL,

    O
  • optional="true" se i dispositivi forniti con V = F possono essere avviati senza questo HAL.

Ad esempio, Android 8.1 ha introdotto cas@1.0 come HAL opzionale. I dispositivi avviati con Android 8.1 non sono necessari per implementare questo HAL, quindi la seguente voce è stata aggiunta a compatibility_matrix.current.xml (rinominato in compatibility_matrix.2.xml dopo il rilascio di Android 8.1):

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

Aggiornamento di un HAL (minore)

Durante lo sviluppo, quando un HAL ha un aggiornamento di versione minore da xz a x.(z+1) alla versione FCM corrente F , se tale versione è:

  • Richiesto sui dispositivi che si avviano con V = F , la compatibility_matrix.current.xml deve indicare x.(z+1) e optional="false" .
  • Non richiesto sui dispositivi che si avviano con V = F , la compatibility_matrix.current.xml deve copiare xy-z e l'opzione da compatibility_matrix.<F-1>.xml e modificare la versione in xw-(z+1) (dove w >= y ).

Ad esempio, Android 8.1 ha introdotto broadcastradio@1.1 come aggiornamento della versione minore di 1.0 HAL. La versione precedente, broadcastradio@1.0 , è opzionale per i dispositivi che si avviano con Android 8.0 mentre la versione più recente, broadcastradio@1.1 , è opzionale per i dispositivi che si avviano 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.current.xml (rinominata in compatibility_matrix.2.xml dopo il rilascio di Android 8.1) 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>

Aggiornamento di un HAL (principale)

Durante lo sviluppo, quando un HAL ha un aggiornamento della versione principale alla versione FCM corrente F , la nuova versione principale x.0 viene aggiunta a compatibility_matrix.current.xml con le seguenti impostazioni optional :

  • optional="false" solo con la versione x.0 , se i dispositivi forniti con V = F devono essere avviati 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 essere avviati 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 aggiornamento della versione principale dell'HAL 1.0 e depreca l'HAL 1.0. La versione precedente, health@1.0 , è facoltativa per i dispositivi con Android 8.0 e Android 8.1. I dispositivi avviati con Android 9 non devono fornire il deprecato HAL 1.0 e devono invece fornire la nuova versione 2.0. In 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 viene copiata in compatibility_matrix.current.xml (rinominata in compatibility_matrix.3.xml con la versione di Android 9) 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 avviati con Android 9 devono essere forniti con HAL 2.0.
  • Poiché l'HAL 1.0 non è in compatibility_matrix.3.xml , i dispositivi che si avviano 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 opzionale, il framework Android 9 può ancora funzionare con l'HAL 1.0 (che non è considerata una versione HAL rimossa ).

Nuove versioni FCM

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

  1. Rinomina compatibility_matrix.current.xml in compatibility_matrix.F.xml .
  2. Assicurati che il file abbia l'attributo level="F" .
  3. Modifica le regole di compilazione corrispondenti per riflettere la modifica del nome del file.
  4. Assicurati che tutti i dispositivi vengano compilati e avviati.
  5. Aggiorna i test VTS per garantire che i dispositivi avviati con il framework più recente (basato sul livello di spedizione API) abbiano Target FCM versione V >= F .
  6. Pubblica file su AOSP.

Questo file non può essere modificato una volta rinominato e pubblicato. Ad esempio, durante lo sviluppo di Android 9 vengono creati i seguenti file per hardware/interfaces/compatibility_matrices/ :

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

Quando viene rilasciato Android 9, compatibility_matrix.current.xml viene rinominato in compatibility_matrix.3.xml e i seguenti file vengono creati per hardware/interfaces/compatibility_matrices/ :

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

I test VTS assicurano che i dispositivi che si avviano con Android 9 abbiano la versione FCM di destinazione >= 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 sul prodotto e sulle partizioni system_ext viene eseguito rispettivamente dal proprietario di queste immagini. I numeri di versione di FCM sulle partizioni product e system_ext devono essere allineati a quelli sulla partizione di sistema. Simile alle versioni FCM sulla partizione di sistema, la matrice di compatibilità alla versione FCM F nelle partizioni product e system_ext riflette i requisiti su un dispositivo con la versione FCM di destinazione F.

Deprecazione della versione HAL

La deprecazione di una versione HAL è una decisione dello sviluppatore (ad esempio, per gli HAL AOSP, è Google a prendere la decisione). Potrebbe accadere quando viene rilasciata una versione HAL superiore (minore o maggiore).

Deprecare un dispositivo HAL

Quando un determinato dispositivo HAL foo@xy è deprecato in FCM versione F , significa che qualsiasi dispositivo avviato con Target FCM versione V = F o successiva non deve implementare foo alla versione xy o qualsiasi versione precedente a xy . Una versione HAL obsoleta è ancora supportata dal framework per l'aggiornamento dei dispositivi.

Quando viene rilasciata la versione FCM di FCM, una versione HAL foo@xy è considerata deprecata se la versione HAL specifica non è esplicitamente dichiarata nell'ultimo FCM per la versione FCM di destinazione V = F F Per i dispositivi che si avviano con V = F , è vera 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 aggiornamento della versione principale di 1.0 HAL. 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 . Pertanto, health@1.0 è considerato deprecato.

Deprecare un framework HAL

Quando un determinato framework HAL foo@xy è deprecato in FCM versione F , significa che qualsiasi dispositivo avviato con Target FCM versione V = F o successiva non deve aspettarsi che il framework fornisca foo alla versione xy oa qualsiasi versione precedente a xy . Una versione HAL deprecata è ancora fornita dal framework per l'aggiornamento dei dispositivi.

Quando viene rilasciata la versione F di FCM, una versione HAL foo@xy viene considerata deprecata se il manifest del framework specifica max-level=" F - 1 " per foo@xy . Per i dispositivi avviati con V = F , il framework non fornisce HAL foo@xy . La matrice di compatibilità dei dispositivi sui dispositivi avviati con V = F non deve elencare gli HAL del 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 il manifesto del framework Android 12 .

Rimozione del supporto per le versioni FCM di destinazione

Quando i dispositivi attivi di una determinata versione V di Target FCM scendono al di sotto di una determinata soglia, la versione di Target FCM viene rimossa dal set SF della successiva versione del framework. Questo viene fatto da entrambi i seguenti passaggi:

  • Rimozione di compatibility_matrix.V.xml dalle regole di compilazione (in modo che non sia installato nell'immagine di sistema) ed eliminazione di qualsiasi codice implementato o dipendente dalla funzionalità rimossa.
  • Rimozione degli HAL del framework con max-level inferiore o uguale a V dal manifest del framework ed eliminazione di qualsiasi codice che implementa gli HAL del framework rimossi.

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

Stato della versione HAL

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

Inedito

Per gli HAL del dispositivo, se una versione HAL non è in nessuna delle matrici di compatibilità pubbliche e bloccate, è considerata non rilasciata e probabilmente in fase di sviluppo. Ciò include le versioni HAL che sono solo in compatibility_matrix.current.xml . Esempi:

  • Durante lo sviluppo di Android 9 (prima che compatibiility_matrix.current.xml venisse rinominato in compatibility_matrix.3.xml ), l'HAL health@2.0 era considerato un HAL non rilasciato.
  • Il teleportation@1.0 @ 1.0 HAL non è in nessuna matrice di compatibilità rilasciata ed è anche considerato un HAL non rilasciato.

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

Rilasciato e attuale

Per gli HAL del dispositivo, se una versione HAL è in una matrice di compatibilità pubblica e bloccata, viene rilasciata. Ad esempio, dopo che la versione 3 di FCM è stata bloccata (quando compatibiility_matrix.current.xml viene rinominato in compatibility_matrix.3.xml ) e pubblicata su AOSP, l'HAL health@2.0 è considerato 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ù alta (esclusa la compatibility_matrix.current.xml ), la versione HAL è corrente (cioè non obsoleta). Ad esempio, le versioni HAL esistenti (come nfc@1.0 introdotto in compatibility_matrix.legacy.xml ) che continuano a esistere in compatibility_matrix.3.xml sono anche considerate come versioni HAL rilasciate e correnti.

Per gli HAL del framework, se una versione HAL è 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, è considerata un rilascio e l'attuale versione HAL. Ad esempio, il displayservice HAL è rilasciato e attuale in Android 12, come specificato dal Android 12framework manifest .

Rilasciato ma deprecato

Per gli HAL dei dispositivi, una versione HAL è deprecata se e solo se sono soddisfatte tutte le seguenti condizioni:

  • Viene rilasciato.
  • Non è nella matrice di compatibilità pubblica e bloccata che ha la versione FCM più alta.
  • È in una matrice di compatibilità pubblica e bloccata che il framework supporta ancora.

Esempi:

Quindi power@1.0 è attuale, ma NON deprecato, in Android 9.

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

RIMOSSO

Per gli HAL del dispositivo, una versione HAL viene rimossa se e solo se si verifica quanto segue:

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

Le matrici di compatibilità pubbliche, bloccate, ma non supportate dal framework vengono mantenute nella base di codice per definire le versioni HAL rimosse impostate in modo che i test VTS possano essere scritti per garantire che gli HAL rimossi non si trovino su nuovi dispositivi.

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

  • È stato precedentemente rilasciato.
  • Non è in nessun quadro manifest dell'ultimo ramo rilasciato.

FCM legacy

La versione legacy di FCM target è un valore speciale per tutti i dispositivi non Treble. L'FCM legacy, 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 , qualsiasi dispositivo non Treble può essere aggiornato a F a condizione che il manifesto del dispositivo sia compatibile con questo file. La sua rimozione segue la stessa procedura degli FCM per altre versioni FCM Target (rimossa dopo che il numero di dispositivi attivi precedenti alla 8.0 scende al di sotto di una certa 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 versione Android specifica, vedere Level.h .