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 (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ù recente di tutti gli FCM in una release del framework.
- Versione FCM di destinazione (V)
- La versione FCM target (da SF), 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
, dovefoo
è il nome dell'HAL ex.y
è la versione specifica. ad es.nfc@1.0
,keymaster@3.0
(il prefisso principale, ad esempioandroid.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 attuali
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,
8, 1 e così via). Durante lo sviluppo, viene creata la nuova compatibility_matrix.F.xml
compatibility_matrix.f.xml
esistente (dove f
< F
) non è più modificato.
Per iniziare a sviluppare in una nuova versione di FCM F
:
- Copia l'ultima versione di
compatibility_matrix.<F-1>.xml
incompatibility_matrix.F.xml
. - Aggiorna l'attributo
level
nel file impostandolo suF
. - 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 conV = F
devono essere lanciati con questo HAL,optional="true"
se i dispositivi conV = F
possono essere lanciati senza questo HAL.
Ad esempio, Android 8.1 ha introdotto cas@1.0
come HAL facoltativo. Lancio dei dispositivi
con Android 8.1 non sono necessari per implementare questo HAL, quindi la voce che segue è
aggiunto a compatibility_matrix.F.xml
(che in precedenza si chiamava
compatibility_matrix.current.xml
temporaneamente durante lo sviluppo della release):
<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
ecompatibility_matrix.F.xml
deve indicarex.(z+1)
eoptional="false"
. - Non obbligatorio sui dispositivi che vengono lanciati con
V = F
.compatibility_matrix.F.xml
deve copiarex.y-z
e la facoltatività dacompatibility_matrix.<F-1>.xml
e cambia la versione inx.w-(z+1)
(dovew >= 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 versionex.0
, se i dispositivi vengono forniti conV = F
deve essere avviato conx.0
.optional="false"
ma insieme alle versioni principali precedenti nello stesso<hal>
tag, se i dispositivi inclusi conV = F
devono essere lanciati con questo HAL, ma possono lanciare con una versione principale precedente.optional="true"
se non è necessario avviare i dispositivi conV = 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:
non fornisce l'HAL 1.0 deprecato e deve invece fornire la nuova versione 2.0.
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 è stata copiata in compatibility_matrix.F.xml
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:
- Perché l'HAL 2.0 è in
compatibility_matrix.3.xml
conoptional="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'attributolevel="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
viene deprecato alla 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'SF 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 aV
dal il file manifest del framework ed eliminando qualsiasi codice che implementa il del framework HAL.
Dispositivi con una versione FCM target esterna a SF 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 incompatibility_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
è incompatibility_matrix.legacy.xml
,compatibility_matrix.1.xml
, ecompatibility_matrix.2.xml
, ma non incompatibility_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 incompatibility_matrix.3.xml
. power@1.0
compatibility_matrix.legacy.xml
,compatibility_matrix.1.xml
, ecompatibility_matrix.2.xml
.compatibility_matrix.3.xml
contienepower@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
Il valore precedente della versione FCM target è 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 nella sezione
hardware/interfaces/compatibility_matrices
Per trovare la versione FCM rilasciata con una specifica release di Android, consulta:
Level.h