Regole delle corrispondenze

Le due coppie di matrici e manifest di compatibilità devono essere riconciliate per verificare che il framework e l'implementazione del fornitore possano funzionare tra loro. Questa verifica viene eseguita correttamente se esiste una corrispondenza tra la matrice di compatibilità del framework e il manifest del dispositivo, nonché tra il manifest del framework e la matrice di compatibilità del dispositivo.

Questa verifica viene eseguita in fase di compilazione, al momento della generazione del pacchetto di aggiornamento OTA, all'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 associare un manifest del dispositivo a una matrice di compatibilità del framework, la versione FCM di spedizione specificata da manifest.target-level deve essere esattamente uguale alla versione FCM specificata da compatibility-matrix.level. In caso contrario, non c'è alcuna corrispondenza.

Quando la matrice di compatibilità del framework viene richiesta con libvintf, questa corrispondenza è sempre riuscita perché libvintf apre il manifest del dispositivo, recupera la versione FCM di produzione e restituisce la matrice di compatibilità del framework in quella versione FCM di produzione (oltre ad alcuni HAL facoltativi dalle matrici di compatibilità in versioni FCM superiori).

Corrispondenze HAL

La regola HAL-match identifica le versioni degli elementi hal in un file manifest che sono considerate supportate dal proprietario della corrispondente matrice di compatibilità.

HIDL e HAL nativi

Le regole di corrispondenza per HIDL e HAL native 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 <hal> hanno la relazione OR. Se sono specificate due o più, solo una delle versioni deve essere implementata. (vedi l'esempio DRM di seguito).
  • Più elementi <instance> e <regex-instance> all'interno dello stesso <hal> vengono valutati con una singola relazione AND quando il <hal> è obbligatorio. Vedi l'<ahref="#drm">esempio di DRM riportato di seguito</ahref="#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 è la versione minima richiesta, il che significa che un manifest che fornisce HAL 2.0-2.4 non è compatibile.
  • 2.7 è la versione massima che può essere richiesta, il che significa che il proprietario della matrice di compatibilità (framework o dispositivo) non richiederà versioni successive alla 2.7. Il proprietario del manifest corrispondente può comunque pubblicare la versione 2.10 (ad esempio) quando viene richiesta la versione 2.7. Il proprietario della matrice di compatibilità sa solo che il servizio richiesto è compatibile con la versione API 2.7.
  • -7 è solo a scopo informativo e non influisce sulla procedura di aggiornamento OTA.
Pertanto, un dispositivo con un HAL alla versione 2.10 nel file manifest rimane compatibile con un framework che indica 2.5-7 nella sua matrice di compatibilità.

Esempio: corrispondenza HAL riuscita per il modulo DRM

La matrice di compatibilità del framework indica le seguenti informazioni sulle versioni per l'HAL DRM:

<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 anche 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

Tutte le versioni di Android successive ad Android 11 (escluso Android 11) supportano le versioni per gli HAL AIDL in VINTF. Le regole di corrispondenza per gli HAL AIDL sono simili a quelle degli HAL HIDL e nativi, ma non esistono versioni principali e esiste una sola 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 il <hal> è obbligatorio. (Vedi l'<ahref="#vibrator">esempio di vibrazione riportato di seguito.)</ahref="#vibrator">

Esempio: corrispondenza HAL riuscita per un modulo

Per un HAL nella 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 è la versione minima richiesta, il che significa che un manifest che fornisce HAL 1-4 non è compatibile.
  • 7 è la versione massima che può essere richiesta, il che significa che il proprietario della matrice di compatibilità (framework o dispositivo) non richiederà versioni superiori alla 7. Il proprietario del manifest corrispondente può comunque pubblicare la versione 10 (ad esempio) quando viene richiesta la 7. Il proprietario della matrice di compatibilità sa solo che il servizio richiesto è compatibile con l'API versione 7.
  • -7 è solo a scopo informativo e non influisce sulla procedura di aggiornamento OTA.
Di conseguenza, un dispositivo con un HAL alla versione 10 nel file manifest rimane compatibile con un framework che indica 5-7 nella matrice di compatibilità.

Esempio: corrispondenza HAL riuscita per più moduli

La matrice di compatibilità del framework indica le seguenti informazioni sulle versioni 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 kernel Linux del framework sul dispositivo. Queste informazioni devono essere associate alle informazioni sul kernel registrate dall'oggetto VINTF del dispositivo.

Associa i rami del kernel

Ogni suffisso del ramo del kernel (ad esempio, 5.4-r) è mappato a una versione FCM univoca del kernel (ad esempio 5). La mappatura è la stessa tra le lettere delle release (ad es. R) e le versioni di FCM (ad es. 5).

I test VTS richiedono che il dispositivo specifichi esplicitamente la versione FCM del kernel nel manifest del dispositivo, /vendor/etc/vintf/manifest.xml, se una delle seguenti condizioni è vera:

  • La versione FCM del kernel è diversa dalla versione FCM target. Ad esempio, il dispositivo sopra indicato ha una versione FCM di destinazione 4 e la sua versione FCM del kernel è 5 (sufisso del ramo del kernel r).
  • La versione FCM del kernel è maggiore o uguale a 5 (sufisso del ramo del kernel r).

I test VTS richiedono che, se viene specificata la versione FCM del kernel, questa sia maggiore o uguale alla versione FCM di destinazione nel file manifest del dispositivo.

Esempio: determinare il ramo del kernel

Se il dispositivo ha la versione FCM target 4 (rilasciata in Android 10), ma gira il kernel del ramo 4.19-r, il file manifest del dispositivo deve specificare quanto segue: 

<manifest version="2.0" type="device" target-level="4">
   <kernel target-level="5" />
</manifest>

L'oggetto VINTF controlla la compatibilità del kernel rispetto ai requisiti del ramo del kernel 4.19-r, specificato nella versione 5 di FCM. Questi requisiti sono ricavati da kernel/configs/r/android-4.19 nella struttura del codice sorgente di Android.

Esempio: determinare il ramo del kernel per GKI

Se il dispositivo usa la Generic Kernel Image (GKI) e la stringa di release del kernel da /proc/version è la seguente:

5.4.42-android12-0-00544-ged21d463f856

Quindi, l'oggetto VINTF ottiene la release Android dalla release del kernel e la utilizza per determinare la versione FCM del kernel. In questo esempio, android12 indica la versione 6 del kernel FCM (rilasciata in Android 12).

Per informazioni dettagliate su come viene analizzata la stringa di rilascio del kernel, consulta Controllo delle versioni GKI.

Abbinare le versioni del kernel

Una matrice può includere più sezioni <kernel>, ciascuna con un attributo version diverso, utilizzando il formato:

${ver}.${major_rev}.${kernel_minor_rev}

L'oggetto VINTF prende in considerazione solo la sezione <kernel> del FCM con la versione FCM corrispondente con gli stessi ${ver} e ${major_rev} del kernel del dispositivo (ovvero version="${ver}.${major_rev}.${matrix_minor_rev}"); le altre sezioni vengono ignorate. Inoltre, la revisione minore del kernel deve essere un valore della matrice di compatibilità (${kernel_minor_rev} >= ${matrix_minor_rev};). Se nessuna sezione <kernel> soddisfa questi requisiti, non è presente una corrispondenza.

Esempio: selezionare i requisiti per la corrispondenza

Prendi in considerazione il seguente caso ipotetico in cui i moduli di controllo a livello di frame 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 insieme selezionano i requisiti del kernel dai FCM:

Versione FCM di destinazioneVersione FCM del kernelVersione kernelCorrispondenza con
3 (R)non specificato4.4.106 Nessuna corrispondenza (versione secondaria non corrispondente)
3 (R)non specificato4.4.107 4.4-p
3 (R)non specificato4.19.42 4.19-q (vedi nota sotto)
3 (R)non specificato5.4.41 5.4-r (vedi la nota di seguito)
3 (R)3 (R) 4.4.107 4.4-p
3 (R)3 (R) 4.19.42 Nessuna corrispondenza (nessun ramo di kernel 4.19-p)
3 (R)4 (Q) 4.19.42 4.19-q
4 (T)non specificato4.4.107 Nessuna corrispondenza (nessun ramo del kernel 4.4-q)
4 (T)non specificato4.9.165 4.9-q
4 (Q)non specificato5.4.41 5.4-r (vedi la nota di seguito)
4 (Q)4 (Q) 4.9.165 4.9-q
4 (Q)4 (Q) 5.4.41 Nessuna corrispondenza (nessun ramo del kernel 5.4-q)
4 (Q)5 (R) 4.14.1054.14-r
4 (Q)5 (R) 5.4.41 5.4-r
5 (R)non specificatoqualsiasi Il VTS non va a buon fine (è necessario specificare la versione FCM del kernel per la versione FCM di destinazione 5)
5 (D)4 (Q) qualsiasi Il VTS non va a buon fine (versione FCM del kernel < versione FCM target)
5 (D)5 (D) 4.14.1804.14-r

Associa configurazioni kernel

Se la sezione <kernel> corrisponde, la procedura continua cercando di trovare una corrispondenza tra gli elementi config e /proc/config.gz. Per ogni elemento di configurazione nella matrice di compatibilità, viene cercato /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, non deve essere presente in /proc/config.gz. Infine, un elemento di configurazione non presente nella matrice di compatibilità potrebbe o meno essere presente in /proc/config.gz.

Esempio: abbinare le 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 a 4096 o 0x1000 o 0X1000.
  • <value type="int">0x1000</value> corrisponde a 4096 o 0x1000 o 0X1000.
  • <value type="int">0X1000</value> corrisponde a 4096 o 0x1000 o 0X1000.
  • <value type="tristate">y</value> corrisponde a y.
  • <value type="tristate">m</value> corrispondenze m.
  • <value type="tristate">n</value> indica che l'elemento di configurazione NON deve esistere in /proc/config.gz.
  • <value type="range">1-0x3</value> corrisponde a 1, 2 o 3 o all'equivalente esadecimale.

Esempio: corrispondenza del kernel riuscita

Una matrice di compatibilità del framework con FCM versione 1 contiene le seguenti informazioni 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>

Il ramo del kernel viene associato per primo. Il ramo del kernel è specificato nel manifest del dispositivo in manifest.kernel.target-level, che per impostazione predefinita è manifest.level se non è specificato il primo. Se il ramo del kernel nel file manifest del dispositivo:

  • è 1, vai al passaggio successivo e controlla la versione del kernel.
  • è 2, nessuna corrispondenza con la matrice. Gli oggetti VINTF leggono i requisiti del kernel dalla matrice nella versione 2 di FCM.

Viene quindi 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">, dove x <= 84)
  • 4.14.41 (nessuna corrispondenza con la matrice, minore di version)
  • 4.14.42 (corrispondenza alla matrice)
  • 4.14.43 (corrispondenza alla matrice)
  • 4.1.22 (nessuna corrispondenza con la matrice, a meno che non esista una sezione del kernel distinta con <kernel version="4.1.x"> dove x <= 22)

Dopo aver selezionato la sezione <kernel> appropriata, per ogni elemento <config> con un valore diverso da n, prevediamo che la voce corrispondente sia presente in /proc/config.gz; per ogni elemento <config> con valore n, prevediamo che la voce corrispondente non sia presente in /proc/config.gz. Prevediamo che i contenuti di <value> corrispondano esattamente al testo dopo il segno di uguale (incluse le virgolette), fino al carattere di a capo o #, con gli spazi 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

Corrispondenza norma SE

Le norme SE richiedono le seguenti corrispondenze:

  • <sepolicy-version> definisce un intervallo chiuso di versioni minori per ogni versione principale. La versione 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: si tratta di una corrispondenza se la versione del criterio di sicurezza è superiore o uguale alla versione minima per l'intervallo. La versione massima è puramente informativa.
  • <kernel-sepolicy-version> ad es. la versione di policydb. Deve essere inferiore a security_policyvers() segnalato dal dispositivo.

Esempio: corrispondenza ai criteri SE riuscita

La matrice di compatibilità del framework indica le seguenti informazioni su 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 è una corrispondenza. Ad esempio:
    • Se un dispositivo restituisce 29, non corrisponde.
    • Se un dispositivo restituisce 31, si tratta di una corrispondenza.
  • La versione del criterio SE deve essere 25.0-∞ o 26.0-∞. In caso contrario, non c'è corrispondenza. Il valore "-3" dopo "26.0" è puramente informativo.

La versione AVB corrisponde

La versione AVB contiene una versione MAJOR e una MINOR, con il formato come MAJOR.MINOR (ad es. 1.0, 2.1). Per maggiori dettagli, consulta Versionamento e compatibilità. La versione AVB ha le seguenti proprietà di sistema:

  • ro.boot.vbmeta.avb_version è la versione libavb nel bootloader
  • ro.boot.avb_version è la versione libavb del sistema operativo Android (init/fs_mgr)

La proprietà di sistema viene visualizzata solo quando è stato utilizzato il libavb corrispondente per verificare i metadati AVB (e restituisce OK). Non è presente 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 con avb.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 con avb.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 potrebbe contenere due copie delle librerie libavb, ciascuna con una versione MAJOR 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 della versione AVB riuscita

La matrice di compatibilità del framework indica le seguenti informazioni su 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 

Abbina la versione AVB durante l'aggiornamento OTA

Per i dispositivi lanciati con Android 9 o versioni precedenti, durante l'aggiornamento ad Android 10, i requisiti della versione AVB nella matrice di compatibilità del framework vengono confrontati con la versione AVB attuale sul dispositivo. Se la versione AVB viene sottoposta a un upgrade di versione principale durante un aggiornamento OTA (ad esempio da 0.0 a 1.0), il controllo VINTF della compatibilità in OTA non riflette la compatibilità dopo l'OTA.

Per ovviare al problema, un OEM può inserire una versione falsa di AVB nel pacchetto OTA (compatibility.zip) per superare il controllo. Per farlo:

  1. Scegli i seguenti CL per l'albero di origine di Android 9:
  2. Definisci BOARD_OTA_FRAMEWORK_VBMETA_VERSION_OVERRIDE per il dispositivo. Il suo valore deve corrispondere alla versione AVB prima dell'OTA, ovvero la versione AVB del dispositivo al momento del lancio.
  3. Ricostruisci 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 (non utilizzata in Android 9) sul dispositivo
  • system_matrix.xml in compatibility.zip nel pacchetto OTA

Queste modifiche non influiscono su altre matrici di compatibilità del framework, tra cui/system/etc/vintf/compatibility_matrix.xml. Dopo l'OTA, per i controlli di compatibilità viene invece utilizzato il nuovo valore di /system/etc/vintf/compatibility_matrix.xml.

La versione VNDK corrisponde

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 e, di conseguenza, viene sempre considerata una corrispondenza.

Se la matrice di compatibilità del dispositivo contiene un tag <vendor-ndk>, viene cercata una voce <vendor-ndk> con un <version> corrispondente nell'insieme di snapshot del fornitore VNDK fornito dal framework nel manifest del framework. Se una voce di questo tipo non esiste, non esiste 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 indicato nel manifest del framework. In caso contrario, la voce non viene considerata una corrispondenza.

  • Come caso speciale, se nella matrice di compatibilità dei dispositivi non sono elencate librerie, la voce viene sempre considerata una corrispondenza, perché l'insieme vuoto è un sottoinsieme di qualsiasi insieme.

Esempio: corrispondenza della versione VNDK riuscita

Se la matrice di compatibilità del dispositivo 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 considerata 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 è una corrispondenza, perché VNDK versione 27 è 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 VNDK versione 27 è nel manifest del framework, libjpeg.so non è supportato dal framework nello 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 dell'SDK di sistema obbligatorie in compatibility-matrix.system-sdk.version. Esiste una corrispondenza solo se l'insieme è un sottoinsieme delle versioni dell'SDK di sistema fornite come dichiarato in manifest.system-sdk.version nel file manifest del framework.

  • Come caso speciale, se nella matrice di compatibilità del dispositivo non sono elencate versioni dell'SDK di sistema, viene sempre considerata una corrispondenza, perché l'insieme vuoto è un sottoinsieme di qualsiasi insieme.

Esempio: corrispondenza della versione dell'SDK di sistema riuscita

Se la matrice di compatibilità del dispositivo indica il seguente requisito per System SDK: 

<!-- Example Device Compatibility Matrix -->
<system-sdk>
    <version>26</version>
    <version>27</version>
</system-sdk>

Inoltre, 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 è una corrispondenza.

<!-- Framework Manifest Example C -->
<system-sdk>
    <version>26</version>
</system-sdk>

L'esempio C non corrisponde perché non è fornita la versione 27 dell'SDK di sistema.