Regole delle corrispondenze

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 è 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 può richiedere versioni successive alla 2.7. Il proprietario del manifest corrispondente può comunque pubblicare la versione 2.10 (ad esempio) quando viene richiesta la 2.7. Il proprietario della matrice di compatibilità sa solo che il servizio richiesto è compatibile con la versione 2.7 dell'API.
  • -7 è solo a titolo informativo e non influisce sulla procedura di aggiornamento OTA.
Pertanto, un dispositivo con una HAL alla versione 2.10 nel file manifest rimane compatibile con un framework che indica 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 è 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 a 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 la versione 7 dell'API.
  • -7 è solo a titolo informativo e non influisce sulla procedura di aggiornamento OTA.
Pertanto, 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 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 destinazioneVersione FCM del kernelVersione kernelCorrispondenza con
3 (R)Non specificato4.4.106Nessuna corrispondenza (mancata corrispondenza della versione secondaria)
3 (R)Non specificato4.4.1074.4-p
3 (R)Non specificato4.19.424.19-q (vedi la nota dopo la tabella)
3 (R)Non specificato5.4.415.4-r (vedi la nota dopo la tabella)
3 (R)3 (R)4.4.1074.4-p
3 (R)3 (R)4.19.42Nessuna corrispondenza (nessun ramo del kernel 4.19-p)
3 (R)4 (T)4.19.424.19-q
4 (T)Non specificato4.4.107Nessuna corrispondenza (nessun ramo del kernel 4.4-q)
4 (T)Non specificato4.9.1654.9-q
4 (T)Non specificato5.4.415.4-r (vedi la nota dopo la tabella)
4 (T)4 (T)4.9.1654.9-q
4 (T)4 (T)5.4.41Nessuna corrispondenza (nessun ramo del kernel 5.4-q)
4 (T)5 (R)4.14.1054.14-r
4 (T)5 (R)5.4.415.4-r
5 (R)Non specificatoqualsiasiVTS non riesce (deve specificare la versione FCM del kernel per la versione FCM di destinazione 5)
5 (R)4 (T)qualsiasiVTS fails (kernel FCM version < target FCM version)
5 (R)5 (R)4.14.1804.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 a 4096, 0x1000 o 0X1000.
  • <value type="int">0x1000</value> corrisponde a 4096, 0x1000 o 0X1000.
  • <value type="int">0X1000</value> corrisponde a 4096, 0x1000 o 0X1000.
  • <value type="tristate">y</value> corrispondenze y.
  • <value type="tristate">m</value> corrispondenze m.
  • <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 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 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">, dove x <= 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">, dove x <= 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 a security_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 dopo 26.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 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 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 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 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:

  1. Seleziona le seguenti CL nell'albero dei sorgenti di Android 9:
  2. 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.
  3. 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 dispositivo
  • system_matrix.xml in compatibility.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.