Questa pagina è stata tradotta dall'API Cloud Translation.

Ciclo di vita di FCM

Una versione del framework Android ha più matrici di compatibilità del framework (FCM), uno per ogni versione di FCM target aggiornabile, che definiscono il framework può utilizzare e i requisiti della versione FCM target. Nell'ambito di FCM Android ritira e rimuove gli HAL HIDL, poi modifica i file FCM riflettono lo stato della versione HAL.

Per attivare le OTA basate solo su framework nei propri ecosistemi, i partner che estendono le interfacce dei fornitori devono inoltre ritirare e rimuovere gli HAL HIDL usando lo stesso di machine learning.

Terminologia

FCM (Framework Compatibility Matrix): Un file XML che specifica i requisiti del framework per la conformità del fornitore implementazioni. Viene eseguito il controllo delle versioni della matrice di compatibilità e una nuova versione viene bloccato per ogni release del framework. Ogni versione del framework contiene più FCM.
Versioni FCM della 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ù recente di tutti gli FCM in una release del framework.
Versione FCM di destinazione (V): La versione FCM target (da S_F), dichiarata esplicitamente nel dispositivo che un'implementazione del fornitore sia soddisfatta. L'implementazione di un fornitore deve generati in base a un file FCM pubblicato, anche se potrebbe 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 es. nfc@1.0, keymaster@3.0 (il prefisso principale, ad esempio android.hardware è stato omesso in questo documento.)
File manifest del dispositivo: File XML che specificano le versioni HAL del lato dispositivo dell'interfaccia del fornitore tra cui il fornitore e le immagini ODM. I contenuti del file manifest di un dispositivo vincolato 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 ed elencati (obbligatorio o facoltativo) nella matrice di compatibilità del framework (FCM).
Matrice di compatibilità dei dispositivi (DCM): Un file XML che specifica i requisiti del fornitore per il framework conforme implementazioni. Ogni dispositivo contiene un solo DCM.
File manifest del framework: Un file XML che specifica le versioni HAL del lato framework del fornitore che fornisce l'interfaccia utente, tra cui system, system_ext e immagini prodotto. HAL nel il file manifest del framework viene disattivato dinamicamente in base al valore FCM target del dispositivo. .
Framework HAL: HAL elencati come forniti nel file manifest del framework e indicati come obbligatorio o facoltativo nella matrice di compatibilità dei dispositivi (DCM).

Ciclo di vita di FCM nel codebase

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

È previsto che un dispositivo che spedisca la versione di release Android corrispondente Un valore FCM maggiore o uguale al livello equivalente. Ad esempio, un la spedizione del dispositivo con Android 11 avrà in genere il livello FCM 5, ma implementa FCM di livello 6 o superiore, che prevede una serie di requisiti aggiuntivi specificato 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.

Sviluppa in una nuova versione di FCM

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

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

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

Presenta un nuovo HAL

Durante lo sviluppo, durante l'introduzione di un nuovo HAL (Wi-Fi, NFC e così via) su Android sulla versione FCM corrente 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. Dispositivi l'avvio con Android 8.1 non è necessario per implementare questo HAL, quindi la voce seguente è stata aggiunta a compatibility_matrix.F.xml (che in precedenza era denominato compatibility_matrix.current.xml temporaneamente durante lo sviluppo di lancio):

<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 esegue un upgrade di una versione secondaria da x.z a x.(z+1) nella versione corrente di FCM F, se tale versione è:

Obbligatorio sui dispositivi che vengono lanciati con V = F e 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 la facoltatività da compatibility_matrix.<F-1>.xml e cambia la versione in x.w-(z+1) (dove w >= y).

Ad esempio, Android 8.1 ha introdotto broadcastradio@1.1 come versione secondaria di 1.0 HAL. La versione precedente, broadcastradio@1.0, è facoltativa per dispositivi che vengono lanciati con Android 8.0 mentre la versione più recente, broadcastradio@1.1 è facoltativo per i dispositivi che verranno lanciati con Android 8.1. Nella 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 nell'attuale FCM Versione F, la nuova versione principale x.0 è stata aggiunta a compatibility_matrix.F.xml con le seguenti impostazioni di optional:

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

Ad esempio, Android 9 introduce health@2.0 come un l'upgrade della versione principale di 1.0 HAL e ritira la versione 1.0 HAL. Il più vecchio la versione 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 devono: fornisce la nuova versione 2.0. Ad esempio, supponiamo compatibility_matrix.legacy.xml, compatibility_matrix.1.xml e compatibility_matrix.2.xml contengono 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 che 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 con Android 9 deve essere spedito con 2.0 HAL.`
Poiché l'HAL 1.0 non è in compatibility_matrix.3.xml, i dispositivi che vengono lanciati con Android 9 non devono fornire 1.0 HAL (perché questo HAL è considerato obsoleto).
Perché l'HAL 1.0 è presente in legacy/1/2.xml (versioni FCM precedenti che Android 9 può funzionare come HAL facoltativo, la Il framework Android 9 può 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 di Google nell'ambito di una release AOSP e prevede i seguenti passaggi:

Assicurati che compatibility_matrix.F.xml abbia l'attributo level="F".
Assicurati che tutti i dispositivi siano creati e avviati.
Aggiornare i test VTS per garantire che i dispositivi siano lanciati con il framework più recente (in base a livello di API Shipping) hanno la versione FCM target V >= F.
Pubblica il file in AOSP.

Ad esempio, test VTS verifica che i dispositivi che vengono lanciati con Android 9 hanno la versione Target FCM >= 3.

Inoltre, gli FCM product e system_ext possono anche elencare requisiti per ogni versioni FCM della piattaforma. Rilascio di versioni FCM per il prodotto e system_ext vengono eseguite rispettivamente dal proprietario delle immagini. Versione FCM i numeri sul prodotto e le partizioni system_ext devono essere allineati a quelli nella partizione di sistema. Analogamente alle versioni FCM nella partizione di sistema, matrice di compatibilità nella versione F di FCM nelle partizioni product e system_ext riflette i requisiti per i dispositivi con versione FCM di destinazione.

Ritiro della versione HAL

Il ritiro di una versione HAL è una decisione dello sviluppatore (ovvero per gli HAL AOSP, prende la decisione). Può accadere quando una versione HAL più elevata (sia minore o minore, principale).

Ritirare l'HAL di un dispositivo

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

Quando viene rilasciata la versione F di FCM, viene considerata una versione dell'HAL foo@x.y deprecata se la versione dell'HAL specifica non è indicata esplicitamente nella versione più recente FCM per la versione FCM di destinazione V = F. Per i dispositivi che vengono lanciati con V = F, uno dei seguenti le seguenti condizioni sono vere:

Il framework richiede una versione superiore (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 di 1.0 HAL. health@1.0 rimosso da compatibility_matrix.3.xml ma è presente in compatibility_matrix.legacy.xml, compatibility_matrix.1.xml, e compatibilità_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 i dispositivi che vengono lanciati con la versione V = F o successiva di FCM target non devono si aspettano che il framework fornisca foo nella versione x.y o in qualsiasi versione precedente di x.y. Una versione HAL deprecata è ancora fornita dal framework per eseguire l'upgrade dei dispositivi.

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

Ad esempio, in Android 12, schedulerservice@1.0 è ritirato. Il suo attributo max-level è impostato su 5, è stata introdotta la versione FCM in Android 11. Consulta Framework Android 12 del file 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 la versione FCM target viene rimossa dall'S_F impostato del valore della versione successiva del framework. Questa operazione può essere eseguita tramite entrambi i seguenti passaggi:

Rimozione di compatibility_matrix.V.xml dalle regole di build (in modo che non installati nell'immagine di sistema) ed eliminando qualsiasi codice che ha implementato o dipendeva dalle funzionalità rimosse.
Rimozione degli HAL del framework con max-level inferiore o uguale a V dal il file manifest del framework ed eliminando qualsiasi codice che implementa il del framework HAL.

Dispositivi con una versione FCM target esterna a S_F per un determinato framework non è possibile 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 pubblico e bloccata matrici di compatibilità, è considerata inedita e potenzialmente in fase di sviluppo. Sono incluse le versioni HAL solo in compatibility_matrix.F.xml. Esempi:

Durante lo sviluppo di Android 9, health@2.0 HAL è stato considerato un HAL non rilasciato ed era presente solo in compatibility_matrix.3.xml.
L'HAL teleportation@1.0 non è presente in alcuna matrice di compatibilità rilasciata e è considerata anch'essa un HAL non rilasciato.

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

Rilasciata e attuale

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

Se una versione HAL si trova in una matrice di compatibilità pubblica e bloccata che presenta Versione FCM più recente: la versione HAL è attuale (ovvero non deprecata). Per Ad esempio, 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 dell'HAL rilasciate e attuali.

Per gli HAL del framework, se una versione HAL è presente nel file 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 una versione HAL rilasciata e attuale. Ad esempio, L'HAL displayservice viene rilasciato ed è attualmente disponibile in Android 12, come specificato dal Framework Android 12 del file manifest.

Rilascio, ma deprecato

Per gli HAL dei dispositivi, una versione HAL è deprecata soltanto se: sono soddisfatti:

Viene rilasciato.
Non è una matrice di compatibilità pubblica e congelata che ha Versione FCM.
È in una matrice di compatibilità pubblica e congelata che il framework Google Cloud.

Esempi:

L'HAL health@1.0 è in compatibility_matrix.legacy.xml, compatibility_matrix.1.xml e compatibility_matrix.2.xml, ma non in compatibility_matrix.3.xml. Pertanto è considerato deprecato in Android 9.
L'HAL ha un upgrade di versione secondaria in Android 9, ma power@1.0 è ancora in compatibility_matrix.3.xml.
power@1.0 compatibility_matrix.legacy.xml, compatibility_matrix.1.xml e compatibility_matrix.2.xml.
compatibility_matrix.3.xml contiene power@1.0-1.

Di conseguenza power@1.0 è la versione attuale di Android, ma NON è deprecata 9,

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

Rimosso

Per gli HAL dei dispositivi, viene rimossa una versione HAL se e solo se: sono vere:

precedentemente rilasciato.
Non è in alcuna matrice di compatibilità pubblica e congelata che il framework Google Cloud.

Matrici di compatibilità pubbliche, congelate, ma non supportate dai vengono conservati nel codebase per definire le versioni dell'HAL rimosse che i test VTS possano essere scritti per garantire che gli HAL rimossi non vengano inseriti su nuovi dispositivi.

Per le HAL del framework, viene rimossa una versione HAL solo se: soddisfatti:

precedentemente rilasciato.
Non è in alcun 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 Il file FCM precedente, compatibility_matrix.legacy.xml, elenca i requisiti del framework sui dispositivi legacy (ovvero quelli lanciati prima di Android 8.0).

Se questo file esiste per un FCM con versione F, qualsiasi dispositivo non Treble può essere eseguito l'upgrade a F, a condizione che il 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. (rimosso quando il numero di dispositivi attivi precedenti alla versione 8.0 è sceso al di sotto di un determinato ).

Versioni FCM rilasciate

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

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