Ciclo di vita FCM

Una versione del framework Android ha più Framework Compatibility Matrix (FCM), uno per ogni versione aggiornabile di Target FCM, che definiscono cosa può utilizzare il framework e i requisiti della versione di Target FCM. Come parte del ciclo di vita FCM, depreca e rimuove Android HIDL HAL, quindi una modifica dei file FCM per riflettere lo stato della versione HAL .

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

Terminologia

Matrice di compatibilità del framework (FCM) Un file XML che specifica i requisiti del framework sulle implementazioni del fornitore conformi. La matrice di compatibilità è versionata e viene bloccata una nuova versione per ogni versione del framework. Ogni versione del framework contiene più FCM.
Versioni della piattaforma FCM (S F) 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 di destinazione (V) La versione FCM mirata (da S F), ha dichiarato in modo esplicito nel manifesto dispositivo, che un soddisfa implementazione fornitore. Un'implementazione del fornitore deve essere generata rispetto a un FCM pubblicato, sebbene possa dichiarare versioni HAL più recenti nel relativo manifesto del dispositivo.
Versione HAL Un HAL versione ha il formato foo@xy , dove foo è il nome HAL e xy è la versione specifica; es nfc@1.0 , keymaster@3.0 (il prefisso principale, per esempio android.hardware , viene 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 Target FCM del dispositivo ma possono elencare gli HAL che sono strettamente più recenti rispetto all'FCM corrispondente a V.
HAL del dispositivo HAL elencati (forniti) nel manifesto del dispositivo ed elencati (obbligatori o facoltativi) nella matrice di compatibilità del framework (FCM).
Matrice di compatibilità dei dispositivi (DCM) Un file XML che specifica i requisiti del fornitore sulle implementazioni del framework conforme. Ciascun dispositivo contiene un DCM.
Manifesto quadro Un file XML che specifica quali versioni HAL fornisce il lato framework dell'interfaccia del fornitore, inclusi system, system_ext e immagini del prodotto. Gli HAL nel manifesto del framework vengono disabilitati dinamicamente in base alla versione Target FCM del dispositivo.
Framework HAL 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, la nuova compatibility_matrix.current.xml viene creata ( F ) e l'attuale compatibility_matrix.f.xml (dove f < F ) non è più cambiato.

Per iniziare a sviluppare in una nuova versione FCM F :

  1. Copiare l'ultima compatibility_matrix.<F-1>.xml a compatibility_matrix.current.xml .
  2. Aggiornare il level attributo nel file F .
  3. Aggiungi le regole di compilazione corrispondenti per installare questa matrice di compatibilità nel dispositivo.

Presentazione di un nuovo HAL

Durante lo sviluppo, quando si introduce un nuovo HAL (Wi-Fi, NFC, ecc) per Android sul corrente FCM versione F , aggiungere l'HAL per compatibility_matrix.current.xml con i seguenti optional impostazioni:

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

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

Ad esempio, Android 8.1 ha introdotto cas@1.0 come HAL opzionale. I dispositivi di lancio con Android 8.1 non sono tenuti ad implementare questa HAL, quindi la seguente voce è stato aggiunto al compatibility_matrix.current.xml (rinominato in compatibility_matrix.2.xml dopo Android 8.1 rilasciato):

<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 minore della versione da xz a x.(z+1) alla corrente FCM versione F , se tale versione è:

  • Richiesto su dispositivi di lancio con V = F , il compatibility_matrix.current.xml stato mosto x.(z+1) e optional="false" .
  • Non necessario su dispositivi di lancio con V = F , il compatibility_matrix.current.xml deve copiare xy-z e opzionalità da compatibility_matrix.<F-1>.xml e cambiare la versione a xw-(z+1) (dove w >= y ).

Ad esempio, Android 8.1 ha introdotto broadcastradio@1.1 come una versione minore di 1,0 aggiornamento HAL. La versione precedente, broadcastradio@1.0 , è opzionale per i dispositivi di lancio con Android 8.0, mentre la versione più recente, broadcastradio@1.1 , è opzionale per i dispositivi di lancio 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>

Questo articole è stato copiato compatibility_matrix.current.xml (rinominato in compatibility_matrix.2.xml dopo Android 8.1 rilasciato) e modificato 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 (maggiore)

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

  • optional="false" con la versione solo x.0 , se i dispositivi forniti con V = F deve lanciare con x.0 .
  • optional="false" , ma con precedenti versioni maggiori nella stessa <hal> tag, se i dispositivi forniti con V = F deve lanciare con questo HAL, ma può lanciare con una versione più vecchia maggiore.
  • optional="true" se i dispositivi forniti con V = F non devono lanciare l'HAL.

Ad esempio, Android 9 introduce health@2.0 come un importante-versione di aggiornamento del 1.0 HAL e depreca l'HAL 1.0. La versione precedente, health@1.0 , è opzionale per i dispositivi di lancio con Android 8.0 e Android 8.1. I dispositivi che si avviano con Android 9 non devono fornire l'HAL 1.0 deprecato 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 compatibility_matrix.current.xml (rinominato compatibility_matrix.3.xml con Android 9 release) e modificato 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:

  • Perché l'HAL 2.0 è in compatibility_matrix.3.xml con optional="false" dispositivi, che il lancio con Android 9 Spedizione solo con 2.0 HAL.
  • Perché il 1,0 HAL non è in compatibility_matrix.3.xml , dispositivi che lancio con Android 9 non devono fornire la HAL 1.0 (come è considerato questo HAL 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 è considerato 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. Rinominare compatibility_matrix.current.xml a compatibility_matrix.F.xml .
  2. Assicurarsi che il file ha l'attributo level="F" .
  3. Modifica corrispondenti regole di compilazione per riflettere il cambiamento di nome del file.
  4. Assicurati che tutti i dispositivi vengano compilati e avviati.
  5. Aggiornamento VTS test per garantire i dispositivi di lancio con l'ultimo quadro (in base al livello di API Shipping) hanno destinazione FCM Version V >= F .
  6. Pubblica file su AOSP.

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

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

Quando Android 9 viene rilasciato, compatibility_matrix.current.xml viene rinominato compatibility_matrix.3.xml ei seguenti file sono costruiti per hardware/interfaces/compatibility_matrices/ :

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

Test VTS garantire che i dispositivi di lancio con Android 9 hanno destinazione FCM versione> = 3.

Inoltre, gli FCM product e system_ext possono anche elencare i requisiti per ciascuna versione FCM della piattaforma. Il rilascio delle versioni FCM sulle partizioni product e system_ext viene eseguito 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à in FCM versione F nelle partizioni product e system_ext riflette i requisiti su un dispositivo con FCM versione F di destinazione.

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 dato dispositivo HAL foo@xy è sconsigliata in FCM Versione F , significa che qualsiasi dispositivo di lancio con TARGET FCM versione V = F o successiva non deve implementare foo alla versione xy o qualsiasi versione precedente alla xy . Una versione HAL deprecata è ancora supportata dal framework per l'aggiornamento dei dispositivi.

Quando FCM versione F viene rilasciato, un HAL versione foo@xy è considerato deprecato se la specifica HAL versione non è esplicitamente indicato nella recente FCM per Target FCM versione V = F . Per i dispositivi di lancio con V = F , una delle seguenti condizioni:

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

Per esempio, in Android 9, health@2.0 è presentato come un importante aggiornamento versione 1.0 HAL. health@1.0 viene rimosso dal compatibility_matrix.3.xml ma è presente in compatibility_matrix.legacy.xml , compatibility_matrix.1.xml e compatibility_matrix.2.xml . Quindi, health@1.0 è considerato obsoleto.

Deprecare un framework HAL

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

Quando FCM versione F viene rilasciato, un HAL versione foo@xy è considerato deprecato se il quadro manifesto specifica max-level=" F - 1 " per foo@xy . Per i dispositivi di lancio con V = F , il quadro non fornisce la HAL foo@xy . La matrice di compatibilità dispositivo sui dispositivi di lancio con V = F non deve Lista HAL quadro con max-level < V .

Per esempio, in Android 12, schedulerservice@1.0 è deprecato. Il suo max-level attributo è impostato su 5 , la versione FCM introdotto in Android 11. Vedere Android 12 quadro manifesta .

Rimozione del supporto per le versioni Target FCM

Quando i dispositivi attivi di una certa destinazione FCM Versione V goccia sotto di una certa soglia, il Target FCM versione viene rimosso dal set S F della prossima release quadro. Questo viene fatto da entrambi i seguenti passaggi:

  • Rimozione compatibility_matrix.V.xml dalle regole di compilazione (in modo che non è installata l'immagine del sistema su), e l'eliminazione di qualsiasi codice che implementato o dipendeva dalla funzionalità rimosso.
  • Rimozione HAL quadro con max-level inferiore o uguale a V dal manifesto quadro, e l'eliminazione di qualsiasi codice che implementa l'HAL quadro rimossi.

I dispositivi con un target FCM versione al di fuori di S F per una data di rilascio quadro non possono effettuare l'aggiornamento a questa release.

Stato 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 forse in fase di sviluppo. Questo include le versioni HAL che sono solo in compatibility_matrix.current.xml . Esempi:

  • Durante lo sviluppo di Android 9 (prima compatibiility_matrix.current.xml viene rinominato compatibility_matrix.3.xml ), il health@2.0 HAL è stato considerato un HAL inedito.
  • Il teleportation@1.0 HAL non è in alcun matrici di compatibilità rilasciati, ed è anche considerato un HAL inedito.

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

Rilasciato e attuale

Per gli HAL del dispositivo, se una versione HAL si trova in una matrice di compatibilità pubblica e bloccata, viene rilasciata. Ad esempio, dopo FCM versione 3 è bloccata (quando compatibiility_matrix.current.xml viene rinominato compatibility_matrix.3.xml ) e pubblicato per AOSP, il health@2.0 HAL è considerato un rilasciato e la corrente HAL versione.

Se una versione HAL è in una matrice pubblica e la compatibilità ghiacciato che ha il più alto (escludendo FCM versione compatibility_matrix.current.xml ), la versione HAL è corrente (cioè non deprecato). Ad esempio, le versioni HAL esistenti (come nfc@1.0 introdotta in compatibility_matrix.legacy.xml ) che continuano ad esistere in compatibility_matrix.3.xml sono anche considerati come versioni HAL rilasciati e correnti.

Per HAL quadro, se una versione HAL è nel manifesto quadro della più recente ramo rilasciato senza il max-level attributo o (insolitamente) un max-level pari o superiore rispetto alla versione FCM rilasciata in questo ramo, è considerato un rilasciato e l'attuale versione di HAL. Ad esempio, il displayservice HAL viene rilasciato e la corrente in Android 12, come specificato dal Android 12framework manifest .

Rilasciato ma deprecato

Per gli HAL del dispositivo, una versione HAL è deprecata se e solo se vengono soddisfatte tutte le condizioni seguenti:

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

Esempi:

Quindi power@1.0 è in corso, ma NON sconsigliato, in Android 9.

Per HAL quadro, se una versione HAL è nel manifesto quadro della più recente ramo rilasciato con un max-level di attributo inferiore rispetto alla versione FCM rilasciata in questo ramo, è considerato una versione HAL rilasciata ma deprecato. Ad esempio, lo schedulerservice HAL viene rilasciato ma obsoleto in Android 12, come specificato dal Android 12framework manifest .

RIMOSSO

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

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

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

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

  • È stato precedentemente rilasciato.
  • Non è presente in alcun framework manifest dell'ultimo ramo rilasciato.

FCM legacy

L'eredità della versione FCM di destinazione è un valore speciale per tutti i dispositivi non Treble. Il FCM eredità, compatibility_matrix.legacy.xml , elenca i requisiti del quadro su dispositivi legacy (cioè dispositivi lanciato prima di Android 8.0).

Se questo file esiste per un FCM con la versione F , qualsiasi dispositivo non Treble può essere aggiornato a F fornito la sua manifesta dispositivo è compatibile con questo file. La sua rimozione segue la stessa procedura degli FCM per altre versioni di Target FCM (rimossi dopo che il numero di dispositivi attivi pre-8.0 scende al di sotto di una certa soglia).

Versioni FCM rilasciate

L'elenco delle versioni rilasciate FCM, si trova nel hardware/interfaces/compatibility_matrices .

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