Google se compromete a impulsar la igualdad racial para las comunidades afrodescendientes. Obtén información al respecto.

Reglas coincidentes

Los dos pares de matrices de compatibilidad y manifiestos deben conciliarse para verificar que el marco y la implementación del proveedor pueden funcionar entre sí. Esta verificación se realiza correctamente al hacer coincidir la matriz de compatibilidad del marco y el manifiesto del dispositivo, así como entre el manifiesto del marco y la matriz de compatibilidad del dispositivo.

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

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 que coincida con un manifiesto dispositivo con una matriz de compatibilidad marco, la versión de envío FCM especificado por manifest.target-level debe ser exactamente igual a la versión especificada por FCM compatibility-matrix.level . De lo contrario, no hay coincidencia.

Cuando se solicita la matriz de compatibilidad marco con libvintf , este partido siempre tiene éxito porque libvintf abre el manifiesto del dispositivo, recupera la FCM versión de envío, y devuelve la matriz de compatibilidad marco en ese envío Versión FCM (además de algunos HAL opcionales a partir de matrices de compatibilidad en mayor FCM Versiones).

Partidos de HAL

Los identifica regla HAL-fósforo de las versiones de hal elementos en un archivo de manifiesto que se consideran ser apoyadas por el propietario de la matriz de compatibilidad correspondiente.

HIDL y HAL nativos

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

  • Múltiples <hal> elementos se evalúan con una sola y la relación.
  • Múltiples <version> elementos dentro del mismo <hal> tienen la o relación. Si se especifican dos o más, solo es necesario implementar una de las versiones. (Véase el ejemplo de DRM a continuación.)
  • Multiple <instance> y <regex-instance> elementos dentro del mismo <hal> se evalúan con una sola y la relación. (Véase el ejemplo de DRM a continuación.)

Ejemplo: coincidencia de HAL satisfactoria 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 (marco o dispositivo) no solicitará versiones posteriores a la 2.7. El propietario del manifiesto coincidente aún puede ofrecer 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 API.
  • -7 es solo informativo y no afecta el proceso de actualización de OTA.
Por lo tanto, un dispositivo con un HAL en la versión 2.10 en su archivo de manifiesto sigue siendo compatible con un marco que los estados 2.5-7 en su matriz de compatibilidad.

Ejemplo: coincidencia exitosa de HAL 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; cualquiera

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

AIDL HAL

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

  • Múltiples <hal> elementos se evalúan con una sola y la relación.
  • Multiple <instance> y <regex-instance> elementos dentro del mismo <hal> se evalúan con una sola y la relación. (Véase el ejemplo vibrador a continuación).

Ejemplo: coincidencia de HAL correcta 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 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 posteriores a 7. El propietario del manifiesto coincidente aún puede ofrecer la versión 10 (como ejemplo) cuando se solicita 7 . El propietario de la matriz de compatibilidad solo sabe que el servicio solicitado es compatible con la versión 7 de API.
  • -7 es solo informativo y no afecta el proceso de actualización de OTA.
Por lo tanto, un dispositivo con un HAL en la versión 10 en su archivo de manifiesto sigue siendo compatible con un marco que los estados 5-7 en su matriz de compatibilidad.

Ejemplo: coincidencia de HAL satisfactoria para varios módulos

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

<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

Partidos de kernel

La <kernel> sección de la matriz de compatibilidad marco describe los requisitos del marco del kernel de Linux en el dispositivo. Esta información está destinada a ser comparada con la información sobre el kernel de eso se difundió por objeto VINTF del dispositivo.

Coincidir con las ramas del kernel

Cada sufijo rama del núcleo (por ejemplo, 5.4- r ) se asigna a una versión única kernel FCM (por ejemplo, 5). El mapeo es el mismo que el mapeo entre las letras de lanzamiento (por ejemplo, R) y las versiones de FCM (por ejemplo, 5).

Pruebas VTS hacer cumplir que el dispositivo se especifique explícitamente la versión del núcleo FCM en el manifiesto del dispositivo, /vendor/etc/vintf/manifest.xml , si una de las siguientes situaciones:

  • 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 FCM objetivo 4, y su versión del núcleo FCM es 5 (kernel rama sufijo r ).
  • La versión del núcleo FCM es mayor que o igual a 5 (kernel rama sufijo r ).

Las pruebas de VTS exigen 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 FCM objetivo de la versión 4 (lanzado en Android 10), pero se ejecuta núcleo desde el 4.19-r rama, el manifiesto dispositivo debe especificar lo siguiente:

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

Compatibilidad de los controles objeto VINTF kernel sobre requisitos de 4.19-r rama del kernel, que se especifica en la versión FCM 5. Estos requisitos se construye a partir de kernel/configs/r/android-4.19 en el árbol de código fuente de Android.

Coincidir con las versiones del kernel

Una matriz puede incluir múltiples <kernel> tramos, cada uno con una diferente version atributo utilizando el formato:

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

El objeto VINTF considera sólo el <kernel> sección de la FCM combina con el modelo FCM con el mismo ${ver} y ${major_rev} como el núcleo del dispositivo (es decir, version="${ver}.${major_rev}.${matrix_minor_rev}") ; otras secciones se ignoran. Además, la revisión menor del núcleo debe ser un valor de la matriz de compatibilidad ( ${kernel_minor_rev} >= ${matrix_minor_rev} ;). Si hay <kernel> sección cumple con estos requisitos, es un no-partido.

Ejemplo: seleccione los requisitos para la coincidencia

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

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

Versión de FCM de destino Versión de Kernel FCM Versión del núcleo Juntar con
3 (P) sin especificar 4.4.106 Sin coincidencia (discrepancia en la versión secundaria)
3 (P) sin especificar 4.4.107 4.4-p
3 (P) sin especificar 4.19.42 4.19-q (véase la nota a continuación)
3 (P) sin especificar 5.4.41 5.4-r (véase la nota a continuación)
3 (P) 3 (P) 4.4.107 4.4-p
3 (P) 3 (P) 4.19.42 Ningún resultado (sin 4.19-p rama del kernel)
3 (P) 4 (Q) 4.19.42 4.19-q
4 (Q) sin especificar 4.4.107 Ningún resultado (sin 4.4-q rama del kernel)
4 (Q) sin especificar 4.9.165 4.9-q
4 (Q) sin especificar 5.4.41 5.4-r (véase la nota a continuación)
4 (Q) 4 (Q) 4.9.165 4.9-q
4 (Q) 4 (Q) 5.4.41 Ningún resultado (sin 5.4-q rama del kernel)
4 (Q) 5 (R) 4.14.105 4.14-r
4 (Q) 5 (R) 5.4.41 5.4-r
5 (R) sin especificar alguna VTS falla (debe especificar la versión de FCM del kernel para la versión 5 de FCM de destino)
5 (R) 4 (Q) alguna VTS falla (versión de FCM del kernel <versión de FCM de destino)
5 (R) 5 (R) 4.14.180 4.14-r

Coincidir con las configuraciones del kernel

Si el <kernel> sección coincide, el proceso continúa tratando de igualar config elementos contra /proc/config.gz . Para cada elemento de configuración en la matriz de compatibilidad, que mira hacia arriba /proc/config.gz para ver si el config está presente. Cuando un elemento de config se establece en n en la matriz de compatibilidad para el juego <kernel> sección, debe estar ausente de /proc/config.gz . Por último, un elemento de configuración no en la matriz de compatibilidad puede o no puede estar presente en /proc/config.gz .

Ejemplo: hacer coincidir configuraciones de kernel

  • <value type="string">bar</value> partidos "bar" . Cotizaciones se omiten en la matriz de compatibilidad, pero presente en /proc/config.gz .
  • <value type="int">4096</value> partidos 4096 o 0x1000 o 0X1000 .
  • <value type="int">0x1000</value> partidos 4096 o 0x1000 o 0X1000 .
  • <value type="int">0X1000</value> partidos 4096 o 0x1000 o 0X1000 .
  • <value type="tristate">y</value> partidos y .
  • <value type="tristate">m</value> partidos m .
  • <value type="tristate">n</value> significa que el elemento de configuración no deben existir en /proc/config.gz .
  • <value type="range">1-0x3</value> partidos 1 , 2 , o 3 , o hexadecimal equivalente.

Ejemplo: coincidencia exitosa del kernel

Una matriz de compatibilidad del marco 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 kernel 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 el primero no se especifica. Si la rama del kernel en el manifiesto del dispositivo:

  • es 1, pasa al siguiente paso y comprueba la versión del kernel.
  • es 2, no coincide con la matriz. En su lugar, los objetos VINTF leen los requisitos del kernel de la matriz en la versión 2 de FCM.

Entonces, la versión del kernel coincide. Si un dispositivo de uname() informes:

  • 4.9.84 (sin partido a la matriz a menos que haya una sección de núcleo separado con <kernel version="4.9.x"> , donde x <= 84 )
  • 04/14/41 (sin partido a la matriz, más pequeño que version )
  • 4.14.42 (coincidir con la matriz)
  • 4.14.43 (coincidir con la matriz)
  • 4.1.22 (sin partido a la matriz a menos que haya una sección de núcleo separado con <kernel version="4.1.x"> donde x <= 22 )

Después de la apropiada <kernel> se selecciona sección, para cada <config> artículo con valor distinto de n , esperamos que la entrada correspondiente esté presente en /proc/config.gz ; para cada <config> elemento con valor de n , se espera que la entrada que corresponde a no estar presente en /proc/config.gz . Esperamos que el contenido de <value> para que coincida exactamente con el texto después del signo igual (incluyendo las comillas), hasta el carácter de nueva línea o # , con el espacio inicial y final truncado.

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 kernel 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 menores para cada versión principal. La versión de sepolicy 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 sepolicy es superior o igual a la versión mínima para el rango. La versión máxima es meramente informativa.
  • <kernel-sepolicy-version> es decir policydb versión. Debe ser inferior a los security_policyvers() reportados por el dispositivo.

Ejemplo: coincidencia satisfactoria de la política de SE

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 que o igual a 30. De lo contrario, no es un partido. Por ejemplo:
    • Si un dispositivo devuelve 29, no coincide.
    • 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 MAJOR.MINOR (por ejemplo, 1.0, 2.1). Para más detalles, consulte Control de versiones y compatibilidad . La versión AVB tiene las siguientes propiedades del sistema:

  • ro.boot.vbmeta.avb_version es la libavb versión del gestor de arranque
  • ro.boot.avb_version es la libavb versión de Android OS ( init/fs_mgr )

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

Una coincidencia de compatibilidad compara lo siguiente:

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

El gestor de arranque o el sistema operativo Android podrían contener dos copias de libavb bibliotecas, cada una con una versión mayor para los dispositivos de actualización y los dispositivos de lanzamiento. En este caso, la misma imagen del sistema sin signo puede ser compartido, pero las imágenes del sistema firmados finales son diferentes (con diferentes avb.vbmeta-version ):

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


Partidos Figura versión 2. AVB (todas las particiones son P).

Ejemplo: coincidencia correcta de la versión de AVB

La matriz de compatibilidad del marco establece la siguiente información 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

Para dispositivos lanzados con Android 9 o versiones anteriores, al actualizar a Android 10, los requisitos de la versión AVB en la matriz de compatibilidad del marco se comparan con la versión AVB actual en el dispositivo. Si la versión AVB tiene una actualización de versión importante durante una OTA (por ejemplo, de 0.0 a 1.0), la verificació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 falsa AVB en el paquete OTA ( compatibility.zip ) para pasar el cheque. Para hacerlo:

  1. Elija los siguientes CL en el árbol de fuentes de Android 9:
  2. Definir 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 ponen 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 utiliza en Android 9) en el dispositivo
  • system_matrix.xml en compatibility.zip en el paquete OTA

Estos cambios no afectan a otras matrices de compatibilidad marco, incluyendo /system/etc/vintf/compatibility_matrix.xml . Después de la OTA, el nuevo valor en /system/etc/vintf/compatibility_matrix.xml se utiliza para comprobaciones de compatibilidad en vez.

Coincidencias de la versión VNDK

La matriz de compatibilidad dispositivo declara la versión VNDK requerida en compatibility-matrix.vendor-ndk.version . Si la matriz de compatibilidad dispositivo no tiene un <vendor-ndk> tag, no se imponen requisitos, y por lo tanto siempre es considerado un partido.

Si la matriz de compatibilidad dispositivo hace A tienen <vendor-ndk> tag, un <vendor-ndk> entrada con un juego <version> se levantó la vista del conjunto de instantáneas de proveedores VNDK que se proporciona por el marco en el manifiesto 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 indicado 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 correcta de la versión de VNDK

Si la matriz de compatibilidad del dispositivo 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>

Ejemplo A es un partido, porque VNDK versión 27 está en el manifiesto de 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 coincide. A pesar de que VNDK versión 27 está en el manifiesto marco, libjpeg.so no es compatible con el marco en el que la instantánea. Se ignora la versión 26 de VNDK.

Coincidencias de la versión del SDK del sistema

La matriz de compatibilidad dispositivo declara un conjunto de requerido versión SDK del sistema en compatibility-matrix.system-sdk.version . Hay un partido sólo si el conjunto es un subconjunto de versiones de SDK Sistema proporcionados declaradas en manifest.system-sdk.version en el manifiesto marco.

  • Como caso especial, si no se enumeran versiones de System SDK 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 correcta de la versión del SDK del sistema

Si la matriz de compatibilidad del dispositivo establece el siguiente requisito en System SDK:

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