Reglas de coincidencia

Los dos pares de matrices de compatibilidad y manifiestos deben reconciliarse para verificar que el marco y la implementación del proveedor puedan funcionar entre sí. Esta verificación se realiza correctamente cuando la matriz de compatibilidad del marco coincide con el manifiesto del dispositivo, así como entre el manifiesto del marco y la matriz de compatibilidad del dispositivo.

Esta verificación se realiza en el momento de la compilación, en el momento de la generación del paquete de actualización OTA , en el momento del arranque y en las pruebas de compatibilidad de VTS.

Las siguientes secciones detallan las reglas de coincidencia utilizadas por varios componentes.

Coincidencias de la versión de la matriz de compatibilidad del marco

Para hacer coincidir un manifiesto de dispositivo con una matriz de compatibilidad de marco, la versión de FCM de envío especificada por manifest.target-level debe ser exactamente igual a la versión de FCM especificada por compatibility-matrix.level . De lo contrario no hay coincidencia.

Cuando se solicita la matriz de compatibilidad del marco con libvintf , esta coincidencia siempre tiene éxito porque libvintf abre el manifiesto del dispositivo, recupera la versión de FCM de envío y devuelve la matriz de compatibilidad del marco en esa versión de FCM de envío (más algunas HAL opcionales de las matrices de compatibilidad en FCM más alto). Versiones).

coincidencias HAL

La regla de coincidencia HAL identifica las versiones de los elementos hal en un archivo de manifiesto que se considera compatible con el propietario de la matriz de compatibilidad correspondiente.

HIDL y HAL nativos

Las reglas de coincidencia para HIDL y HAL nativas son las siguientes.

• Varios elementos <hal> se evalúan con una sola relación AND .
• Los elementos <hal> pueden tener <hal optional="true"> para marcarlos como no necesarios.
• Múltiples elementos <version> dentro del mismo <hal> tienen la relación OR . Si se especifican dos o más, solo se necesita implementar una de las versiones. (Consulte el ejemplo de DRM a continuación).
• Varios elementos <instance> y <regex-instance> dentro del mismo <hal> se evalúan con una sola relación AND cuando se requiere <hal> . (Ver el Ejemplo de DRM a continuación.)

Ejemplo: Coincidencia HAL exitosa para un módulo

Para una HAL en la versión 2.5, la regla de coincidencia es la siguiente:

Matriz	Manifiesto coincidente
2.5	2.5-2.∞. En la matriz de compatibilidad, 2.5 es la abreviatura de 2.5-5 .
2.5-7	2.5-2.∞. Indica lo siguiente: 2.5 es la versión mínima requerida, lo que significa que un manifiesto que proporciona HAL 2.0-2.4 no es compatible. 2.7 es la versión máxima que se puede solicitar, lo que significa que el propietario de la matriz de compatibilidad (marco o dispositivo) no solicitará versiones superiores a la 2.7. El propietario del manifiesto coincidente aún puede publicar la versión 2.10 (como ejemplo) cuando se solicita la 2.7. El propietario de la matriz de compatibilidad solo sabe que el servicio solicitado es compatible con la versión 2.7 de la API. -7 es solo informativo y no afecta el proceso de actualización OTA. Por lo tanto, un dispositivo con HAL en la versión 2.10 en su archivo de manifiesto sigue siendo compatible con un marco que establece 2.5-7 en su matriz de compatibilidad.

Ejemplo: Coincidencia HAL exitosa para el módulo DRM

La matriz de compatibilidad del marco establece la siguiente información de versión para 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 proveedor debe implementar UNA de las siguientes instancias; 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

Y también debe implementar todas estas instancias:

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

Todas las versiones de Android posteriores a Android 11 (excepto Android 11) admiten versiones para AIDL HAL en VINTF. Las reglas de coincidencia para las HAL de AIDL son similares a las de HIDL y las HAL nativas, excepto que no hay versiones principales y hay exactamente una versión por instancia de HAL ( 1 si no se especifica la versión).

• Varios elementos <hal> se evalúan con una sola relación AND .
• Los elementos <hal> pueden tener <hal optional="true"> para marcarlos como no necesarios.
• Varios elementos <instance> y <regex-instance> dentro del mismo <hal> se evalúan con una sola relación AND cuando se requiere <hal> . (Ver el ejemplo de vibrador a continuación.)

Ejemplo: Coincidencia HAL exitosa para un módulo

Para una HAL en la versión 5, la regla de coincidencia es la siguiente:

Matriz	Manifiesto coincidente
5	5-∞. En la matriz de compatibilidad, 5 es la abreviatura de 5-5 .
5-7	5-∞. Indica lo siguiente: 5 es la versión mínima requerida, lo que significa que un manifiesto que proporciona HAL 1-4 no es compatible. 7 es la versión máxima que se puede solicitar, lo que significa que el propietario de la matriz de compatibilidad (marco o dispositivo) no solicitará versiones superiores a la 7. El propietario del manifiesto coincidente aún puede publicar la versión 10 (como ejemplo) cuando se solicita la 7. . El propietario de la matriz de compatibilidad solo sabe que el servicio solicitado es compatible con la versión 7 de la API. -7 es solo informativo y no afecta el proceso de actualización OTA. Por lo tanto, un dispositivo con HAL en la versión 10 en su archivo de manifiesto sigue siendo compatible con un marco que establece 5-7 en su matriz de compatibilidad.

Ejemplo: Coincidencia HAL exitosa para múltiples módulos

La matriz de compatibilidad del marco establece la siguiente información de versión para HAL de vibrador y cámara:

<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 proveedor debe implementar todas estas instancias:

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

Coincidencias del núcleo

La sección <kernel> de la matriz de compatibilidad del marco describe los requisitos del marco del kernel de Linux en el dispositivo. Esta información está destinada a compararse con la información sobre el kernel que informa el objeto VINTF del dispositivo.

Hacer coincidir las ramas del kernel

Cada sufijo de rama del kernel (por ejemplo, 5.4- r ) se asigna a una versión única de FCM del kernel (por ejemplo, 5). La asignación es la misma que la asignación entre letras de versión (por ejemplo, R) y versiones de FCM (por ejemplo, 5).

Las pruebas de VTS exigen que el dispositivo especifique explícitamente la versión de FCM del kernel en el manifiesto del dispositivo, /vendor/etc/vintf/manifest.xml , si se cumple una de las siguientes condiciones:

• La versión de kernel de FCM es diferente de la versión de destino de FCM. Por ejemplo, el dispositivo antes mencionado tiene una versión de FCM de destino 4, y su versión de FCM de kernel es 5 (sufijo de rama de kernel r ).
• La versión de FCM del núcleo es mayor o igual a 5 (sufijo de rama del núcleo r ).

Nota: Si la versión de FCM del kernel es igual a la versión de FCM de destino y son mayores o iguales a 5, el archivo de origen del manifiesto del dispositivo especificado por DEVICE_MANIFEST_FILE no tiene que especificar la versión de FCM del kernel. assemble_vintf infiere automáticamente la versión de FCM del kernel a partir de la versión de FCM de destino si la versión de FCM de destino es mayor o igual a 5.

Las pruebas de VTS imponen que, si se especifica la versión de FCM del kernel, la versión de FCM del kernel es mayor o igual que la versión de FCM de destino en el manifiesto del dispositivo.

Ejemplo: determinar la rama del kernel

Si el dispositivo tiene la versión 4 de FCM de destino (lanzada en Android 10), pero ejecuta el kernel desde la rama 4.19-r , el manifiesto del dispositivo debe especificar lo siguiente:

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

El objeto VINTF comprueba la compatibilidad del kernel con los requisitos de la rama del kernel 4.19-r , que se especifica en la versión 5 de FCM. Estos requisitos se crean a partir de kernel/configs/r/android-4.19 en el árbol de fuentes de Android.

Ejemplo: determinar la rama del kernel para GKI

Si el dispositivo utiliza la imagen genérica del kernel (GKI) y la cadena de versión del kernel de /proc/version es la siguiente:

5.4.42-android12-0-00544-ged21d463f856

Luego, el objeto VINTF obtiene la versión de Android de la versión del kernel y la usa para determinar la versión de FCM del kernel. En este ejemplo, android12 significa kernel FCM versión 6 (lanzado en Android 12).

Para obtener detalles sobre cómo se analiza la cadena de versión del kernel, consulte Control de versiones de GKI .

Hacer coincidir las versiones del kernel

Una matriz puede incluir múltiples secciones <kernel> , cada una con un atributo de version diferente usando el formato:

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

El objeto VINTF considera solo la sección <kernel> del FCM con la versión FCM coincidente con el mismo ${ver} y ${major_rev} que el kernel del dispositivo (es decir, version="${ver}.${major_rev}.${matrix_minor_rev}") ; otras secciones son ignoradas. Además, la revisión menor del kernel debe ser un valor de la matriz de compatibilidad ( ${kernel_minor_rev} >= ${matrix_minor_rev} ;). Si ninguna sección <kernel> cumple con estos requisitos, no coincide.

Ejemplo: Seleccione los requisitos para la coincidencia

Considere el siguiente caso hipotético donde los FCM en /system/etc/vintf declaran los siguientes requisitos (se omiten las etiquetas de encabezado y pie de página):

<!-- 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 versión de destino de FCM, la versión de kernel de FCM y la versión de kernel juntas seleccionan los requisitos del kernel de los FCM:

Versión de destino de FCM	Versión de núcleo FCM	Versión del núcleo	Juntar con
3 (P)	no especificado	4.4.106	Sin coincidencia (discrepancia de versión secundaria)
3 (P)	no especificado	4.4.107	4.4-p
3 (P)	no especificado	4.19.42	4.19-q (ver nota a continuación)
3 (P)	no especificado	5.4.41	5.4-r (ver nota a continuación)
3 (P)	3 (P)	4.4.107	4.4-p
3 (P)	3 (P)	4.19.42	Sin coincidencia (sin rama del kernel 4.19-p )
3 (P)	4 (Q)	4.19.42	4.19-q
4 (Q)	no especificado	4.4.107	Sin coincidencia (sin rama del kernel 4.4-q )
4 (Q)	no especificado	4.9.165	4.9-q
4 (Q)	no especificado	5.4.41	5.4-r (ver nota a continuación)
4 (Q)	4 (Q)	4.9.165	4.9-q
4 (Q)	4 (Q)	5.4.41	Sin coincidencia (sin rama del kernel 5.4-q )
4 (Q)	5 (D)	4.14.105	4.14-r
4 (Q)	5 (D)	5.4.41	5.4-r
5 (D)	no especificado	ningún	VTS falla (debe especificar la versión de FCM del kernel para la versión 5 de FCM de destino)
5 (D)	4 (Q)	ningún	VTS falla (versión de FCM del núcleo <versión de FCM de destino)
5 (D)	5 (D)	4.14.180	4.14-r

Nota: Para dispositivos con una versión de FCM de destino inferior a 5 (R) y una versión de FCM de kernel no especificada, el objeto VINTF selecciona la rama de kernel con el sufijo más bajo que es mayor que la versión de FCM de destino con la versión de kernel coincidente. En el ejemplo anterior, un dispositivo con una versión de FCM objetivo de 3 (P) usa la rama del kernel 4.19 4.19-q porque 4.19-q tiene el sufijo más bajo entre todas las ramas del kernel 4.19-* , [4.19-q, 4.19-r, 4.19-s] . Este comportamiento de selección de requisitos no está permitido para dispositivos con una versión de FCM de destino de 5 (R) o superior, porque se debe especificar la versión de FCM del kernel.

Hacer coincidir las configuraciones del kernel

Si la sección <kernel> coincide, el proceso continúa intentando hacer coincidir los elementos de config con /proc/config.gz . Para cada elemento de configuración en la matriz de compatibilidad, busca /proc/config.gz para ver si la configuración está presente. Cuando un elemento de configuración se establece en n en la matriz de compatibilidad para la sección correspondiente <kernel> , debe estar ausente de /proc/config.gz . Finalmente, un elemento de configuración que no esté en la matriz de compatibilidad puede o no estar presente en /proc/config.gz .

Ejemplo: hacer coincidir las configuraciones del kernel

• <value type="string">bar</value> coincide con "bar" . Las comillas se omiten en la matriz de compatibilidad pero están presentes en /proc/config.gz .
• <value type="int">4096</value> coincide con 4096 o 0x1000 o 0X1000 .
• <value type="int">0x1000</value> coincide con 4096 o 0x1000 o 0X1000 .
• <value type="int">0X1000</value> coincide con 4096 o 0x1000 o 0X1000 .
• <value type="tristate">y</value> coincide con y .
• <value type="tristate">m</value> coincide con m .
• <value type="tristate">n</value> significa que el elemento de configuración NO debe existir en /proc/config.gz .
• <value type="range">1-0x3</value> coincide con 1 , 2 o 3 , o su equivalente hexadecimal.

Ejemplo: Coincidencia de kernel exitosa

Una matriz de compatibilidad de framework con FCM versión 1 tiene la siguiente información del 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>

La rama del núcleo se empareja primero. La rama del kernel se especifica en el manifiesto del dispositivo en manifest.kernel.target-level , que por defecto es manifest.level si no se especifica el primero. Si la rama del kernel en el manifiesto del dispositivo:

• es 1, continúa con el siguiente paso y verifica la versión del kernel.
• es 2, no coincide con la matriz. Los objetos VINTF leen los requisitos del núcleo de la matriz en la versión 2 de FCM.

Entonces, la versión del kernel se empareja. Si un dispositivo en uname() informa:

• 4.9.84 (no coincide con la matriz a menos que haya una sección de kernel separada con <kernel version="4.9.x"> , donde x <= 84 )
• 4.14.41 (sin coincidencia con la matriz, más pequeña que la version )
• 4.14.42 (coincidencia con matriz)
• 4.14.43 (coincidencia con matriz)
• 4.1.22 (no coincide con la matriz a menos que haya una sección del kernel separada con <kernel version="4.1.x"> donde x <= 22 )

Después de seleccionar la sección <kernel> adecuada, para cada elemento <config> con un valor distinto de n , esperamos que la entrada correspondiente esté presente en /proc/config.gz ; para cada elemento <config> con valor n , esperamos que la entrada correspondiente no esté presente en /proc/config.gz . Esperamos que el contenido de <value> coincida exactamente con el texto después del signo igual (incluidas las comillas), hasta el carácter de nueva línea o # , con los espacios en blanco iniciales y finales truncados.

La siguiente configuración del kernel es un ejemplo de una coincidencia exitosa:

# 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 siguiente configuración del núcleo es un ejemplo de una coincidencia fallida:

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

Coincidencias de política SE

La política SE requiere las siguientes coincidencias:

• <sepolicy-version> define un rango cerrado de versiones secundarias para cada versión principal. La versión de la política de seguridad informada por el dispositivo debe estar dentro de uno de estos rangos para ser compatible con el marco. Las reglas de coincidencia son similares a las versiones HAL; es una coincidencia si la versión de sepolicy es superior o igual a la versión mínima para el rango. La versión máxima es puramente informativa.
• <kernel-sepolicy-version> es decir, versión de policydb. Debe ser menor que security_policyvers() informado por el dispositivo.

Ejemplo: Coincidencia de política de SE exitosa

La matriz de compatibilidad del marco establece la siguiente información de política:

<sepolicy>
    <kernel-sepolicy-version>30</kernel-sepolicy-version>
    <sepolicy-version>25.0</sepolicy-version>
    <sepolicy-version>26.0-3</sepolicy-version>
</sepolicy>

En el dispositivo:

• El valor devuelto por security_policyvers() debe ser mayor o igual a 30. De lo contrario, no es una coincidencia. Por ejemplo:
  • Si un dispositivo devuelve 29, no es una coincidencia.
  • Si un dispositivo devuelve 31, es una coincidencia.
• La versión de la política SE debe ser una de 25.0-∞ o 26.0-∞. De lo contrario, no es un partido. (El " -3 " después de " 26.0 " es puramente informativo).

Coincidencias de la versión AVB

La versión AVB contiene una versión MAYOR y una versión MENOR, con el formato MAYOR.MENOR (p. ej., 1.0, 2.1). Para obtener más información, consulte Control de versiones y compatibilidad . La versión AVB tiene las siguientes propiedades del sistema:

• ro.boot.vbmeta.avb_version es la versión libavb en el gestor de arranque
• ro.boot.avb_version es la versión libavb en el sistema operativo Android ( init/fs_mgr )

La propiedad del sistema aparece solo cuando se ha utilizado el libavb correspondiente para verificar los metadatos de AVB (y devuelve OK). Está ausente si se produjo un error de verificación (o no se produjo ninguna verificación).

Una coincidencia de compatibilidad compara lo siguiente:

• sysprop ro.boot.vbmeta.avb_version con avb.vbmeta-version de la matriz de compatibilidad del marco;
  • 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 de la matriz de compatibilidad del marco.
  • ro.boot.avb_version.MAJOR == avb.vbmeta-version.MAJOR
  • ro.boot.avb_version.MINOR >= avb.vbmeta-version.MINOR

El cargador de arranque o el sistema operativo Android pueden contener dos copias de bibliotecas libavb , cada una con una versión PRINCIPAL diferente para dispositivos de actualización y dispositivos de inicio. En este caso, se puede compartir la misma imagen del sistema sin firmar , pero las imágenes finales del sistema con firma son diferentes (con diferentes avb.vbmeta-version ):

Figura 1. Coincidencias de versión de AVB ( /system es P, todas las demás particiones son O).

Figura 2. Coincidencias de versiones de AVB (todas las particiones son P).

Ejemplo: Coincidencia de versión AVB exitosa

La matriz de compatibilidad del marco establece la siguiente información de AVB:

<avb>
    <vbmeta-version>2.1</vbmeta-version>
</avb>

En el 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 

Versión AVB coincidente durante OTA

Nota: Esta sección no se aplica a los dispositivos que se actualizan a Android 11.

Para dispositivos lanzados con Android 9 o anterior, al actualizar a Android 10, los requisitos de la versión de AVB en la matriz de compatibilidad del marco se comparan con la versión actual de AVB en el dispositivo. Si la versión de AVB tiene una actualización de versión principal durante una OTA (por ejemplo, de 0.0 a 1.0), la comprobación de compatibilidad de VINTF en OTA no refleja la compatibilidad después de la OTA.

Para mitigar el problema, un OEM puede colocar una versión AVB falsa en el paquete OTA ( compatibility.zip ) para pasar la verificación. Para hacerlo:

1. Seleccione las siguientes CL para el árbol fuente de Android 9:
   • CL 732261
   • CL 732262
2. Defina BOARD_OTA_FRAMEWORK_VBMETA_VERSION_OVERRIDE para el dispositivo. Su valor debe ser igual a la versión AVB antes de la OTA, es decir, la versión AVB del dispositivo cuando se lanzó.
3. Reconstruya el paquete OTA.

Estos cambios colocan automáticamente BOARD_OTA_FRAMEWORK_VBMETA_VERSION_OVERRIDE como compatibility-matrix.avb.vbmeta-version en los siguientes archivos:

• /system/compatibility_matrix.xml (que no se usa en Android 9) en el dispositivo
• system_matrix.xml en compatibility.zip en el paquete OTA

Estos cambios no afectan otras matrices de compatibilidad de framework, incluido /system/etc/vintf/compatibility_matrix.xml . Después de la OTA, el nuevo valor en /system/etc/vintf/compatibility_matrix.xml se usa para las comprobaciones de compatibilidad.

Coincidencias de versión de VNDK

La matriz de compatibilidad de dispositivos declara la versión VNDK requerida en compatibility-matrix.vendor-ndk.version . Si la matriz de compatibilidad de dispositivos no tiene una etiqueta <vendor-ndk> , no se imponen requisitos y, por lo tanto, siempre se considera una coincidencia.

Si la matriz de compatibilidad de dispositivos tiene una etiqueta <vendor-ndk <vendor-ndk> , se busca una entrada <vendor-ndk> con una <version> coincidente en el conjunto de instantáneas de proveedores de VNDK que proporciona el marco en el manifiesto del marco. Si tal entrada no existe, no hay coincidencia.

Si tal entrada existe, el conjunto de bibliotecas enumeradas en la matriz de compatibilidad de dispositivos debe ser un subconjunto del conjunto de bibliotecas establecido en el manifiesto del marco; de lo contrario, la entrada no se considera una coincidencia.

• Como caso especial, si no se enumeran bibliotecas en la matriz de compatibilidad de dispositivos, la entrada siempre se considera una coincidencia, porque el conjunto vacío es un subconjunto de cualquier conjunto.

Ejemplo: Coincidencia de versión de VNDK exitosa

Si la matriz de compatibilidad de dispositivos establece el siguiente requisito en VNDK:

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

En el manifiesto del marco, solo se considera la entrada con la versión 27.

<!-- Framework Manifest Example A -->
<vendor-ndk>
    <version>27</version>
    <library>libjpeg.so</library>
    <library>libbase.so</library>
    <library>libfoo.so</library>
</vendor-ndk>

El ejemplo A es una coincidencia, porque la versión 27 de VNDK está en el manifiesto del marco y {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>

El ejemplo B no es una coincidencia. Aunque la versión 27 de VNDK está en el manifiesto del marco, libjpeg.so no es compatible con el marco en esa instantánea. Se ignora la versión 26 de VNDK.

Coincidencias de la versión del SDK del sistema

La matriz de compatibilidad de dispositivos declara un conjunto de versiones requeridas del SDK del sistema en compatibility-matrix.system-sdk.version . Hay una coincidencia solo si el conjunto es un subconjunto de las versiones del SDK del sistema proporcionadas como se declara en manifest.system-sdk.version en el manifiesto del marco.

• Como caso especial, si no se enumeran versiones del SDK del sistema en la matriz de compatibilidad de dispositivos, siempre se considera una coincidencia, porque el conjunto vacío es un subconjunto de cualquier conjunto.

Ejemplo: coincidencia exitosa de la versión del SDK del sistema

Si la matriz de compatibilidad de dispositivos establece el siguiente requisito en el SDK del sistema:

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

Luego, el marco debe proporcionar las versiones 26 y 27 del SDK del sistema para que coincidan.

<!-- Framework Manifest Example A -->
<system-sdk>
    <version>26</version>
    <version>27</version>
</system-sdk>

El ejemplo A es una coincidencia.

<!-- Framework Manifest Example B -->
<system-sdk>
    <version>26</version>
    <version>27</version>
    <version>28</version>
</system-sdk>

El ejemplo B es una coincidencia.

<!-- Framework Manifest Example C -->
<system-sdk>
    <version>26</version>
</system-sdk>

El ejemplo C no coincide porque no se proporciona la versión 27 del SDK del sistema.