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 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 dai vari componenti.

La versione della matrice di compatibilità del framework corrisponde

Per abbinare un manifest del dispositivo con 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 . Altrimenti non c'è corrispondenza.

Quando la matrice di compatibilità del framework viene richiesta con libvintf , questa corrispondenza ha sempre successo perché libvintf apre il manifest del dispositivo, recupera la versione FCM di spedizione e restituisce la matrice di compatibilità del framework a quella versione FCM di spedizione (più alcuni HAL opzionali dalle matrici di compatibilità a FCM superiore Versioni).

Corrispondenze 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 richiesti.
  • 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. (Vedi l' esempio DRM di seguito.)
  • Più elementi <instance> e <regex-instance> all'interno dello stesso <hal> vengono valutati con una singola relazione AND quando è 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 è 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.
  • La 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 oltre la 2.7. Il proprietario del manifest corrispondente può comunque fornire 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.
Pertanto, un dispositivo con un 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; O

android.hardware.drm@1.x::IDrmFactory/default          // where x >= 0
android.hardware.drm@1.x::IDrmFactory/specific         // where x >= 0
OR
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

HAL AIDL

Tutte le versioni di Android successive ad Android 11 (escluso Android 11) supportano le versioni per HAL AIDL in VINTF. Le regole di corrispondenza per gli HAL AIDL sono simili a quelle degli HAL HIDL e 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 richiesti.
  • 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 è la scorciatoia 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 fornire 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 7 dell'API.
  • -7 è solo informativo e non influisce sul processo 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 sua matrice di compatibilità.

Esempio: corrispondenza HAL riuscita per più moduli

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

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 riportate dall'oggetto VINTF del dispositivo.

Abbina i rami del kernel

Ogni suffisso di ramo del kernel (ad esempio, 5.4- r ) è mappato su 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 sopra menzionato ha una versione FCM di destinazione 4 e la versione FCM del kernel è 5 (suffisso del ramo del kernel r ).
  • La versione del kernel FCM è 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 la versione 4 di FCM di destinazione (rilasciata 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 kernel 4.19-r , specificato nella versione 5 di FCM. Questi requisiti sono creati da kernel/configs/r/android-4.19 nell'albero dei sorgenti Android.

Esempio: determinare il ramo del kernel per GKI

Se il dispositivo utilizza l'immagine generica del kernel (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 utilizza per determinare la versione FCM del kernel. In questo esempio, android12 indica la versione 6 del kernel FCM (rilasciata in Android 12).

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

Corrisponde alle versioni del kernel

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

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

L'oggetto VINTF considera solo la sezione <kernel> dell'FCM con la versione FCM corrispondente con gli stessi ${ver} e ${major_rev} del kernel del dispositivo (ovvero, version="${ver}.${major_rev}.${matrix_minor_rev}") ; le altre sezioni vengono ignorate. Inoltre, la revisione minore del kernel deve essere un valore della matrice di compatibilità ( ${kernel_minor_rev} >= ${matrix_minor_rev} ;). Se nessuna sezione <kernel> soddisfa questi requisiti, si tratta di 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 selezionano insieme i requisiti del kernel dagli FCM:

Versione FCM target Versione FCM del kernel Versione del kernel Abbina con
3 (P) non specificato 4.4.106 Nessuna corrispondenza (mancata corrispondenza della versione secondaria)
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 fallisce (è necessario specificare la versione FCM del kernel per la versione 5 di FCM di destinazione)
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

Corrisponde alle configurazioni del kernel

Se la sezione <kernel> corrisponde, il processo continua tentando di far corrispondere gli elementi 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 presente nella matrice di compatibilità potrebbe essere presente o meno in /proc/config.gz .

Esempio: corrisponde alle 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 4096 o 0x1000 o 0X1000 .
  • <value type="int">0x1000</value> corrisponde 4096 o 0x1000 o 0X1000 .
  • <value type="int">0X1000</value> corrisponde 4096 o 0x1000 o 0X1000 .
  • <value type="tristate">y</value> corrisponde y .
  • <value type="tristate">m</value> corrisponde 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>

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 invece i requisiti del kernel dalla matrice nella versione 2 di FCM.

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

  • 4.9.84 (nessuna corrispondenza con la matrice a meno che non ci sia una sezione separata del kernel con <kernel version="4.9.x"> , dove x <= 84 )
  • 4.14.41 (nessuna corrispondenza con la matrice, più piccola della version )
  • 4.14.42 (corrispondenza alla matrice)
  • 4.14.43 (corrispondenza alla matrice)
  • 4.1.22 (nessuna corrispondenza con la matrice a meno che non ci sia una sezione separata del kernel 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 (comprese le virgolette), fino al carattere di nuova riga o # , con gli 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

Corrispondenza 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 sepolicy riportata 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 sepolicy è superiore o uguale alla versione minima per l'intervallo. La versione massima è puramente informativa.
  • <kernel-sepolicy-version> cioè la versione policydb. Deve essere inferiore al valore security_policyvers() riportato dal dispositivo.

Esempio: corrispondenza della politica 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 è una corrispondenza.
    • Se un dispositivo restituisce 31, è una corrispondenza.
  • La versione della policy SE deve essere una tra 25.0-∞ o 26.0-∞. Altrimenti non è una corrispondenza. (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 (ad esempio, 1.0, 2.1). Per i dettagli, fare riferimento a 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 nel sistema operativo Android ( init/fs_mgr )

La proprietà di sistema appare solo quando il corrispondente libavb è stato utilizzato per verificare i metadati AVB (e restituisce OK). È assente se si è verificato un errore di verifica (o non è avvenuta 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 diverse 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 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 l'OTA

Per i dispositivi lanciati con Android 9 o versioni precedenti, durante l'aggiornamento ad Android 10, i requisiti della versione AVB nella matrice di compatibilità del framework vengono confrontati con la versione AVB corrente sul dispositivo. Se la versione AVB presenta un aggiornamento di 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 le 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 alla versione AVB del dispositivo al momento del lancio.
  3. Ricostruisci il pacchetto OTA.

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

  • /system/compatibility_matrix.xml (che non è utilizzato 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, incluso /system/etc/vintf/compatibility_matrix.xml . Dopo l'OTA, il nuovo valore in /system/etc/vintf/compatibility_matrix.xml viene invece utilizzato per i controlli di compatibilità.

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 tag <vendor-ndk> , non viene imposto alcun requisito e quindi viene sempre considerata una corrispondenza.

Se la matrice di compatibilità del dispositivo ha un tag <vendor-ndk> , viene cercata una voce <vendor-ndk> con una <version> corrispondente dal set di snapshot del fornitore VNDK fornito dal framework nel manifesto 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 indicate nel manifesto del framework; in caso contrario, la voce non è considerata una corrispondenza.

  • Come 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 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>

L'esempio A corrisponde, perché la versione 27 di VNDK è 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 la versione 27 di VNDK è 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 un set di versioni dell'SDK di sistema richieste in compatibility-matrix.system-sdk.version . Esiste una corrispondenza solo se il set è un sottoinsieme delle versioni dell'SDK di sistema fornite come dichiarato in manifest.system-sdk.version nel manifesto del framework.

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

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

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