Normas 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 tiempo de compilación, en el tiempo de generación del paquete de actualización inalámbrica, en el tiempo de 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 versiones de la matriz de compatibilidad del 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 HIDL y HAL nativos son las siguientes.

• Varios elementos <hal> se evalúan con una sola relación Y.
• Los elementos <hal> pueden tener <hal optional="true"> para marcarlos como no obligatorios. Advertencia: Este optional ya no es compatible después de Android 15.
• 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:

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

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

• Varios elementos <hal> se evalúan con una sola relación Y.
• Los elementos <hal> pueden tener <hal optional="true"> para marcarlos como no obligatorios. Advertencia: Este optional ya no es compatible después de Android 15.
• 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="#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:

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.

Coincide con 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 las letras de las versiones (por ejemplo, R) y las 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 alguna 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 mencionado anteriormente 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 del 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 más información 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 siguiente formato:

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

El objeto VINTF solo considera la sección <kernel> de FCM con la 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:

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 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 <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 o no presente en /proc/config.gz.

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 coincide 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 en 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 coincide con la matriz, a menos que haya una sección de kernel independiente 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 no exitosa:

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. Hay una coincidencia si la versión de sepolicy 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 framework indica la siguiente información de sepolicy:

<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, haz lo siguiente:

• 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 muestra 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" después de "26.0" es solo informativo).

Coincidencias de versiones de AVB

La versión de AVB contiene una versión MAJOR y una MINOR, con el formato MAJOR.MINOR (p.ej., 1.0, 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 un error de verificación (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 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 framework
  • 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 los dispositivos de lanzamiento. 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, 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 

Coincidencia de la versión de AVB durante la actualización 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 OTA, 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 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 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 de dispositivos 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 de VNDK que proporciona el framework en el manifiesto del framework. Si no existe una entrada de este tipo, no hay coincidencias.

Si existe una entrada de este tipo, el conjunto de bibliotecas enumeradas en la matriz de compatibilidad del dispositivo debe ser un subconjunto del conjunto de bibliotecas que se indica en el manifiesto del framework. De lo contrario, la entrada no se considera una coincidencia.

• Como caso especial, si no se enumeran bibliotecas en la matriz de compatibilidad del dispositivo, la entrada siempre se considera una coincidencia, ya que 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 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 es una coincidencia. Aunque la versión 27 de VNDK está en el manifiesto del framework, el framework no admite libjpeg.so en esa instantánea. 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, ya que 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, ya que no se proporciona la versión 27 del SDK del sistema.