Regole di corrispondenza

Le due coppie di matrici e manifest di compatibilità hanno lo scopo riconciliato per verificare che il framework e l'implementazione del fornitore possono lavorare contemporaneamente. Questa verifica ha esito positivo in presenza di una corrispondenza tra la matrice di compatibilità del framework manifest del dispositivo, nonché tra il manifest del framework e il file manifest di compatibilità.

Questa verifica viene eseguita al momento della creazione, al momento dell'aggiornamento OTA di generazione del pacchetto, al momento dell'avvio e nei test di compatibilità VTS.

Le seguenti sezioni descrivono in dettaglio le regole di corrispondenza utilizzate da componenti.

La versione della matrice di compatibilità del framework corrisponde

Per associare il manifest di un 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'è corrispondenza.

Quando viene richiesta la matrice di compatibilità del framework con libvintf, questa corrispondenza è sempre riuscita perché libvintf apre il manifest del dispositivo e recupera l'attributo spedizione FCM Version, e restituisce la matrice di compatibilità del framework in quella versione di FCM di spedizione (più alcune HAL facoltativi da matrici di compatibilità in versioni FCM successive).

Corrispondenze HAL

La regola di corrispondenza HAL identifica le versioni degli elementi hal in un file manifest supportati dal proprietario dell'account di servizio di compatibilità.

HIDL e HAL nativi

Di seguito sono riportate le regole di corrispondenza per gli HAL HIDL e nativi.

  • Più elementi <hal> vengono valutati con un singolo AND relazione tra utenti.
  • <hal> elementi possono avere <hal optional="true"> per contrassegnarli come non è obbligatorio.
  • Più elementi <version> all'interno dello stesso <hal> hanno una relazione OR. Se vengono specificati due o più, una delle versioni deve essere implementata. (vedi l'esempio di DRM di seguito).
  • Più elementi <instance> e <regex-instance> elementi all'interno dello stesso <hal> vengono valutati con una singola relazione AND quando È obbligatorio specificare il campo <hal>. 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, ovvero un file manifest che fornisce l'HAL 2.0-2.4 non è compatibile.
  • 2.7 è la versione massima che può essere richiesta, ovvero il proprietario la matrice di compatibilità (framework o dispositivo) non richiederà le versioni oltre 2,7. Il proprietario del manifest corrispondente può continuare a 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 sia compatibile con la versione API 2.7.
  • -7 è solo a scopo informativo e non influisce sulla procedura di aggiornamento OTA.
di Gemini Advanced. Pertanto, un dispositivo con un HAL alla versione 2.10 nel file manifest rimane compatibile con un framework che dichiara 2.5-7 nella sua matrice di compatibilità.

Esempio: corrispondenza HAL riuscita per il modulo DRM

La matrice di compatibilità del framework dichiara 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: o

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 inoltre implementare tutte le seguenti 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) supporta 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, tranne che non esistono versioni principali ed esiste esattamente una versione per istanza HAL (1 se non è specificata).

  • Più elementi <hal> vengono valutati con un singolo AND relazione tra utenti.
  • <hal> elementi possono avere <hal optional="true"> per contrassegnarli come non è obbligatorio.
  • Più elementi <instance> e <regex-instance> elementi all'interno dello stesso <hal> vengono valutati con una singola relazione AND quando È obbligatorio specificare il campo <hal>. (Vedi l'<ahref="#vibrator">esempio di vibrazione di seguito).</a href="#vibrator">

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 è la versione minima richiesta, ovvero un file manifest che fornisce l'HAL 1-4 non è compatibile.
  • 7 è la versione massima che è possibile richiedere, ovvero il proprietario la matrice di compatibilità (framework o dispositivo) non richiederà le versioni oltre 7. Il proprietario del manifest corrispondente può comunque pubblicare la versione 10 (ad esempio) quando viene richiesto il numero 7. Il proprietario della matrice di compatibilità sa solo che il servizio richiesto sia compatibile con la versione API 7.
  • -7 è solo a scopo informativo e non influisce sulla procedura di aggiornamento OTA.
di Gemini Advanced. Pertanto, un dispositivo con un HAL alla versione 10 nel file manifest rimane compatibile con un framework che dichiara 5-7 nella sua matrice di compatibilità.

Esempio: corrispondenza HAL riuscita per più moduli

La matrice di compatibilità del framework dichiara le seguenti informazioni sulla versione per HAL vibrazione e videocamera:

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

La sezione <kernel> della matrice di compatibilità del framework descrive i requisiti del framework del kernel Linux sul dispositivo. Questo le informazioni devono essere confrontate informazioni sul kernel che viene segnalato dall'oggetto VINTF del dispositivo.

Associa i rami del kernel

Ogni suffisso del ramo del kernel (ad esempio, 5.4-r) è mappato a un versione FCM del kernel (ad esempio, 5). La mappatura è la stessa delle lettere di rilascio (ad es. R) e FCM (ad es. 5).

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

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

I test VTS applicano che, se viene specificata la versione FCM del kernel, la versione FCM del kernel 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 4 di FCM target (rilasciata su Android 10), ma esegue il kernel dal 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 in base ai requisiti sul kernel 4.19-r ramo, specificato nella versione 5 di FCM. Questi requisiti vengono creati kernel/configs/r/android-4.19 nell'albero delle origini 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 è il 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 maggiori dettagli su come viene analizzata la stringa di rilascio del kernel, consulta Controllo delle versioni di GKI.

Associa le versioni del kernel

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

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

L'oggetto VINTF prende in considerazione solo la sezione <kernel> dell'oggetto FCM con versione FCM corrispondente con lo stesso ${ver} e ${major_rev} come kernel del dispositivo (ad es. version="${ver}.${major_rev}.${matrix_minor_rev}"); altre sezioni vengono ignorati. Inoltre, la revisione secondaria del kernel deve essere un valore dalla matrice di compatibilità (${kernel_minor_rev} >= ${matrix_minor_rev};). Se nessuna sezione <kernel> soddisfa questi requisiti, la mancata corrispondenza.

Esempio: selezionare i requisiti per la corrispondenza

Considera il seguente caso ipotetico in cui gli FCM in /system/etc/vintf dichiarano i seguenti requisiti (i tag di intestazione e piè di pagina vengono 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 il kernel. requisiti delle 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 nota sotto)
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 (T) 4.19.42 4.19-q
4 (T)non specificato4.4.107 Nessuna corrispondenza (nessun ramo di kernel 4.4-q)
4 (T)non specificato4.9.165 4.9-q
4 (T)non specificato5.4.41 5.4-r (vedi nota sotto)
4 (T)4 (T) 4.9.165 4.9-q
4 (T)4 (T) 5.4.41 Nessuna corrispondenza (nessun ramo di kernel 5.4-q)
4 (T)5 (D) 4.14.1054.14-r
4 (T)5 (D) 5.4.41 5.4-r
5 (D)non specificatoqualsiasi VTS non riesce (è necessario specificare la versione FCM del kernel per la versione 5 di FCM di destinazione)
5 (D)4 (T) qualsiasi VTS non riesce (versione FCM del kernel < versione FCM di destinazione)
5 (D)5 (D) 4.14.1804.14-r

Associa configurazioni kernel

Se la sezione <kernel> corrisponde, la procedura continua cercando di far corrispondere config elementi /proc/config.gz. Per ogni elemento di configurazione nella compatibilità osserva /proc/config.gz per vedere se la configurazione presenti. Quando un elemento di configurazione è impostato su n nella compatibilità per la sezione <kernel> corrispondente, deve essere assente da /proc/config.gz. Infine, un elemento di configurazione non potrebbe non 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 a /proc/config.gz.
  • <value type="int">4096</value> corrispondenze 4096, 0x1000 o 0X1000.
  • <value type="int">0x1000</value> corrispondenze 4096, 0x1000 o 0X1000.
  • <value type="int">0X1000</value> corrispondenze 4096, 0x1000 o 0X1000.
  • <value type="tristate">y</value> corrispondenze y.
  • <value type="tristate">m</value> corrispondenze m.
  • <value type="tristate">n</value> indica che la configurazione l'elemento NON deve esistere in /proc/config.gz.
  • <value type="range">1-0x3</value> corrispondenze 1, 2 o 3 o 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 abbinato per primo. Il ramo del kernel è specificato nel manifest del dispositivo in manifest.kernel.target-level, che per impostazione predefinita è manifest.level se il primo non è specificato. Se il ramo del kernel nel manifest del dispositivo:

  • è 1, procede 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 FCM versione 2.

Quindi, viene trovata la versione del kernel. Se un dispositivo in uname() report:

  • 4.9.84 (non esiste una corrispondenza con la matrice a meno che non ci sia 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 con la matrice)
  • 4.14.43 (corrispondenza con la matrice)
  • 4.1.22 (nessuna corrispondenza con la matrice a meno che non ci sia una sezione del kernel separata con <kernel version="4.1.x"> dove x <= 22)

Dopo aver selezionato la sezione <kernel> appropriata, per ogni elemento <config> con valore diverso da n, si aspetta che la voce corrispondente sia presente in /proc/config.gz; per ogni articolo <config> con valore n, prevediamo la voce corrispondente non deve essere presente in /proc/config.gz. Me si aspetta che i contenuti di <value> corrispondano esattamente al testo dopo il segno di uguale (incluse le virgolette), fino al carattere di nuova riga o #, con spazi vuoti iniziali e finali troncati.

La seguente configurazione del kernel è un esempio di corrispondenza corretta:

# 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

La norma SE richiede le seguenti corrispondenze:

  • <sepolicy-version> definisce un intervallo chiuso di minori per ogni versione principale. La versione sepolicy segnalata dal dispositivo Deve rientrare in uno di questi intervalli per essere compatibile con il framework. Corrispondenza sono simili a quelle delle versioni HAL; la corrispondenza è se la versione sepolicy sia superiore o uguale alla versione minima dell'intervallo. La versione massima è puramente informativo.
  • <kernel-sepolicy-version> ovvero la versione del database dei criteri. Deve essere inferiore al valore di security_policyvers() segnalato dal dispositivo.

Esempio: corrispondenza della norma SE riuscita

La matrice di compatibilità del framework riporta le seguenti informazioni di sicurezza: 

<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. Altrimenti non c'è corrispondenza. Ad esempio:
    • Se un dispositivo restituisce 29, non corrisponde.
    • Se un dispositivo restituisce 31, si tratta di una corrispondenza.
  • La versione delle policy SE deve essere una tra 25.0-∞ o 26.0-∞. Altrimenti non si tratta di corrispondono. ("-3" dopo "26.0" è puramente informativa.)

La versione AVB corrisponde

La versione AVB contiene una versione MAJOR e una versione MINOR, con il formato come MAJOR.MINOR (ad es. 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 versione libavb in bootloader
  • ro.boot.avb_version è la versione libavb in Sistema operativo Android (init/fs_mgr)

La proprietà di sistema viene visualizzata solo quando è stato utilizzato il valore libavb corrispondente per verificare i metadati AVB (e restituisce OK). Non è presente se si verifica un errore di verifica (o non è stata effettuata alcuna verifica).

Una corrispondenza di compatibilità mette a confronto i seguenti elementi:

  • 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 di libavb librerie, ognuna con una versione MAJOR diversa per l'upgrade dei dispositivi e dispositivi mobili. In questo caso, può essere condivisa la stessa immagine di sistema non firmata, ma le immagini di sistema firmate finali sono diverse (con avb.vbmeta-version):

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



Figura 2. La versione AVB corrisponde (tutte le partizioni sono P).

Esempio: corrispondenza della versione AVB riuscita

La matrice di compatibilità del framework dichiara 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 

Abbina la versione AVB durante l'aggiornamento OTA

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

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

  1. Seleziona le seguenti CL nell'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 quando è stato avviato.
  3. Ricrea il pacchetto OTA.

Queste modifiche vengono applicate automaticamente BOARD_OTA_FRAMEWORK_VBMETA_VERSION_OVERRIDE sotto forma di 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, il nuovo valore Per i controlli di compatibilità viene invece utilizzato /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 il dispositivo la matrice di compatibilità non ha un tag <vendor-ndk>, no se vengono imposti requisiti specifici, viene sempre considerata una corrispondenza.

Se la matrice di compatibilità dei dispositivi ha un <vendor-ndk> tag, una voce <vendor-ndk> con un valore Il campo <version> viene cercato dall'insieme di snapshot dei fornitori VNDK fornite dal framework nel file manifest del framework. Se una voce di questo tipo esistono, non c'è corrispondenza.

Se una voce di questo tipo esiste, l'insieme di librerie enumerato nel dispositivo la matrice di compatibilità deve essere un sottoinsieme dell'insieme di librerie indicato nella il manifest del framework; altrimenti la voce non viene considerata una corrispondenza.

  • Come caso speciale, se nel dispositivo non sono enumerate librerie matrice di compatibilità, la voce viene sempre considerata una corrispondenza, perché set è un sottoinsieme di qualsiasi insieme.

Esempio: corrispondenza della versione VNDK riuscita

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 è 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 la versione 27 di VNDK è inclusa nel framework manifest, libjpeg.so non è supportato dal framework in quanto senza dover creare uno snapshot. La versione 26 di VNDK viene ignorata.

La versione dell'SDK di sistema corrisponde

La matrice di compatibilità dei dispositivi dichiara un insieme di SDK di sistema necessari in compatibility-matrix.system-sdk.version. C'è un corrispondono solo se l'insieme è un sottoinsieme di versioni dell'SDK di sistema fornite, come dichiarato in manifest.system-sdk.version nel file manifest del framework.

  • Come caso speciale, se nel dispositivo non sono enumerate versioni dell'SDK di sistema di compatibilità, viene sempre considerata una corrispondenza, perché set è un sottoinsieme di qualsiasi insieme.

Esempio: corrispondenza della versione dell'SDK di sistema riuscita

Se la matrice di compatibilità dei dispositivi indica il seguente requisito sul sistema SDK: 

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

Quindi, il framework deve fornire per la corrispondenza le versioni 26 e 27 dell'SDK di sistema.

<!-- 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é la versione 27 dell'SDK di sistema non è fornita.