Regole di corrispondenza

Le due coppie di matrici e manifest di compatibilità devono essere riconciliate per verificare che il framework e l'implementazione del fornitore possano funzionare insieme. Questa verifica ha esito positivo in caso di 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 al momento della 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 dai vari componenti.

La versione della matrice di compatibilità del framework corrisponde

Per abbinare un manifest del dispositivo a una matrice di compatibilità del framework, la versione di Shipping FCM specificata da manifest.target-level deve essere esattamente uguale alla versione FCM specificata da compatibility-matrix.level . Altrimenti non c'è corrispondenza.

Quando viene richiesta la matrice di compatibilità del framework 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 opzionali da matrici di compatibilità a FCM superiore versioni).

partite HAL

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

HIDL e HAL 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 <hal> hanno la relazione OR . Se ne vengono specificate due o più, è necessario implementare solo una delle versioni. (Vedere l' esempio DRM di seguito.)
  • Più elementi <instance> e <regex-instance> all'interno dello stesso <hal> vengono valutati con una singola relazione AND quando è richiesto <hal> . (Vedi il Esempio DRM di seguito.)

Esempio: corrispondenza HAL riuscita per un modulo

Per un HAL alla versione 2.5, la regola di corrispondenza è la seguente:

Matrice Manifesto 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ò ancora pubblicare la versione 2.10 (come esempio) quando viene richiesta la 2.7. Il proprietario della matrice di compatibilità sa solo che il servizio richiesto è compatibile con l'API versione 2.7.
  • -7 è solo informativo e non influisce sul processo di aggiornamento OTA.
Pertanto, un dispositivo con un HAL alla versione 2.10 nel suo file manifest rimane compatibile con un framework che afferma 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 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 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

AIDL HAL

Tutte le versioni di Android successive ad Android 11 (escluso Android 11) supportano le versioni per AIDL HAL in VINTF. Le regole di corrispondenza per gli HAL AIDL sono simili a quelle di HIDL e HAL nativi, 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 è richiesto <hal> . (Vedi il esempio di vibratore di seguito.)

Esempio: corrispondenza HAL riuscita per un modulo

Per un HAL alla versione 5, la regola di corrispondenza è la seguente:

Matrice Manifesto 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 servire 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 informativo e non influisce sul processo di aggiornamento OTA.
Pertanto, un dispositivo con un HAL alla versione 10 nel suo file manifest rimane compatibile con un framework che afferma 5-7 nella sua matrice di compatibilità.

Esempio: corrispondenza HAL riuscita per più moduli

La matrice di compatibilità del framework indica le seguenti informazioni sulla versione per vibratori e HAL della 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 che vengono riportate dall'oggetto VINTF del dispositivo.

Abbina i rami del kernel

Ogni suffisso del ramo del kernel (ad esempio, 5.4- r ) è 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 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 una delle seguenti condizioni è vera:

  • La versione FCM del kernel è diversa dalla versione FCM di destinazione. Ad esempio, il dispositivo di cui sopra 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, la versione FCM del kernel è maggiore o uguale alla versione FCM di destinazione nel manifest del dispositivo.

Esempio: determinare il ramo del kernel

Se il dispositivo ha FCM di destinazione versione 4 (rilasciato in 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 rispetto ai requisiti del ramo del kernel 4.19-r , che è specificato nella versione 5 di FCM. Questi requisiti sono compilati da kernel/configs/r/android-4.19 nell'albero dei sorgenti di Android.

Esempio: determinare il ramo del kernel per GKI

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

5.4.42-android12-0-00544-ged21d463f856

Quindi, l'oggetto VINTF ottiene la versione Android dalla versione del kernel e la usa per determinare la versione FCM del kernel. In questo esempio, android12 significa kernel FCM versione 6 (rilasciato in Android 12).

Per i dettagli su come viene analizzata la stringa di rilascio del kernel, vedere GKI versioning .

Abbina le versioni del kernel

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

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

L'oggetto VINTF considera solo la sezione <kernel> di FCM con la versione FCM corrispondente con gli stessi ${ver} e ${major_rev} del kernel del dispositivo (ad esempio, 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, è una non 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 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 dagli FCM:

Versione di destinazione FCM Versione FCM del kernel Versione kernel Abbina con
3 (P) non specificato 4.4.106 Nessuna corrispondenza (versione secondaria non corrispondente)
3 (P) non specificato 4.4.107 4.4-p
3 (P) non specificato 4.19.42 4.19-q (vedi nota sotto)
3 (P) non specificato 5.4.41 5.4-r (vedi nota sotto)
3 (P) 3 (P) 4.4.107 4.4-p
3 (P) 3 (P) 4.19.42 Nessuna corrispondenza (nessun ramo del kernel 4.19-p )
3 (P) 4 (Q) 4.19.42 4.19-q
4 (Q) non specificato 4.4.107 Nessuna corrispondenza (nessun ramo del kernel 4.4-q )
4 (Q) non specificato 4.9.165 4.9-q
4 (Q) non specificato 5.4.41 5.4-r (vedi nota sotto)
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.105 4.14-r
4 (Q) 5 (R) 5.4.41 5.4-r
5 (R) non specificato qualunque VTS non riesce (è necessario specificare la versione FCM del kernel per la versione FCM di destinazione 5)
5 (R) 4 (Q) qualunque VTS non riesce (versione FCM del kernel < versione FCM di destinazione)
5 (R) 5 (R) 4.14.180 4.14-r

Abbina le configurazioni del kernel

Se la sezione <kernel> non corrisponde, il processo continua tentando di confrontare gli elementi di config con /proc/config.gz . Per ogni elemento di configurazione nella matrice di compatibilità, cerca /proc/config.gz per vedere 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 nella matrice di compatibilità può essere presente o meno in /proc/config.gz .

Esempio: abbina le configurazioni del kernel

  • <value type="string">bar</value> corrisponde "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> corrisponde a 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 equivalente esadecimale.

Esempio: corrispondenza del kernel riuscita

Una matrice di compatibilità del framework con FCM versione 1 ha 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>

Il ramo del kernel viene confrontato 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 invece i requisiti del kernel dalla matrice in FCM versione 2.

Quindi, la versione del kernel è abbinata. Se un dispositivo in uname() segnala:

  • 4.9.84 (nessuna 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, più piccola della version )
  • 4.14.42 (abbina alla matrice)
  • 4.14.43 (abbina alla 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 , ci aspettiamo che la voce corrispondente sia presente in /proc/config.gz ; per ogni elemento <config> con valore n , ci aspettiamo che la voce corrispondente non sia presente in /proc/config.gz . Ci aspettiamo che il contenuto di <value> corrisponda esattamente al testo dopo il segno di uguale (incluse le virgolette), fino al carattere di nuova riga o # , con spazi bianchi 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 della politica SE

La politica SE 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; corrisponde se la versione sepolicy è maggiore o uguale alla versione minima per l'intervallo. La versione massima è puramente informativa.
  • <kernel-sepolicy-version> cioè la versione policydb. Deve essere inferiore a security_policyvers() riportato dal dispositivo.

Esempio: corrispondenza della norma SE riuscita

La matrice di compatibilità del framework riporta le seguenti informazioni sulla 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. Altrimenti non è una corrispondenza. Per esempio:
    • Se un dispositivo restituisce 29, non corrisponde.
    • Se un dispositivo restituisce 31, è una corrispondenza.
  • La versione della politica SE deve essere una delle 25.0-∞ o 26.0-∞. Altrimenti non è una partita. (Il " -3 " dopo " 26.0 " è puramente informativo.)

La versione AVB corrisponde

La versione AVB contiene una versione MAJOR e una versione MINOR, con il formato MAJOR.MINOR (es. 1.0, 2.1). Per i dettagli, fare riferimento a Versioning 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 nel sistema operativo Android ( init/fs_mgr )

La proprietà di sistema viene visualizzata solo quando il corrispondente libavb è stato utilizzato per verificare i metadati AVB (e restituisce OK). È assente se si è verificata una verifica non riuscita (o non si è verificata 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 , ciascuna con una versione MAJOR diversa per i dispositivi di aggiornamento e di avvio. In questo caso, la stessa immagine di sistema non firmata può essere condivisa ma le immagini di sistema firmate finali sono diverse (con diverso avb.vbmeta-version ):

Figura 1. La versione di 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 riporta 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 

Versione AVB corrispondente durante OTA

Per i dispositivi avviati 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 corrente sul dispositivo. Se la versione AVB ha un aggiornamento della versione principale durante un'OTA (ad esempio, da 0.0 a 1.0), il controllo VINTF per la compatibilità in OTA non riflette la compatibilità dopo l'OTA.

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

  1. Scegli i seguenti CL nell'albero dei sorgenti di Android 9:
  2. Definire BOARD_OTA_FRAMEWORK_VBMETA_VERSION_OVERRIDE per il dispositivo. Il suo valore dovrebbe essere uguale alla versione AVB prima dell'OTA, ovvero la versione AVB del dispositivo al momento del lancio.
  3. Ricostruisci il pacchetto OTA.

Queste modifiche posizionano automaticamente BOARD_OTA_FRAMEWORK_VBMETA_VERSION_OVERRIDE come compatibility-matrix.avb.vbmeta-version nei seguenti file:

  • /system/compatibility_matrix.xml (che non è usato 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 in /system/etc/vintf/compatibility_matrix.xml .

La versione VNDK corrisponde

La matrice di compatibilità del dispositivo dichiara la versione VNDK richiesta in compatibility-matrix.vendor-ndk.version . Se la matrice di compatibilità del dispositivo non ha un <vendor-ndk> , non viene imposto alcun requisito e quindi è sempre considerata una corrispondenza.

Se la matrice di compatibilità del dispositivo ha un <vendor-ndk> , viene cercata una voce <vendor-ndk> con una <version> corrispondente dal set di snapshot del fornitore VNDK fornito dal framework nel manifest del framework. Se tale voce non esiste, non c'è corrispondenza.

Se tale voce esiste, l'insieme di librerie enumerate nella matrice di compatibilità del dispositivo deve essere un sottoinsieme dell'insieme di librerie indicato nel manifesto del framework; in caso contrario, la voce non è considerata una corrispondenza.

  • In un caso speciale, se non vengono enumerate librerie nella matrice di compatibilità del dispositivo, la voce viene sempre considerata una corrispondenza, poiché 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 su 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 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 in quello snapshot. VNDK versione 26 viene ignorata.

La versione dell'SDK di sistema corrisponde

La matrice di compatibilità del dispositivo dichiara una serie di versioni di System SDK richieste in compatibility-matrix.system-sdk.version . Esiste una corrispondenza solo se il set è un sottoinsieme delle versioni di System SDK fornite come dichiarato in manifest.system-sdk.version nel manifest del framework.

  • Come caso speciale, se nella matrice di compatibilità del dispositivo non vengono enumerate versioni di System SDK, viene sempre considerata una corrispondenza, poiché 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 su System SDK:

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

Quindi, il framework deve fornire System SDK versione 26 e 27 da abbinare.

<!-- 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.