Reglas de coincidencia

Los dos pares de matrices de compatibilidad y manifiestos deben reconciliarse para verificar que el framework y la implementación del proveedor puedan funcionar en conjunto. Esta verificación se realiza correctamente cuando hay una coincidencia entre la matriz de compatibilidad del framework y el manifiesto del dispositivo, así como entre el manifiesto del framework y la matriz de compatibilidad del dispositivo.

Esta verificación se realiza en el momento de la compilación, en el momento de generar paquetes de actualización OTA, en el momento del inicio y en las pruebas de compatibilidad de VTS.

En las siguientes secciones, se detallan las reglas de coincidencia que usan varios componentes.

Coincidencias de la versión de la matriz de compatibilidad con el framework

Para que un manifiesto de dispositivo coincida con una matriz de compatibilidad del framework, la versión de FCM de envío que especifica manifest.target-level debe ser exactamente igual a la versión de FCM que especifica compatibility-matrix.level. De lo contrario, no hay coincidencia.

Cuando se solicita la matriz de compatibilidad del framework con libvintf, esta coincidencia siempre se realiza correctamente porque libvintf abre el manifiesto del dispositivo, recupera la versión de FCM de lanzamiento y muestra la matriz de compatibilidad del framework en esa versión de FCM de lanzamiento (además de algunos HAL opcionales de las matrices de compatibilidad en versiones de FCM posteriores).

Coincidencias de HAL

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

HIDL y HAL nativos

Las reglas de coincidencia para el HIDL y las HALs nativas son las siguientes:

• Se evalúan varios elementos <hal> con una sola relación AND.
• Los elementos <hal> pueden tener <hal optional="true"> para marcarlos como no obligatorios.
• Varios elementos <version> dentro del mismo <hal> tienen la relación O. Si se especifican dos o más, solo se debe implementar una de las versiones. (consulta el ejemplo de la DRM a continuación).
• Varios elementos <instance> y <regex-instance> dentro de la misma <hal> se evalúan con una sola relación Y cuando se requiere <hal>. (consulta el <ahref="#drm">ejemplo de DRM a continuación).</ahref="#drm">

Ejemplo: Coincidencia correcta de HAL para un módulo

Para un 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 (framework o dispositivo) no solicitará versiones posteriores a la 2.7. El propietario del manifiesto coincidente aún puede publicar la versión 2.10 (a modo de 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 una HAL en la versión 2.10 en su archivo de manifiesto sigue siendo compatible con un framework que indica 2.5-7 en su matriz de compatibilidad.

Ejemplo: Coincidencia correcta de HAL para el módulo de DRM

La matriz de compatibilidad del framework indica la siguiente información de versión para el HAL de DRM:

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

Los proveedores deben implementar UNA de las siguientes instancias:

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 de AIDL

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

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

Ejemplo: Coincidencia correcta de HAL para un módulo

Para un 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 de 1 a 4 no es compatible. 7 es la versión máxima que se podría solicitar, lo que significa que el propietario de la matriz de compatibilidad (framework o dispositivo) no solicitará versiones posteriores a la 7. El propietario del manifiesto coincidente aún puede publicar la versión 10 (a modo de 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 una HAL en la versión 10 en su archivo de manifiesto seguirá siendo compatible con un marco de trabajo que indique 5-7 en su matriz de compatibilidad.

Ejemplo: coincidencia correcta de HAL para varios módulos

La matriz de compatibilidad del framework indica la siguiente información de versión para los 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 de kernel

En la sección <kernel> de la matriz de compatibilidad del framework, se describen los requisitos del framework del kernel de Linux en el dispositivo. Esta información debe coincidir con la información sobre el kernel que informa el objeto VINTF del dispositivo.

Cómo hacer coincidir las ramas de 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 las letras de las versiones (por ejemplo, R) y las versiones de FCM (por ejemplo, 5).

Las pruebas de VTS garantizan 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 FCM del kernel es diferente de la versión de FCM de destino. Por ejemplo, el dispositivo antes mencionado tiene una versión objetivo de FCM 4 y su versión de FCM del kernel es 5 (sufijo de rama del kernel r).
• La versión de FCM del kernel es mayor o igual que 5 (sufijo de rama del kernel r).

Las pruebas de VTS aplican que, si se especifica la versión de FCM del kernel, esta sea superior o igual a la versión de FCM objetivo en el manifiesto del dispositivo.

Ejemplo: Determina la rama de kernel

Si el dispositivo tiene como objetivo la versión 4 de FCM (lanzada en Android 10), pero ejecuta el kernel de 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 verifica 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 compilan a partir de kernel/configs/r/android-4.19 en el árbol de fuentes de Android.

Ejemplo: Determina la rama del kernel para GKI

Si el dispositivo usa la imagen genérica de kernel (GKI) y la cadena de lanzamiento 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 la versión 6 de FCM del kernel (lanzada en Android 12).

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

Cómo hacer coincidir las versiones de kernel

Una matriz puede incluir varias secciones <kernel>, cada una con un atributo version diferente con el formato:

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

El objeto VINTF solo considera la sección <kernel> de FCM que tiene una versión de FCM coincidente con el mismo ${ver} y ${major_rev} que el kernel del dispositivo (es decir, version="${ver}.${major_rev}.${matrix_minor_rev}"); se ignoran las demás secciones. 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 hay coincidencia.

Ejemplo: Selecciona los requisitos para la coincidencia

Considera el siguiente caso hipotético en el que 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 FCM objetivo, la versión de FCM del kernel y la versión del kernel seleccionan juntos los requisitos del kernel de los FCM:

Versión de destino de FCM	Versión de FCM del kernel	Versión de kernel	Coincide con
3 (P)	sin especificar	4.4.106	No hay coincidencias (discrepancia en la versión menor)
3 (P)	sin especificar	4.4.107	4.4-p
3 (P)	sin especificar	4.19.42	4.19-q (consulta la nota a continuación)
3 (P)	sin especificar	5.4.41	5.4-r (consulta la nota a continuación)
3 (P)	3 (P)	4.4.107	4.4-p
3 (P)	3 (P)	4.19.42	No hay coincidencias (no hay rama del kernel 4.19-p).
3 (P)	4 (Q)	4.19.42	4.19-q
4 (P)	sin especificar	4.4.107	No hay coincidencias (no hay rama del kernel 4.4-q).
4 (Q)	sin especificar	4.9.165	4.9-q
4 (Q)	sin especificar	5.4.41	5.4-r (consulta la nota a continuación)
4 (Q)	4 (Q)	4.9.165	4.9-q
4 (Q)	4 (P)	5.4.41	No hay coincidencias (no hay rama 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 (D)	sin especificar	cualquiera	El VTS falla (debe especificar la versión de FCM del kernel para la versión 5 de FCM de destino)
5 (R)	4 (Q)	cualquiera	VTS falla (versión de FCM del kernel < versión de FCM objetivo)
5 (R)	5 (R)	4.14.180	4.14-r

Cómo hacer coincidir las configuraciones del kernel

Si la sección <kernel> coincide, el proceso continúa intentando hacer coincidir los elementos config con /proc/config.gz. Para cada elemento de configuración en la matriz de compatibilidad, busca /proc/config.gz a fin de 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 <kernel> coincidente, no debe estar presente en /proc/config.gz. Por último, un elemento de configuración que no está en la matriz de compatibilidad puede estar presente en /proc/config.gz o no.

Ejemplo: Cómo 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, 0x1000 o 0X1000.
• <value type="int">0x1000</value> coincide con 4096, 0x1000 o 0X1000.
• <value type="int">0X1000</value> coincide con 4096, 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, 3 o el equivalente hexadecimal.

Ejemplo: Coincidencia correcta del kernel

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

Primero se busca una coincidencia con la rama del kernel. La rama del kernel se especifica en el manifiesto del dispositivo en manifest.kernel.target-level, que se establece de forma predeterminada en manifest.level si no se especifica la primera. Si la rama del kernel en el manifiesto del dispositivo cumple con los siguientes requisitos:

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

Luego, se compara la versión del kernel. Si un dispositivo de uname() informa lo siguiente:

• 4.9.84 (no coincide con la matriz, a menos que haya una sección de kernel independiente con <kernel version="4.9.x">, donde x <= 84)
• 4.14.41 (no coincide con la matriz, es menor que version)
• 4.14.42 (coincidencia con la matriz)
• 4.14.43 (coincidencia con la matriz)
• 4.1.22 (no hay coincidencia con la matriz, a menos que haya una sección de 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 el 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 línea nueva o #, con los espacios en blanco iniciales y finales truncados.

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

# 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 kernel es un ejemplo de una coincidencia incorrecta:

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íticas de SE

La política de SE requiere las siguientes coincidencias:

• <sepolicy-version> define un rango cerrado de versiones secundarias para cada versión principal. La versión de sepolicy que informa el dispositivo debe estar dentro de uno de estos rangos para ser compatible con el framework. Las reglas de coincidencia son similares a las versiones de HAL. Se consideran coincidencias si la versión de la política de seguridad es superior o igual a la versión mínima del rango. La versión máxima es solo informativa.
• <kernel-sepolicy-version>, es decir, la versión de policydb. Debe ser inferior al security_policyvers() que informa el dispositivo.

Ejemplo: Coincidencia exitosa de la política de SE

La matriz de compatibilidad del marco de trabajo indica 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>

Sigue estos pasos en el dispositivo:

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

Coincidencias de versiones de AVB

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

• ro.boot.vbmeta.avb_version es la versión libavb en el bootloader.
• ro.boot.avb_version es la versión libavb en el SO Android (init/fs_mgr)

La propiedad del sistema aparece solo cuando se usó la libavb correspondiente para verificar los metadatos de AVB (y muestra un mensaje de OK). No está presente si se produjo una verificación fallida (o si no se realizó 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 de trabajo
  • 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 de trabajo
  • ro.boot.avb_version.MAJOR == avb.vbmeta-version.MAJOR
  • ro.boot.avb_version.MINOR >= avb.vbmeta-version.MINOR

Es posible que el bootloader o el SO Android contengan dos copias de las bibliotecas de libavb, cada una con una versión MAJOR diferente para los dispositivos de actualización y de inicio. En este caso, se puede compartir la misma imagen del sistema sin firmar, pero las imágenes del sistema firmadas finales son diferentes (con avb.vbmeta-version diferentes):

Figura 1: La versión de AVB coincide (/system es P y todas las demás particiones son O).

Figura 2: Coincidencias de versión de AVB (todas las particiones son P).

Ejemplo: Coincidencia correcta de la versión de AVB

La matriz de compatibilidad del framework indica la siguiente información de AVB:

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

En el dispositivo, haz lo siguiente:

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 

Hacer coincidir la versión de AVB durante OTA

En el caso de los dispositivos lanzados con Android 9 o versiones anteriores, cuando se actualizan a Android 10, los requisitos de versión de AVB en la matriz de compatibilidad del framework coinciden 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 actualización OTA (por ejemplo, de 0.0 a 1.0), la verificación de VINTF de compatibilidad en OTA no refleja la compatibilidad después de la OTA.

Para mitigar el problema, un OEM puede colocar una versión falsa de AVB en el paquete OTA (compatibility.zip) para aprobar la verificación. Para ello, sigue estos pasos:

1. Selecciona los siguientes CL para el árbol de fuentes de Android 9:
   • CL 732261
   • CL 732262
2. Define BOARD_OTA_FRAMEWORK_VBMETA_VERSION_OVERRIDE para el dispositivo. Su valor debe ser igual a la versión de AVB anterior a la actualización inalámbrica, es decir, la versión de AVB del dispositivo cuando se lanzó.
3. Vuelve a compilar el paquete inalámbrico.

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 del framework, incluida /system/etc/vintf/compatibility_matrix.xml. Después de la actualización OTA, se usa el valor nuevo en /system/etc/vintf/compatibility_matrix.xml para las verificaciones de compatibilidad.

Coincidencias de versión de VNDK

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

Si la matriz de compatibilidad del dispositivo tiene una etiqueta <vendor-ndk>, se busca una entrada <vendor-ndk> con una <version> coincidente en el conjunto de instantáneas del proveedor del VNDK que proporciona el framework en el manifiesto del framework. Si no existe una entrada de este tipo, no hay coincidencias.

Si esa entrada existe, el conjunto de bibliotecas enumeradas en la matriz de compatibilidad del dispositivo debe ser un subconjunto del conjunto de bibliotecas indicado en el manifiesto del framework; de lo contrario, la entrada no se considerará 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 correcta de versión del VNDK

Si la matriz de compatibilidad del dispositivo indica 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 framework, 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, ya que la versión 27 de VNDK está en el manifiesto del framework y en {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 coincide. Aunque la versión 27 del VNDK está en el manifiesto del framework, el framework de esa instantánea no admite libjpeg.so. Se ignora la versión 26 de VNDK.

La versión del SDK del sistema coincide

La matriz de compatibilidad del dispositivo declara un conjunto de versiones requeridas del SDK del sistema en compatibility-matrix.system-sdk.version. Solo hay una coincidencia 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 framework.

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

Ejemplo: Coincidencia correcta de la versión del SDK del sistema

Si la matriz de compatibilidad del dispositivo indica el siguiente requisito en el SDK del sistema:

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

Luego, el framework 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.