Google is committed to advancing racial equity for Black communities. See how.
Questa pagina è stata tradotta dall'API Cloud Translation.
Switch to English

FCM Lifecycle

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

Terminologia

Matrice di compatibilità del framework (FCM) Un file XML che specifica i requisiti del framework sulle implementazioni conformi del fornitore. La matrice di compatibilità è dotata di versione e una nuova versione viene congelata per ogni versione del framework. Ogni versione del framework contiene più FCM.
Versioni FCM piattaforma (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 framework.
Versione FCM di destinazione (V) La versione FCM di destinazione (da S F ), dichiarata esplicitamente nel manifesto del dispositivo, che soddisfa l'implementazione di un fornitore. Un'implementazione del fornitore deve essere generata rispetto a un FCM pubblicato, sebbene possa dichiarare versioni più recenti di HAL nel proprio Device Manifest.
Versione HAL Una versione HAL ha il formato foo@xy , dove foo è il nome HAL e xy è la versione specifica; es. nfc@1.0 , keymaster@3.0 (il prefisso di root, es. android.hardware , è omesso in questo documento).
Manifest del dispositivo Un file XML che specifica le versioni di HAL fornite dall'immagine del fornitore. I contenuti di un manifesto del dispositivo sono vincolati dalla versione FCM di destinazione del dispositivo, ma possono elencare gli HAL strettamente più recenti rispetto al FCM corrispondente a V.

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 (dove f < F ) non viene più modificata.

Per iniziare a sviluppare in una nuova versione F FCM:

  1. Copia l'ultima compatibility_matrix.<F-1>.xml in compatibility_matrix.current.xml .
  2. Aggiorna l'attributo di level nel file a 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.) Su Android nell'attuale versione F 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 che si avviano con Android 8.1 non sono necessari per implementare questo HAL, quindi la seguente voce è stata aggiunta a compatibility_matrix.current.xml (rinominata 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 una versione secondaria da xz a x.(z+1) nell'attuale versione F FCM, se quella versione è:

  • Obbligatorio 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 le opzioni 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 (maggiore)

Durante lo sviluppo, quando un HAL ha un aggiornamento della versione principale all'attuale FCM Versione 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 x.0 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 che si avviano con Android 8.0 e Android 8.1. I dispositivi che si avviano 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é 2.0 HAL è in compatibility_matrix.3.xml con optional="false" , i dispositivi che vengono avviati con Android 9 devono essere forniti con 2.0 HAL.
  • 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é 1.0 HAL è presente in legacy / 1 / 2.xml (versioni precedenti di FCM con cui Android 9 può funzionare) come HAL opzionale, il framework Android 9 può ancora funzionare con 1.0 HAL (che non è considerata una versione HAL rimossa ).

Nuove versioni di 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 il level="F" 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 assicurarti che i dispositivi che si avviano con il framework più recente (in base al livello di API di spedizione) abbiano Target FCM Version 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, la compatibility_matrix.current.xml viene rinominata 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 sulle partizioni prodotto e system_ext viene eseguito rispettivamente dal proprietario di queste immagini. I numeri di versione di FCM sulle partizioni product_ext e system_ext devono essere allineati a quelli sulla partizione di sistema. Simile alle versioni FCM sulla partizione di sistema, la matrice di compatibilità nella versione FCM F nelle partizioni product e system_ext riflette i requisiti su un dispositivo con FCM versione F di destinazione.

Versione HAL deprecata

Il ritiro di una versione HAL è una decisione dello sviluppatore (ad esempio, per gli HAL AOSP, la decisione è Google). Potrebbe accadere quando viene rilasciata una versione HAL superiore (minore o maggiore). Quando un determinato HAL foo@xy è deprecato in FCM Versione F , significa che qualsiasi dispositivo che si avvia con Target FCM Versione V = F o successiva non deve implementare foo alla versione xy o qualsiasi versione precedente a xy . Una versione deprecata di HAL è ancora supportata dal framework per l'aggiornamento dei dispositivi.

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

Rimozione del supporto per le versioni FCM di destinazione

Quando i dispositivi attivi di una determinata versione V FCM di destinazione scendono al di sotto di una determinata soglia, la versione di FCM di destinazione viene rimossa dal set S F della successiva versione del framework. Ciò viene fatto rimuovendo compatibility_matrix.V.xml dalle regole di compilazione (in modo che non sia più installato sull'immagine di sistema) ed eliminando qualsiasi codice che implementa o dipende dalla funzionalità rimossa. I dispositivi con una versione FCM di destinazione al di fuori di S F per una data versione del framework non possono essere aggiornati a quella versione.

Stato della versione HAL

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

Inedito

Se una versione HAL non è in nessuna delle matrici di compatibilità pubblica e congelata, è considerata non rilasciata e probabilmente in fase di sviluppo. Ciò include le versioni di 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 inedito.
  • Il teleportation@1.0 HAL non si trova in nessuna matrice di compatibilità rilasciata ed è anche considerato un HAL inedito.

Rilasciato e attuale

Se una versione HAL si trova in una matrice di compatibilità pubblica e congelata, viene rilasciata. Ad esempio, dopo che la versione 3 di FCM è stata congelata (quando compatibiility_matrix.current.xml viene rinominata in compatibility_matrix.3.xml ) e pubblicata su AOSP, l'HAL health@2.0 è considerata una versione HAL rilasciata e corrente.

Se una versione di 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 di HAL è quella corrente (cioè non deprecata). Ad esempio, le versioni di 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 di HAL rilasciate e correnti.

Rilasciato ma deprecato

Una versione HAL è deprecata se e solo se:

  • Viene 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 è attuale, ma NON deprecato, in Android 9.

Rimosso

Una versione HAL viene rimossa se e solo se:

  • È stato precedentemente rilasciato;
  • Non è in nessuna matrice di compatibilità pubblica e congelata che il framework supporta.

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

FCM legacy

La versione legacy di Target FCM è un valore speciale per tutti i dispositivi non Treble. Il legacy 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 , qualsiasi dispositivo non Treble può essere aggiornato a F condizione che il suo manifesto del dispositivo sia compatibile con questo file. La sua rimozione segue la stessa procedura degli FCM per le altre versioni di Target FCM (rimossi dopo che il numero di dispositivi pre-8.0 attivi scende al di sotto di una certa soglia).

Versioni FCM rilasciate

L'elenco delle versioni FCM rilasciate può essere trovato in hardware/interfaces/compatibility_matrices .

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