Reglas de coincidencia

Los dos pares de matrices de compatibilidad y manifiestos están destinados a ser conciliados para verificar que el y la implementación de proveedores puedan trabajar en conjunto. Esta verificación se realiza correctamente cuando hay una coincidencia entre la matriz de compatibilidad del marco y la manifiesto del dispositivo, así como entre el manifiesto del framework y el del dispositivo matriz de compatibilidad.

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

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

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

Para hacer coincidir un manifiesto de dispositivo con una matriz de compatibilidad de framework, haz lo siguiente: la versión de envío de FCM que se especifica en el manifest.target-level debe ser exactamente igual a la versión de FCM que se especifica por compatibility-matrix.level De lo contrario, no hay coincidencia.

Cuando se solicita la matriz de compatibilidad del marco de trabajo con libvintf, esta coincidencia se siempre se realiza correctamente porque libvintf abre el manifiesto del dispositivo y recupera el campo de envío Versión de FCM y devuelve la matriz de compatibilidad del marco de trabajo en esa versión de FCM de envío (más algunas HALs opcionales de matrices de compatibilidad en versiones posteriores de FCM).

Coincidencias del HAL

La regla de coincidencia de HAL identifica las versiones de elementos hal en un archivo de manifiesto que se consideren admitidos por el propietario de la correspondiente matriz de compatibilidad.

HIDL y HALs nativas

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

• Varios elementos <hal> se evalúan con un solo operador AND relación.
• Los elementos <hal> pueden tener <hal optional="true"> para marcarlos como no es necesario.
• Varios elementos <version> dentro de la misma <hal> tienen el OR. Si se especifican dos o más, solo una de las versiones debe implementarse. (Consulta el ejemplo de DRM más abajo).
• Múltiples <instance> y <regex-instance> elementos dentro de la misma Los <hal> se evalúan con una sola relación AND cuando El campo <hal> es obligatorio. (Consulta el <ahref="#drm">ejemplo de DRM que aparece a continuación).</ahref="#drm">

Ejemplo: Coincidencia correcta de HAL 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 a 2.∞. En la matriz de compatibilidad, 2.5 es la abreviatura de 2.5-5
2.5-7	2.5 a 2.∞. Indica lo siguiente: 2.5 es la versión mínima requerida, es decir, un manifiesto que proporciona la HAL Las versiones 2.0-2.4 no son compatibles. 2.7 es la versión máxima que se puede solicitar, es decir, el propietario de la matriz de compatibilidad (framework o dispositivo) no solicitará versiones más allá de 2.7. El propietario del manifiesto coincidente aún puede publicar la versión 2.10. por ejemplo, cuando se solicita 2.7. El propietario de la matriz de compatibilidad sabe solo que el servicio solicitado sea compatible con la versión de API 2.7. -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 permanece compatibles con un framework que establezca 2.5-7 en su matriz de compatibilidad.

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

La matriz de compatibilidad del marco de trabajo indica la siguiente información de la versión Para la 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>

Un proveedor debe implementar UNA de las siguientes instancias: cualquiera de los dos

android.hardware.drm@1.x::IDrmFactory/default          // where x >= 0
android.hardware.drm@1.x::IDrmFactory/specific         // where x >= 0

O BIEN

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) admite versiones para HALs de AIDL en VINTF. Las reglas de coincidencia de las HAL del AIDL son similares a las de las HALs nativas y de HIDL. no hay versiones principales y hay exactamente una versión por instancia de HAL (1 si versión no especificada).

• Varios elementos <hal> se evalúan con un solo operador AND relación.
• Los elementos <hal> pueden tener <hal optional="true"> para marcarlos como no es necesario.
• Múltiples <instance> y <regex-instance> elementos dentro de la misma Los <hal> se evalúan con una sola relación AND cuando El campo <hal> es obligatorio. (Consulta el ejemplo de <ahref="#vibrator">vibrador a continuación).</ahref="#vibrator">

Ejemplo: Coincidencia correcta de HAL para un módulo

En el caso de 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, es decir, el propietario de la matriz de compatibilidad (framework o dispositivo) no solicitará versiones más de 7. El propietario del manifiesto coincidente aún puede publicar la versión 10. (por ejemplo), cuando se solicita 7. El propietario de la matriz de compatibilidad sabe solo que el servicio solicitado sea 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 permanece compatibles con un framework que establezca 5-7 en su matriz de compatibilidad.

Ejemplo: coincidencia correcta de HAL para varios módulos

La matriz de compatibilidad del marco de trabajo indica la siguiente información de la versión Para las HAL del vibrador y la 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 kernel

Sección <kernel> de la matriz de compatibilidad del framework describe los requisitos del framework del kernel de Linux en el dispositivo. Esta la información debe compararse con información acerca del kernel que informa el objeto VINTF del dispositivo.

Cómo hacer coincidir las ramas de kernel

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

Las pruebas de VTS determinan 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 el dispositivo mencionado anteriormente tiene una versión 4 de FCM de destino y la versión de FCM de su kernel es 5 (kernel sufijo de rama r).
• La versión de FCM del kernel es superior o igual a 5 (sufijo de rama de kernel r).

Nota: Si la versión de FCM del kernel es igual a la versión de FCM de destino y son superiores o iguales a 5, el archivo fuente del manifiesto del dispositivo especificado por DEVICE_MANIFEST_FILE no tendrá para especificar la versión de FCM del kernel. assemble_vintf infiere automáticamente la versión de FCM del kernel de la versión de FCM de destino si esta es superior o igual a 5)

Las pruebas de VTS establecen que, si se especifica la versión de FCM del kernel, se cumple superior o igual a la versión de destino de FCM que figura en el manifiesto del dispositivo

Ejemplo: Determina la rama de kernel

Si el dispositivo tiene como destino la versión 4 de FCM (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 verifica la compatibilidad del kernel con los requisitos del kernel 4.19-r. que se especifica en la versión 5 de FCM. Estos requisitos se basan en kernel/configs/r/android-4.19 en el árbol de fuentes de Android.

Ejemplo: Determina la rama de kernel para GKI

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

Para obtener detalles sobre cómo se analiza la cadena de actualización del kernel, consulta la siguiente información: Control de versiones de GKI

Cómo hacer coincidir versiones de kernel

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

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

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

Ejemplo: Selecciona los requisitos para las coincidencias

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

Versión de destino de FCM	Versión de FCM de kernel	Versión de kernel	Coincide con
3 (P)	sin especificar	4.4.106	Sin coincidencia (la versión secundaria no coincide)
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	Sin coincidencia (sin rama de kernel 4.19-p)
3 (P)	4 (P)	4.19.42	4.19-q
4 (P)	sin especificar	4.4.107	Sin coincidencia (sin rama de kernel 4.4-q)
4 (P)	sin especificar	4.9.165	4.9-q
4 (P)	sin especificar	5.4.41	5.4-r (consulta la nota a continuación)
4 (P)	4 (P)	4.9.165	4.9-q
4 (P)	4 (P)	5.4.41	Sin coincidencia (sin rama de kernel 5.4-q)
4 (P)	5 (D)	4.14.105	4.14-r
4 (P)	5 (D)	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 (D)	4 (P)	cualquiera	Falla de VTS (versión de FCM del kernel < 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, la El objeto VINTF selecciona la rama de kernel con el sufijo más bajo que sea mayor que el FCM de destino. con la versión de kernel coincidente. En el ejemplo anterior, un dispositivo con una versión de FCM de destino de 3 (P) usa la rama de kernel 4.19-q porque 4.19-q tiene el sufijo más bajo entre todas las 4.19-* ramas de kernel, [4.19-q, 4.19-r, 4.19-s]. Esta el comportamiento de selección de requisitos no está permitido para dispositivos cuya versión de FCM de destino es 5 (R). porque la versión de FCM del kernel debe ser especificada.

Cómo hacer coincidir la configuración del kernel

Si la sección <kernel> coincide, el proceso continúa. haciendo coincidir los elementos config con /proc/config.gz Para cada elemento de configuración en la lista matrix, busca /proc/config.gz para ver si la configuración está presente. Cuando un elemento de configuración se establece en n en la configuración matriz para la sección <kernel> coincidente, debe estar ausente desde /proc/config.gz. Por último, un elemento de configuración que no está en puede o no estar presente en /proc/config.gz.

Ejemplo: Cómo hacer coincidir configuraciones de kernel

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

Ejemplo: Coincidencia correcta de kernel

Una matriz de compatibilidad del marco de trabajo 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 establece la coincidencia con la rama de kernel. La rama de kernel se especifica en el manifiesto del dispositivo. En manifest.kernel.target-level, el valor predeterminado es manifest.level. si el primero no se especifica. Si la rama de kernel en el manifiesto del dispositivo:

• es 1, avanza al 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 En su lugar, FCM 2.

Luego, se establece la coincidencia con la versión de kernel. Si un dispositivo de uname() informes:

• 4.9.84 (sin coincidencia 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, menor que version)
• 4.14.42 (coincidencia con la matriz)
• 4.14.43 (coincidencia con la matriz)
• 4.1.22 (sin coincidencia con la matriz, a menos que haya una sección de kernel separada) con <kernel version="4.1.x">, en el que x <= 22)

Después de seleccionar la sección <kernel> adecuada, por cada elemento <config> con un valor distinto de n, esperar que la entrada correspondiente esté presente en /proc/config.gz para cada elemento <config> con el valor n, esperamos la entrada correspondiente no debe estar presente en /proc/config.gz. Mié Se espera que el contenido de <value> coincida exactamente con el texto después de el signo igual (incluidas las comillas), hasta el carácter de línea nueva o #, con espacios en blanco al inicio y al final 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 la política de SE

La política de SE requiere las siguientes coincidencias:

• <sepolicy-version> define un rango cerrado de valores secundarios para cada versión principal. La versión de la política que informa el dispositivo debe estar dentro de uno de estos rangos para ser compatible con el framework. Coincidencia son similares a las versiones de HAL; es una coincidencia si la versión de la política superior o igual a la versión mínima del rango. La versión máxima es meramente informativo.
• <kernel-sepolicy-version>: Es decir, la versión de policydb. Indispensable ser inferior al security_policyvers() informado por el dispositivo.

Ejemplo: Coincidencia correcta 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 muestra security_policyvers() debe ser mayor igual o superior a 30. De lo contrario, no hay 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 de SE debe ser 25.0-∞ o 26.0-∞. De lo contrario, no es un la coincidencia. (El término "-3" que aparece después de "26.0" es puramente informativo).

Coincidencias de la versión de AVB

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

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

La propiedad del sistema aparece solo cuando se usa la libavb correspondiente. para verificar los metadatos del AVB (y devuelve OK). Falta si se produce un error en la verificación (o 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 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 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

El bootloader o el SO Android pueden contener dos copias de libavb cada una con una versión MAJOR diferente para los dispositivos actualizados y lanzar dispositivos. En este caso, se puede compartir la misma imagen de sistema sin firmar, pero las imágenes finales del sistema firmado son diferentes (con diferentes avb.vbmeta-version):

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

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

Ejemplo: Coincidencia correcta de la versión de AVB

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

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

Sigue estos pasos 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 

Hacer coincidir la versión de AVB durante OTA

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

Para los dispositivos que se lanzaron con Android 9 o versiones anteriores, cuando se actualice a Android 10 (AVB) los requisitos de versión de la matriz de compatibilidad del framework se comparan con el AVB actual versión en el dispositivo. Si la versión de AVB tiene una actualización de versión principal durante una actualización inalámbrica (por ejemplo, de 0.0 a 1.0), la verificación de compatibilidad de VINTF en OTA no refleja la compatibilidad después a la OTA.

Para mitigar el problema, un OEM puede colocar una versión de AVB falsa en el paquete inalámbrico (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 debería ser igual a la versión de AVB antes de la actualización inalámbrica, es decir, la versión de AVB del dispositivo cuando se lanzamiento.
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 inalámbrico

Estos cambios no afectan a otras matrices de compatibilidad del framework, incluida /system/etc/vintf/compatibility_matrix.xml Después de la actualización inalámbrica, el nuevo valor en En su lugar, se usa /system/etc/vintf/compatibility_matrix.xml para las verificaciones de compatibilidad.

Coincidencias de la versión del VNDK

La matriz de compatibilidad de dispositivos declara la versión requerida del VNDK en compatibility-matrix.vendor-ndk.version Si el dispositivo la matriz de compatibilidad 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 un elemento <vendor-ndk> etiqueta, una entrada <vendor-ndk> con una coincidencia <version> se busca a partir del conjunto de resúmenes de proveedores del VNDK que proporciona el framework en el manifiesto del framework. Si una entrada de este tipo no existen, no hay coincidencias.

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

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

Ejemplo: Coincidencia correcta de la versión del VNDK

Si la matriz de compatibilidad de dispositivos indica el siguiente requisito en el 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 porque la versión 27 del VNDK está en el manifiesto del framework. 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. Aunque la versión 27 del VNDK ya está disponible en el marco manifiesto, libjpeg.so no es compatible con el framework en ese 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 SDK de sistema obligatorios. en la versión compatibility-matrix.system-sdk.version. Hay un coincidir solo si el conjunto es un subconjunto de las versiones del SDK del sistema proporcionadas, según lo declarado en manifest.system-sdk.version en el manifiesto del framework.

• Como caso especial, si no se enumeran versiones del SDK del sistema en el dispositivo de compatibilidad, siempre se considera una coincidencia, porque está vacía conjunto 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 sistema SDK:

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