Regole di corrispondenza

Le due coppie di matrici di compatibilità e manifest 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 manifesto del dispositivo, nonché tra il manifesto del framework e la matrice di compatibilità del dispositivo.

Questa verifica viene effettuata in fase di compilazione, in OTA tempo di generazione pacchetto di aggiornamento, in fase di avvio, in test di compatibilità VTS.

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

Corrispondenze della versione della matrice di compatibilità del framework

Per trovare una manifesta dispositivo con una matrice di compatibilità quadro, la versione di spedizione FCM specificato dal manifest.target-level deve essere esattamente uguale alla versione FCM specificato compatibility-matrix.level . Altrimenti non c'è corrispondenza.

Quando la matrice di compatibilità quadro è richiesto con libvintf , questa partita è sempre successo, perché libvintf apre il manifesto dispositivo, recupera il FCM versione di spedizione, e restituisce la matrice di compatibilità quadro in quel versione FCM Spedizione (più alcuni HAL opzionali da matrici di compatibilità a più alto FCM versioni).

Partite HAL

La regola identifica HAL-adattamento delle versioni di hal elementi in un file manifesto che sono considerati essere supportati dal proprietario della matrice di compatibilità corrispondente.

HIDL e HAL nativi

Le regole di corrispondenza per HIDL e HAL nativi sono le seguenti.

  • Molteplici <hal> elementi sono valutati con un singolo e relazione.
  • Molteplici <version> elementi all'interno dello stesso <hal> hanno la relazione OR. Se ne vengono specificati due o più, deve essere implementata solo una delle versioni. (Vedere l' esempio DRM di seguito.)
  • Molteplici <instance> e <regex-instance> elementi all'interno dello stesso <hal> vengono valutati con un singolo e relazione. (Vedere l' 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 è la scorciatoia per 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 servire 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 la versione API 2.7.
  • -7 è solo informativo e non influisce sul processo di aggiornamento OTA.
Così, un dispositivo con un HAL alla versione 2.10 nel suo file manifesto sempre compatibile con una struttura che gli stati 2.5-7 nella sua matrice 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 venditore 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
O
android.hardware.drm@3.y::IDrmFactory/default          // where y >= 1
android.hardware.drm@3.y::IDrmFactory/specific         // where y >= 1

AND 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 confronto per HAL AIDL sono simili a quelli di HIDL e HAL nativi, salvo che non esistono nemmeno le principali versioni, e non v'è esattamente una versione per istanza HAL ( 1 se la versione non è specificato).

  • Molteplici <hal> elementi sono valutati con un singolo e relazione.
  • Molteplici <instance> e <regex-instance> elementi all'interno dello stesso <hal> vengono valutati con un singolo e relazione. (Vedere l' esempio 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 per 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 potrebbe essere richiesta, il che significa che il proprietario della matrice di compatibilità (framework o dispositivo) non richiederà versioni oltre la 7. Il proprietario del manifest corrispondente può comunque servire la versione 10 (come esempio) quando viene richiesta la 7 . Il proprietario della matrice di compatibilità sa solo che il servizio richiesto è compatibile con la versione API 7.
  • -7 è solo informativo e non influisce sul processo di aggiornamento OTA.
Così, un dispositivo con un HAL alla versione 10 nel suo file manifesto sempre compatibile con una struttura che gli stati 5-7 nella sua matrice compatibilità.

Esempio: corrispondenza HAL riuscita per più moduli

La matrice di compatibilità del framework indica le seguenti informazioni sulla versione per gli HAL di vibratori e fotocamere:

<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

Il <kernel> sezione della matrice di compatibilità quadro descrive i requisiti del framework del kernel di Linux sul dispositivo. Questa informazione è pensata per essere confrontato con l'informazioni sul kernel che viene riportato da oggetto VINTF del dispositivo.

Abbina i rami del kernel

Ogni suffisso ramo del kernel (per esempio, 5.4- r ) è associata a una versione unica del kernel FCM (ad esempio, 5). La mappatura è la stessa della mappatura tra le lettere di rilascio (ad esempio, R) e le versioni FCM (ad esempio, 5).

Test VTS impongono che il dispositivo indica esplicitamente la versione del kernel FCM nel manifesto dispositivo, /vendor/etc/vintf/manifest.xml , se una delle seguenti condizioni:

  • La versione FCM del kernel è diversa dalla versione FCM di destinazione. Ad esempio, il suddetto dispositivo ha una versione target FCM 4, e la sua versione del kernel FCM è 5 (kernel ramo suffisso r ).
  • La versione del kernel FCM è maggiore o uguale a 5 (kernel ramo suffisso 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 è dotato di destinazione FCM versione 4 (uscito nel Android 10), ma corre kernel dal 4.19-r ramo, il manifesto dispositivo dovrebbe specificare quanto segue:

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

I controlli degli oggetti del kernel VINTF compatibilità rispetto ai requisiti di 4.19-r ramo del kernel, che è specificato nel FCM versione 5. Questi requisiti sono costruiti da kernel/configs/r/android-4.19 nell'albero dei sorgenti di Android.

Corrisponde alle versioni del kernel

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

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

L'oggetto VINTF considera solo il <kernel> sezione dal FCM coordinata con il modello FCM con la stessa ${ver} e ${major_rev} come il kernel del dispositivo (ad esempio, version="${ver}.${major_rev}.${matrix_minor_rev}") ; altre sezioni vengono ignorate. Inoltre, la revisione minore dal kernel deve essere un valore dalla matrice di compatibilità ( ${kernel_minor_rev} >= ${matrix_minor_rev} ;). Se nessun <kernel> sezione risponde a questi requisiti, è un non-partita.

Esempio: selezionare i requisiti per la corrispondenza

Si consideri il seguente caso ipotetico in cui FCM nel /system/etc/vintf dichiarare i seguenti requisiti (intestazione e piè tag 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 selezionano insieme i requisiti del kernel dagli FCM:

Versione FCM di destinazione Kernel versione FCM Versione del kernel Abbina con
3 (P) non specificato 4.4.106 Nessuna corrispondenza (mancata corrispondenza della versione minore)
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 (senza 4.19-p ramo del kernel)
3 (P) 4 (Q) 4.19.42 4.19-q
4 (Q) non specificato 4.4.107 Nessuna corrispondenza (senza 4.4-q ramo del kernel)
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 (senza 5.4-q ramo del kernel)
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 (deve 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 il <kernel> sezione corrisponde, il processo continua, cercando di abbinare config elementi contro /proc/config.gz . Per ciascun elemento di configurazione nella matrice di compatibilità, si alza /proc/config.gz per vedere se la configurazione è presente. Quando un elemento di configurazione è impostato su n nella matrice di compatibilità per l'abbinamento <kernel> sezione, deve essere assente dal /proc/config.gz . Infine, un elemento di configurazione non nella matrice di compatibilità può o non può essere presente in /proc/config.gz .

Esempio: corrispondenza delle configurazioni del kernel

  • <value type="string">bar</value> partite "bar" . Le quotazioni sono omessi nella matrice compatibilità ma presente in /proc/config.gz .
  • <value type="int">4096</value> partite 4096 o 0x1000 o 0X1000 .
  • <value type="int">0x1000</value> partite 4096 o 0x1000 o 0X1000 .
  • <value type="int">0X1000</value> partite 4096 o 0x1000 o 0X1000 .
  • <value type="tristate">y</value> partite y .
  • <value type="tristate">m</value> partite 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> partite 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 abbinato per primo. Il ramo del kernel è specificato nel manifesto dispositivo in manifest.kernel.target-level , che per impostazione predefinita manifest.level se la prima non è specificato. Se il ramo del kernel nel dispositivo manifesta:

  • è 1, procede al passaggio successivo e verifica la versione del kernel.
  • è 2, nessuna corrispondenza con la matrice. Gli oggetti VINTF leggono invece i requisiti del kernel dalla matrice alla versione 2 di FCM.

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

  • 4.9.84 (nessuna corrispondenza alla matrice a meno che non ci sia una sezione separata con kernel <kernel version="4.9.x"> , dove x <= 84 )
  • 4.14.41 (nessuna corrispondenza alla matrice, più piccolo di version )
  • 4.14.42 (corrisponde alla matrice)
  • 4.14.43 (corrisponde alla matrice)
  • 4.1.22 (nessuna corrispondenza alla matrice a meno che non ci sia una sezione separata con kernel <kernel version="4.1.x"> dove x <= 22 )

Dopo l'appropriato <kernel> è selezionato sezione, per ogni <config> articolo con valore diverso da n , ci aspettiamo che la voce corrispondente di essere presente in /proc/config.gz ; per ogni <config> elemento con un valore n , ci aspettiamo che la voce corrispondente a non essere presenti in /proc/config.gz . Ci aspettiamo che il contenuto di <value> in modo che corrisponda esattamente il testo dopo il segno di uguale (tra cui le virgolette), fino al carattere di nuova riga o # , con spazi iniziali e finali tronca.

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 politiche SE

La politica SE richiede le seguenti corrispondenze:

  • <sepolicy-version> definisce un intervallo chiuso di versioni minori 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; è una corrispondenza se la versione di sepolicy è superiore o uguale alla versione minima per l'intervallo. La versione massima è puramente informativa.
  • <kernel-sepolicy-version> cioè policydb versione. Deve essere inferiore ai security_policyvers() riportati dal dispositivo.

Esempio: corrispondenza dei criteri SE riuscita

La matrice di compatibilità del framework indica 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 è una corrispondenza.
    • Se un dispositivo restituisce 31, è una corrispondenza.
  • La versione della politica SE deve essere una tra 25.0-∞ o 26.0-∞. Altrimenti non è una corrispondenza. (Il " -3 " dopo " 26.0 " è puramente informativo.)

Corrispondenze della versione AVB

La versione AVB contiene una versione MAJOR e una versione MINOR, con il formato MAJOR.MINOR (es. 1.0, 2.1). Per ulteriori informazioni, fare riferimento a delle versioni e la compatibilità . La versione AVB ha le seguenti proprietà di sistema:

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

La proprietà di sistema appare solo quando il libavb corrispondente è stato utilizzato per verificare i metadati AVB (e restituisce OK). È assente se si è verificato un errore di verifica (o non si è verificata affatto).

Una corrispondenza di compatibilità confronta quanto segue:

  • sysprop ro.boot.vbmeta.avb_version con avb.vbmeta-version dalla matrice di compatibilità quadro;
    • 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 da quadro matrice di compatibilità.
    • ro.boot.avb_version.MAJOR == avb.vbmeta-version.MAJOR
    • ro.boot.avb_version.MINOR >= avb.vbmeta-version.MINOR

Il bootloader o Android OS potrebbero contenere due copie di libavb biblioteche, ognuna con una diversa versione maggiore per i dispositivi di aggiornamento e dispositivi di lancio. In questo caso, la stessa immagine del sistema non firmato può essere condiviso, ma le immagini del sistema firmati finali sono differenti (con differenti avb.vbmeta-version ):

Figura 1. Versione AVB partite ( /system è P, tutte le altre partizioni sono O).


Partite figura versione 2. CGA (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 

Corrispondenza della versione AVB 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 falsa versione AVB nel pacchetto OTA ( compatibility.zip ) per passare il controllo. Fare così:

  1. Seleziona 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 quando è stato lanciato.
  3. Ricostruisci il pacchetto OTA.

Questi cambiamenti pongono 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 altre matrici di compatibilità quadro, tra cui /system/etc/vintf/compatibility_matrix.xml . Dopo l'OTA, il nuovo valore in /system/etc/vintf/compatibility_matrix.xml viene utilizzato per i controlli di compatibilità, invece.

Corrispondenze versione VNDK

La matrice di compatibilità dispositivo dichiara la versione VNDK required compatibility-matrix.vendor-ndk.version . Se la matrice di compatibilità dispositivo non ha una <vendor-ndk> tag, vengono imposti requisiti, e quindi è sempre considerato una corrispondenza.

Se la matrice di compatibilità dispositivo ha un <vendor-ndk> tag, un <vendor-ndk> voce con un corrispondente <version> viene cercato dal set di istantanee vendor VNDK che è fornito dal quadro nel manifesto quadro. Se tale voce non esiste, non c'è corrispondenza.

Se tale voce esiste, l'insieme di librerie enumerato 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.

  • Come caso speciale, se nessuna libreria è enumerata nella matrice di compatibilità del dispositivo, la voce è 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 su VNDK:

<!-- Example Device Compatibility Matrix -->
<vendor-ndk>
    <version>27</version>
    <library>libjpeg.so</library>
    <library>libbase.so</library>
</vendor-ndk>

Nel manifesto 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>

Esempio A è una partita, perché VNDK versione 27 è nel manifesto quadro, 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 manifesto quadro, libjpeg.so non è supportato dal framework in quella istantanea. VNDK versione 26 viene ignorata.

Corrispondenza della versione dell'SDK di sistema

La matrice di compatibilità dispositivo dichiara un insieme di richiesta versione Sistema SDK compatibility-matrix.system-sdk.version . C'è una corrispondenza solo se l'insieme è un sottoinsieme di versioni fornite Sistema SDK dichiarate nella manifest.system-sdk.version nel manifesto quadro.

  • Come caso speciale, se nessuna versione dell'SDK di sistema viene enumerata nella matrice di compatibilità del dispositivo, 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 su System SDK:

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

Quindi, il framework deve fornire la versione 26 e 27 dell'SDK di sistema in modo che corrisponda.

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