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 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 utilizzando gli stessi metodi.
Terminologia
Matrice di compatibilità del framework (FCM) | Un file XML che specifica i requisiti del framework per le implementazioni del fornitore conformi. 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 di HAL più recenti 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:
- Copia l'ultima
compatibility_matrix.<F-1>.xml
incompatibility_matrix.current.xml
. - Aggiorna l'attributo di
level
nel file aF
- 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 conV = F
devono essere avviati con questo HAL,
O -
optional="true"
se i dispositivi forniti conV = 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 minore da xz
a x.(z+1)
all'attuale FCM Versione F
, se quella versione è:
- Obbligatorio sui dispositivi che si avviano con
V = F
, lacompatibility_matrix.current.xml
deve indicarex.(z+1)
eoptional="false"
. - Non richiesto sui dispositivi che si avviano con
V = F
, lacompatibility_matrix.current.xml
deve copiarexy-z
e le opzioni dacompatibility_matrix.<F-1>.xml
e modificare la versione inxw-(z+1)
(dovew >= 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 versionex.0
, se i dispositivi forniti conV = F
devono esserex.0
conx.0
. -
optional="false"
ma insieme alle versioni principali precedenti nello stesso tag<hal>
, se i dispositivi forniti conV = F
devono essere avviati con questo HAL, ma possono essere avviati con una versione principale precedente. -
optional="true"
se i dispositivi forniti conV = 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
conoptional="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:
- Rinomina
compatibility_matrix.current.xml
incompatibility_matrix.F.xml
. - Assicurati che il file abbia il
level="F"
attributolevel="F"
. - Modifica le regole di compilazione corrispondenti per riflettere la modifica del nome del file.
- Assicurati che tutti i dispositivi vengano compilati e avviati.
- Aggiorna i test VTS per garantire che i dispositivi che si avviano con il framework più recente (in base al livello di API di spedizione) abbiano Target FCM versione
V >= F
- 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 FCM sulle partizioni product_ext e system_ext devono essere allineati a quelli sulla partizione di sistema. Analogamente 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
La deprecazione 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 dato 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 HAL deprecata è 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 (principale o secondaria);
- 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
Target FCM scendono al di sotto di una determinata soglia, la versione di Target FCM viene rimossa dal set S F della successiva release del framework. Questo 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 HAL che sono solo in compatibility_matrix.current.xml
. Esempi:
- Durante lo sviluppo di Android 9 (prima che
compatibiility_matrix.current.xml
venisse rinominato incompatibility_matrix.3.xml
), l'HALhealth@2.0
era considerato un HAL inedito. - Il
teleportation@1.0
HAL non è presente 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 compatibility_matrix.3.xml
) e pubblicata su AOSP, l'HAL health@2.0
viene 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 è quella corrente (ovvero 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 considerate anche 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:
- L'HAL
health@1.0
è incompatibility_matrix.legacy.xml
,compatibility_matrix.1.xml
ecompatibility_matrix.2.xml
, ma non incompatibility_matrix.3.xml
. Quindi è considerato deprecato in Android 9. - Il power HAL ha un aggiornamento di versione minore in Android 9, ma
power@1.0
è ancora incompatibility_matrix.3.xml
.-
power@1.0
è incompatibility_matrix.legacy.xml
,compatibility_matrix.1.xml
ecompatibility_matrix.2.xml
. -
compatibility_matrix.3.xml
hapower@1.0-1
.
-
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 mantenute nel codice base 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
.