Le due coppie di matrici di compatibilità e manifest sono pensate per essere riconciliate per verificare che l'implementazione del framework e del fornitore possano funzionare insieme. Questa verifica ha esito positivo se la matrice di compatibilità del framework e il manifest del dispositivo corrispondono, così come il manifest del framework e la matrice di compatibilità del dispositivo.
Questa verifica viene eseguita in fase di compilazione, in fase di generazione del pacchetto di aggiornamento OTA, in fase di avvio e nei test di compatibilità VTS.
Le sezioni seguenti descrivono in dettaglio le regole di corrispondenza utilizzate da vari componenti.
Corrispondenze delle versioni della matrice di compatibilità del framework
Per abbinare un manifest del dispositivo a una matrice di compatibilità del framework,
la versione di FCM di spedizione specificata da manifest.target-level
deve essere esattamente uguale alla versione di FCM specificata da
compatibility-matrix.level
. In caso contrario, non ci sarà alcuna corrispondenza.
Quando la matrice di compatibilità del framework viene richiesta con libvintf
, questa corrispondenza
ha sempre esito positivo perché libvintf
apre il manifest del dispositivo, recupera la versione FCM di spedizione e restituisce la matrice di compatibilità del framework in quella versione FCM di spedizione (più alcuni HAL facoltativi delle matrici di compatibilità nelle versioni FCM più recenti).
Partite HAL
La regola di corrispondenza HAL identifica le versioni degli elementi hal
in un file manifest considerate supportate dal proprietario della matrice di compatibilità corrispondente.
HAL HIDL e nativi
Le regole di corrispondenza per HIDL e HAL nativi sono le seguenti:
- Più elementi
<hal>
vengono valutati con una singola relazione AND. - Gli elementi
<hal>
possono avere<hal optional="true">
per contrassegnarli come non obbligatori. - Più elementi
<version>
all'interno dello stesso elemento<hal>
hanno la relazione OR. Se ne vengono specificate due o più, è necessario implementare solo una delle versioni. (Vedi Corrispondenza HAL riuscita per il modulo DRM.) - Più elementi
<instance>
e<regex-instance>
all'interno dello stesso elemento<hal>
vengono valutati con una singola relazione AND quando<hal>
è obbligatorio. (Vedi Corrispondenza HAL riuscita per il modulo DRM.)
Esempio: corrispondenza HAL riuscita per un modulo
Per un HAL alla versione 2.5, la regola di corrispondenza è la seguente:
Matrice | Manifest corrispondente |
---|---|
2.5 |
2.5-2.∞. Nella matrice di compatibilità, 2.5 è l'abbreviazione di
2.5-5 . |
2.5-7 |
2.5-2.∞. Indica quanto segue:
2.5-7 nella matrice di compatibilità. |
Esempio: corrispondenza HAL riuscita per il modulo DRM
La matrice di compatibilità del framework indica le seguenti informazioni sulla versione per DRM HAL:
<hal> <name>android.hardware.drm <version>1.0</version> <version>3.1-2</version> <interface> <name>IDrmFactory</name> <instance>default</instance> <instance>specific</instance> </interface> </hal> <hal> <name>android.hardware.drm <version>2.0</version> <interface> <name>ICryptoFactory</name> <instance>default</instance> <regex-instance>[a-z]+/[0-9]+</regex-instance> </interface> </hal>
Un fornitore deve implementare UNA delle seguenti istanze:
android.hardware.drm@1.x::IDrmFactory/default // where x >= 0 android.hardware.drm@1.x::IDrmFactory/specific // where x >= 0
OPPURE:
android.hardware.drm@3.y::IDrmFactory/default // where y >= 1 android.hardware.drm@3.y::IDrmFactory/specific // where y >= 1
E deve implementare tutte queste istanze:
android.hardware.drm@2.z::ICryptoFactory/default // where z >= 0 android.hardware.drm@2.z::ICryptoFactory/${INSTANCE} // where z >= 0 and ${INSTANCE} matches [a-z]+/[0-9]+ // e.g. legacy/0
HAL AIDL
Android e versioni successive supportano le versioni per gli HAL AIDL in VINTF.
Le regole di corrispondenza per le HAL AIDL sono simili a quelle delle HAL HIDL e native, tranne per il fatto che
non esistono versioni principali ed esiste esattamente una versione per istanza HAL (1
se
la versione non è specificata):
- Più elementi
<hal>
vengono valutati con una singola relazione AND. - Gli elementi
<hal>
possono avere<hal optional="true">
per contrassegnarli come non obbligatori. - Più elementi
<instance>
e<regex-instance>
all'interno dello stesso<hal>
vengono valutati con una singola relazione AND quando<hal>
è obbligatorio. (Vedi Corrispondenza HAL riuscita per più moduli.)
Esempio: corrispondenza HAL riuscita per un modulo
Per un HAL alla versione 5, la regola di corrispondenza è la seguente:
Matrice | Manifest corrispondente |
---|---|
5 |
5-∞. Nella matrice di compatibilità, 5 è l'abbreviazione di
5-5 . |
5-7 |
5-∞. Indica quanto segue:
5-7 nella matrice di compatibilità. |
Esempio: corrispondenza HAL riuscita per più moduli
La matrice di compatibilità del framework indica le seguenti informazioni sulla versione per gli HAL di vibrazione e fotocamera:
<hal> <name>android.hardware.vibrator <version>1-2</version> <interface> <name>IVibrator</name> <instance>default</instance> <instance>specific</instance> </interface> </hal> <hal> <name>android.hardware.camera <version>5</version> <interface> <name>ICamera</name> <instance>default</instance> <regex-instance>[a-z]+/[0-9]+</regex-instance> </interface> </hal>
Un fornitore deve implementare tutte queste istanze:
android.hardware.vibrator.IVibrator/default // version >= 1 android.hardware.vibrator.IVibrator/specific // version >= 1 android.hardware.camera.ICamera/default // version >= 5 android.hardware.camera.ICamera/${INSTANCE} // with version >= 5, where ${INSTANCE} matches [a-z]+/[0-9]+ // e.g. legacy/0
Corrispondenze del kernel
La sezione <kernel>
della matrice di compatibilità del framework
descrive i requisiti del framework del kernel Linux sul dispositivo. Queste
informazioni devono essere confrontate con le
informazioni
sul kernel segnalate dall'oggetto VINTF del dispositivo.
Corrispondenza dei rami del kernel
Ogni suffisso del ramo del kernel (ad esempio 5.4-r
) viene mappato a una
versione FCM del kernel univoca (ad esempio 5). La mappatura è la stessa della mappatura tra le lettere di rilascio (ad esempio R) e le versioni di FCM (ad esempio 5).
I test VTS impongono che il dispositivo specifichi esplicitamente la versione FCM del kernel nel manifest del dispositivo, /vendor/etc/vintf/manifest.xml
, se è vera una delle seguenti condizioni:
-
La versione FCM del kernel è diversa dalla versione FCM di destinazione. Ad esempio, il
dispositivo menzionato in precedenza ha una versione FCM di destinazione 4 e la sua versione FCM del kernel è 5 (suffisso del ramo
del kernel
r
). -
La versione FCM del kernel è maggiore o uguale a 5 (suffisso del ramo del kernel
r
).
I test VTS impongono che, se viene specificata la versione FCM del kernel, questa sia maggiore o uguale alla versione FCM di destinazione nel manifest del dispositivo.
Esempio: determinare il ramo del kernel
Se il dispositivo ha come target la versione 4 di FCM (rilasciata in Android 10), ma
esegue il kernel del ramo 4.19-r
, il manifest del dispositivo deve specificare quanto segue:
<manifest version="2.0" type="device" target-level="4"> <kernel target-level="5" /> </manifest>
L'oggetto VINTF verifica la compatibilità del kernel rispetto ai requisiti del ramo del kernel 4.19-r
, specificato nella versione 5 di FCM. Questi requisiti sono creati a partire da
kernel/configs/r/android-4.19
nell'albero delle origini di Android.
Esempio: determinare il ramo del kernel per GKI
Se il dispositivo utilizza l'immagine del kernel generico (GKI) e la stringa di rilascio del kernel da
/proc/version
è la seguente:
5.4.42-android12-0-00544-ged21d463f856
Successivamente, l'oggetto VINTF ottiene la release di Android dalla release del kernel e la utilizza per determinare
la versione FCM del kernel. In questo esempio, android12
indica la versione 6 di FCM del kernel
(rilasciata in Android 12).
Per informazioni dettagliate su come viene analizzata la stringa di rilascio del kernel, vedi Controllo delle versioni di GKI.
Corrispondenza delle versioni del kernel
Una matrice può includere più sezioni <kernel>
, ognuna con
un attributo version
diverso utilizzando il formato:
${ver}.${major_rev}.${kernel_minor_rev}
L'oggetto VINTF considera solo la sezione <kernel>
dell'FCM con la versione FCM corrispondente con lo stesso ${ver}
e ${major_rev}
del kernel del dispositivo (ovvero version="${ver}.${major_rev}.${matrix_minor_rev}")
); le altre sezioni vengono ignorate. Inoltre, la revisione secondaria del kernel deve essere un valore
della matrice di compatibilità (${kernel_minor_rev} >=
${matrix_minor_rev}
). Se nessuna sezione <kernel>
soddisfa
questi requisiti, non c'è corrispondenza.
Esempio: seleziona i requisiti per la corrispondenza
Considera il seguente caso ipotetico in cui i file FCM in /system/etc/vintf
dichiarano
i seguenti requisiti (i tag di intestazione e piè di pagina sono omessi):
<!-- compatibility_matrix.3.xml --> <kernel version="4.4.107" level="3"/> <!-- See kernel/configs/p/android-4.4/ for 4.4-p requirements --> <kernel version="4.9.84" level="3"/> <!-- See kernel/configs/p/android-4.9/ for 4.9-p requirements --> <kernel version="4.14.42" level="3"/> <!-- See kernel/configs/p/android-4.14/ for 4.14-p requirements --> <!-- compatibility_matrix.4.xml --> <kernel version="4.9.165" level="4"/> <!-- See kernel/configs/q/android-4.9/ for 4.9-q requirements --> <kernel version="4.14.105" level="4"/> <!-- See kernel/configs/q/android-4.14/ for 4.14-q requirements --> <kernel version="4.19.42" level="4"/> <!-- See kernel/configs/q/android-4.19/ for 4.19-q requirements --> <!-- compatibility_matrix.5.xml --> <kernel version="4.14.180" level="5"/> <!-- See kernel/configs/r/android-4.14/ for 4.14-r requirements --> <kernel version="4.19.123" level="5"/> <!-- See kernel/configs/r/android-4.19/ for 4.19-r requirements --> <kernel version="5.4.41" level="5"/> <!-- See kernel/configs/r/android-5.4/ for 5.4-r requirements -->
La versione FCM di destinazione, la versione FCM del kernel e la versione del kernel selezionano insieme i requisiti del kernel dagli FCM:
Versione FCM di destinazione | Versione FCM del kernel | Versione kernel | Corrispondenza con |
---|---|---|---|
3 (R) | Non specificato | 4.4.106 | Nessuna corrispondenza (mancata corrispondenza della versione secondaria) |
3 (R) | Non specificato | 4.4.107 | 4.4-p |
3 (R) | Non specificato | 4.19.42 | 4.19-q (vedi la nota dopo la tabella) |
3 (R) | Non specificato | 5.4.41 | 5.4-r (vedi la nota dopo la tabella) |
3 (R) | 3 (R) | 4.4.107 | 4.4-p |
3 (R) | 3 (R) | 4.19.42 | Nessuna corrispondenza (nessun ramo del kernel 4.19-p ) |
3 (R) | 4 (T) | 4.19.42 | 4.19-q |
4 (T) | Non specificato | 4.4.107 | Nessuna corrispondenza (nessun ramo del kernel 4.4-q ) |
4 (T) | Non specificato | 4.9.165 | 4.9-q |
4 (T) | Non specificato | 5.4.41 | 5.4-r (vedi la nota dopo la tabella) |
4 (T) | 4 (T) | 4.9.165 | 4.9-q |
4 (T) | 4 (T) | 5.4.41 | Nessuna corrispondenza (nessun ramo del kernel 5.4-q ) |
4 (T) | 5 (R) | 4.14.105 | 4.14-r |
4 (T) | 5 (R) | 5.4.41 | 5.4-r |
5 (R) | Non specificato | qualsiasi | VTS non riesce (deve specificare la versione FCM del kernel per la versione FCM di destinazione 5) |
5 (R) | 4 (T) | qualsiasi | VTS fails (kernel FCM version < target FCM version) |
5 (R) | 5 (R) | 4.14.180 | 4.14-r |
Configurazioni del kernel corrispondenti
Se la sezione <kernel>
corrisponde, il processo continua
tentando di abbinare gli elementi config
a
/proc/config.gz
. Per ogni elemento di configurazione nella matrice di compatibilità, cerca /proc/config.gz
per verificare se la configurazione è presente. Quando un elemento di configurazione è impostato su n
nella matrice di compatibilità per la sezione <kernel>
corrispondente, deve essere assente da /proc/config.gz
. Infine, un elemento di configurazione non presente nella
matrice di compatibilità potrebbe essere presente o meno in /proc/config.gz
.
Esempio: corrispondenza delle configurazioni del kernel
<value type="string">bar</value>
corrispondenze"bar"
. Le virgolette sono omesse nella matrice di compatibilità, ma sono presenti in/proc/config.gz
.<value type="int">4096</value>
corrisponde a4096
,0x1000
o0X1000
.<value type="int">0x1000</value>
corrisponde a4096
,0x1000
o0X1000
.<value type="int">0X1000</value>
corrisponde a4096
,0x1000
o0X1000
.<value type="tristate">y</value>
corrispondenzey
.<value type="tristate">m</value>
corrispondenzem
.<value type="tristate">n</value>
significa che l'elemento di configurazione NON deve esistere in/proc/config.gz
.<value type="range">1-0x3</value>
corrisponde a1
,2
o3
o all'equivalente esadecimale.
Esempio: corrispondenza del kernel riuscita
Una matrice di compatibilità del framework con FCM versione 1 contiene le seguenti informazioni sul kernel:
<kernel version="4.14.42"> <config> <key>CONFIG_TRI</key> <value type="tristate">y</value> </config> <config> <key>CONFIG_NOEXIST</key> <value type="tristate">n</value> </config> <config> <key>CONFIG_DEC</key> <value type="int">4096</value> </config> <config> <key>CONFIG_HEX</key> <value type="int">0XDEAD</value> </config> <config> <key>CONFIG_STR</key> <value type="string">str</value> </config> <config> <key>CONFIG_EMPTY</key> <value type="string"></value> </config> </kernel>
Viene abbinato prima il ramo del kernel. Il ramo del kernel è specificato nel manifest del dispositivo
in manifest.kernel.target-level
, il cui valore predefinito è manifest.level
se il primo non è specificato:
- Se il ramo del kernel nel manifest del dispositivo è 1, la procedura passa al passaggio successivo e controlla la versione del kernel.
- Se il ramo del kernel nel manifest del dispositivo è 2, non esiste una corrispondenza con la matrice. VINTF objects read the kernel requirements from the matrix at FCM version 2 instead.
A questo punto, viene abbinata la versione del kernel. Se un dispositivo in uname()
segnala:
- 4.9.84 (nessuna corrispondenza con la matrice, a meno che non esista una sezione del kernel separata con
<kernel version="4.9.x">
, dovex <= 84
) - 4.14.41 (nessuna corrispondenza con la matrice, inferiore a
version
) - 4.14.42 (corrispondenza con la matrice)
- 4.14.43 (corrispondenza con la matrice)
- 4.1.22 (nessuna corrispondenza con la matrice, a meno che non esista una sezione del kernel separata
con
<kernel version="4.1.x">
, dovex <= 22
)
Dopo aver selezionato la sezione <kernel>
appropriata, per
ogni elemento <config>
con un valore diverso da n
,
la voce corrispondente deve essere presente in /proc/config.gz
;
per ogni elemento <config>
con valore n
,
la voce corrispondente non deve essere presente in /proc/config.gz
.
Il contenuto di <value>
deve corrispondere esattamente al testo dopo il segno uguale (incluse le virgolette), fino al carattere di nuova riga o #
, con gli spazi vuoti iniziali e finali troncati.
La seguente configurazione del kernel è un esempio di corrispondenza riuscita:
# comments don't matter CONFIG_TRI=y # CONFIG_NOEXIST shouldn't exist CONFIG_DEC = 4096 # trailing comments and whitespaces are fine CONFIG_HEX=57005 # 0XDEAD == 57005 CONFIG_STR="str" CONFIG_EMPTY="" # empty string must have quotes CONFIG_EXTRA="extra config items are fine too"
La seguente configurazione del kernel è un esempio di corrispondenza non riuscita:
CONFIG_TRI="y" # mismatch: quotes CONFIG_NOEXIST=y # mismatch: CONFIG_NOEXIST exists CONFIG_HEX=0x0 # mismatch; value doesn't match CONFIG_DEC="" # mismatch; type mismatch (expect int) CONFIG_EMPTY=1 # mismatch; expects "" # mismatch: CONFIG_STR is missing
Corrispondenze SEPolicy
SEPolicy richiede le seguenti corrispondenze:
<sepolicy-version>
definisce un intervallo chiuso di versioni secondarie per ogni versione principale. La versione di SEPolicy segnalata dal dispositivo deve rientrare in uno di questi intervalli per essere compatibile con il framework. Le regole di corrispondenza sono simili alle versioni HAL: la corrispondenza si verifica se la versione di SEPolicy è maggiore o uguale alla versione minima per l'intervallo. La versione massima è puramente informativa.<kernel-sepolicy-version>
, ovvero la versione del database delle policy, deve essere inferiore asecurity_policyvers()
segnalato dal dispositivo.
Esempio: corrispondenza riuscita di SEPolicy
La matrice di compatibilità del framework indica le seguenti informazioni SEPolicy:
<sepolicy> <kernel-sepolicy-version>30</kernel-sepolicy-version> <sepolicy-version>25.0</sepolicy-version> <sepolicy-version>26.0-3</sepolicy-version> </sepolicy>
Sul dispositivo:
- Il valore restituito da
security_policyvers()
deve essere maggiore o uguale a 30. In caso contrario, non si tratta di una corrispondenza. Ad esempio:- Se un dispositivo restituisce 29, non corrisponde.
- Se un dispositivo restituisce 31, la corrispondenza è esatta.
- La versione di SEPolicy deve essere compresa tra 25.0 e ∞ o tra 26.0 e ∞. In caso contrario, non
corrisponde. Il valore
-3
dopo26.0
è puramente informativo.
Corrispondenze delle versioni AVB
La versione AVB contiene una versione MAJOR e una versione MINOR, con il formato MAJOR.MINOR (ad esempio, 1.0, 2.1). Per maggiori dettagli, consulta Controllo delle versioni e compatibilità. La versione AVB ha le seguenti proprietà di sistema:
ro.boot.vbmeta.avb_version
è la versionelibavb
nel bootloader.ro.boot.avb_version
è la versionelibavb
del sistema operativo Android (init/fs_mgr
).
La proprietà di sistema viene visualizzata solo quando il libavb
corrispondente è stato utilizzato
per verificare i metadati AVB (e restituisce OK). È assente se si è verificato un errore di verifica (o se non è stata eseguita alcuna verifica).
Una corrispondenza di compatibilità confronta quanto segue:
- sysprop
ro.boot.vbmeta.avb_version
conavb.vbmeta-version
dalla matrice di compatibilità del framework:ro.boot.vbmeta.avb_version.MAJOR == avb.vbmeta-version.MAJOR
ro.boot.vbmeta.avb_version.MINOR >= avb.vbmeta-version.MINOR
- sysprop
ro.boot.avb_version
conavb.vbmeta-version
dalla matrice di compatibilità del framework:ro.boot.avb_version.MAJOR == avb.vbmeta-version.MAJOR
ro.boot.avb_version.MINOR >= avb.vbmeta-version.MINOR
Il bootloader o il sistema operativo Android potrebbero contenere due copie delle librerie libavb
, ognuna con una versione PRINCIPALE diversa per i dispositivi di upgrade e di lancio. In questo caso, è possibile condividere la stessa immagine di sistema non firmata, ma le immagini di sistema firmate finali sono diverse (con avb.vbmeta-version
diversi):

Figura 1. La versione AVB corrisponde (/system è P, tutte le altre partizioni sono O).

Figura 2. Corrispondenze della versione AVB (tutte le partizioni sono P).
Esempio: corrispondenza riuscita della versione AVB
La matrice di compatibilità del framework indica le seguenti informazioni AVB:
<avb> <vbmeta-version>2.1</vbmeta-version> </avb>
Sul dispositivo:
ro.boot.avb_version == 1.0 && ro.boot.vbmeta.avb_version == 2.1 mismatch
ro.boot.avb_version == 2.1 && ro.boot.vbmeta.avb_version == 3.0 mismatch
ro.boot.avb_version == 2.1 && ro.boot.vbmeta.avb_version == 2.3 match
ro.boot.avb_version == 2.3 && ro.boot.vbmeta.avb_version == 2.1 match
Corrispondenza della versione AVB durante l'aggiornamento OTA
Per i dispositivi lanciati con Android 9 o versioni precedenti, durante l'aggiornamento ad Android 10, i requisiti di versione AVB nella matrice di compatibilità del framework vengono confrontati con la versione AVB corrente sul dispositivo. Se la versione AVB subisce un upgrade della versione principale durante un aggiornamento OTA (ad esempio, da 0.0 a 1.0), il controllo VINTF per la compatibilità nell'OTA non riflette la compatibilità dopo l'OTA.
Per risolvere il problema, un OEM può inserire una versione AVB falsa nel pacchetto OTA
(compatibility.zip
) per superare il controllo. Per farlo:
- Seleziona le seguenti CL nell'albero dei sorgenti di Android 9:
- Definisci
BOARD_OTA_FRAMEWORK_VBMETA_VERSION_OVERRIDE
per il dispositivo. Il suo valore deve essere uguale alla versione AVB prima dell'OTA, ovvero la versione AVB del dispositivo al momento del lancio. - Ricrea il pacchetto OTA.
Queste modifiche inseriscono automaticamente
BOARD_OTA_FRAMEWORK_VBMETA_VERSION_OVERRIDE
come
compatibility-matrix.avb.vbmeta-version
nei seguenti file:
/system/compatibility_matrix.xml
(che non viene utilizzato in Android 9) sul dispositivosystem_matrix.xml
incompatibility.zip
nel pacchetto OTA
Queste modifiche non influiscono su altre matrici di compatibilità dei framework, tra cui
/system/etc/vintf/compatibility_matrix.xml
. Dopo l'OTA, per i controlli di compatibilità viene utilizzato il nuovo valore in
/system/etc/vintf/compatibility_matrix.xml
.
Corrispondenza della versione VNDK
La matrice di compatibilità dei dispositivi dichiara la versione VNDK richiesta in
compatibility-matrix.vendor-ndk.version
. Se la matrice di compatibilità
del dispositivo non ha un tag <vendor-ndk>
, non
vengono imposti requisiti ed è sempre considerata una corrispondenza.
Se la matrice di compatibilità dei dispositivi ha un tag <vendor-ndk>
, viene cercata una voce <vendor-ndk>
con un <version>
corrispondente dall'insieme di snapshot del fornitore VNDK forniti dal framework nel manifest del framework. Se una voce di questo tipo non esiste, non viene trovata alcuna corrispondenza.
Se esiste una voce di questo tipo, l'insieme di librerie elencate nella matrice di compatibilità del dispositivo deve essere un sottoinsieme dell'insieme di librerie indicate nel manifest del framework; in caso contrario, la voce non viene considerata una corrispondenza.
- Come caso speciale, se non vengono elencate librerie nella matrice di compatibilità dei dispositivi, la voce viene sempre considerata una corrispondenza, perché un insieme vuoto è un sottoinsieme di qualsiasi insieme.
Esempio: corrispondenza riuscita della versione VNDK
Se la matrice di compatibilità dei dispositivi indica il seguente requisito per VNDK:
<!-- Example Device Compatibility Matrix --> <vendor-ndk> <version>27</version> <library>libjpeg.so</library> <library>libbase.so</library> </vendor-ndk>
Nel manifest del framework viene presa in considerazione solo la voce con la versione 27.
<!-- Framework Manifest Example A --> <vendor-ndk> <version>27</version> <library>libjpeg.so</library> <library>libbase.so</library> <library>libfoo.so</library> </vendor-ndk>
L'esempio A corrisponde perché la versione 27 di VNDK è presente nel file manifest del framework
e {libjpeg.so, libbase.so, libfoo.so} ⊇ {libjpeg.so, libbase.so}
.
<!-- Framework Manifest Example B --> <vendor-ndk> <version>26</version> <library>libjpeg.so</library> <library>libbase.so</library> </vendor-ndk> <vendor-ndk> <version>27</version> <library>libbase.so</library> </vendor-ndk>
L'esempio B non corrisponde. Anche se la versione 27 di VNDK è presente nel manifest del framework, libjpeg.so
non è supportata dal framework in questo snapshot. La versione 26 di VNDK viene ignorata.
Corrispondenze della versione dell'SDK di sistema
La matrice di compatibilità dei dispositivi dichiara un insieme di versioni SDK di sistema richieste in compatibility-matrix.system-sdk.version
. Si verifica
una corrispondenza solo se l'insieme è un sottoinsieme delle versioni dell'SDK di sistema fornite come dichiarato
in manifest.system-sdk.version
nel manifest del framework.
- Come caso speciale, se nella matrice di compatibilità dei dispositivi non sono elencate versioni dell'SDK di sistema, viene sempre considerata una corrispondenza, perché un insieme vuoto è un sottoinsieme di qualsiasi insieme.
Esempio: corrispondenza riuscita della versione dell'SDK di sistema
Se la matrice di compatibilità dei dispositivi indica il seguente requisito per l'SDK di sistema:
<!-- Example Device Compatibility Matrix --> <system-sdk> <version>26</version> <version>27</version> </system-sdk>
A questo punto, il framework deve fornire le versioni 26 e 27 dell'SDK di sistema per la corrispondenza:
<!-- Framework Manifest Example A --> <system-sdk> <version>26</version> <version>27</version> </system-sdk>
L'esempio A è una corrispondenza:
<!-- Framework Manifest Example B --> <system-sdk> <version>26</version> <version>27</version> <version>28</version> </system-sdk>
L'esempio B corrisponde:
<!-- Framework Manifest Example C --> <system-sdk> <version>26</version> </system-sdk>
L'esempio C non corrisponde perché la versione 27 dell'SDK di sistema non è fornita.