Los dos pares de matrices de compatibilidad y manifiestos deben reconciliarse para verificar que el marco y la implementación del proveedor puedan funcionar entre sí. Esta verificación se realiza correctamente cuando la matriz de compatibilidad del marco coincide con el manifiesto del dispositivo, así como entre el manifiesto del marco y la matriz de compatibilidad del dispositivo.
Esta verificación se realiza en el momento de la compilación, en el momento de la generación del paquete de actualización OTA , en el momento del arranque y en las pruebas de compatibilidad de VTS.
Las siguientes secciones detallan las reglas de coincidencia utilizadas por varios componentes.
Coincidencias de la versión de la matriz de compatibilidad del marco
Para hacer coincidir un manifiesto de dispositivo con una matriz de compatibilidad de marco, la versión de FCM de envío especificada por manifest.target-level
debe ser exactamente igual a la versión de FCM especificada por compatibility-matrix.level
. De lo contrario no hay coincidencia.
Cuando se solicita la matriz de compatibilidad del marco con libvintf
, esta coincidencia siempre tiene éxito porque libvintf
abre el manifiesto del dispositivo, recupera la versión de FCM de envío y devuelve la matriz de compatibilidad del marco en esa versión de FCM de envío (más algunas HAL opcionales de las matrices de compatibilidad en FCM más alto). Versiones).
coincidencias HAL
La regla de coincidencia HAL identifica las versiones de los elementos hal
en un archivo de manifiesto que se considera compatible con el propietario de la matriz de compatibilidad correspondiente.
HIDL y HAL nativos
Las reglas de coincidencia para HIDL y HAL nativas son las siguientes.
- Varios elementos
<hal>
se evalúan con una sola relación AND . - Los elementos
<hal>
pueden tener<hal optional="true">
para marcarlos como no necesarios. - Múltiples elementos
<version>
dentro del mismo<hal>
tienen la relación OR . Si se especifican dos o más, solo se necesita implementar una de las versiones. (Consulte el ejemplo de DRM a continuación). - Varios elementos
<instance>
y<regex-instance>
dentro del mismo<hal>
se evalúan con una sola relación AND cuando se requiere<hal>
. (Ver elEjemplo de DRM a continuación.)
Ejemplo: Coincidencia HAL exitosa para un módulo
Para una HAL en la versión 2.5, la regla de coincidencia es la siguiente:
Matriz | Manifiesto coincidente |
---|---|
2.5 | 2.5-2.∞. En la matriz de compatibilidad, 2.5 es la abreviatura de 2.5-5 . |
2.5-7 | 2.5-2.∞. Indica lo siguiente:
2.5-7 en su matriz de compatibilidad. |
Ejemplo: Coincidencia HAL exitosa para el módulo DRM
La matriz de compatibilidad del marco establece la siguiente información de versión para DRM HAL:
<hal> <name>android.hardware.drm <version>1.0</version> <version>3.1-2</version> <interface> <name>IDrmFactory</name> <instance>default</instance> <instance>specific</instance> </interface> </hal> <hal> <name>android.hardware.drm <version>2.0</version> <interface> <name>ICryptoFactory</name> <instance>default</instance> <regex-instance>[a-z]+/[0-9]+</regex-instance> </interface> </hal>
Un proveedor debe implementar UNA de las siguientes instancias; o
android.hardware.drm@1.x::IDrmFactory/default // where x >= 0 android.hardware.drm@1.x::IDrmFactory/specific // where x >= 0O
android.hardware.drm@3.y::IDrmFactory/default // where y >= 1 android.hardware.drm@3.y::IDrmFactory/specific // where y >= 1
Y también debe implementar todas estas instancias:
android.hardware.drm@2.z::ICryptoFactory/default // where z >= 0 android.hardware.drm@2.z::ICryptoFactory/${INSTANCE} // where z >= 0 and ${INSTANCE} matches [a-z]+/[0-9]+ // e.g. legacy/0
HAL AIDL
Todas las versiones de Android posteriores a Android 11 (excepto Android 11) admiten versiones para AIDL HAL en VINTF. Las reglas de coincidencia para las HAL de AIDL son similares a las de HIDL y las HAL nativas, excepto que no hay versiones principales y hay exactamente una versión por instancia de HAL ( 1
si no se especifica la versión).
- Varios elementos
<hal>
se evalúan con una sola relación AND . - Los elementos
<hal>
pueden tener<hal optional="true">
para marcarlos como no necesarios. - Varios elementos
<instance>
y<regex-instance>
dentro del mismo<hal>
se evalúan con una sola relación AND cuando se requiere<hal>
. (Ver elejemplo de vibrador a continuación.)
Ejemplo: Coincidencia HAL exitosa para un módulo
Para una HAL en la versión 5, la regla de coincidencia es la siguiente:
Matriz | Manifiesto coincidente |
---|---|
5 | 5-∞. En la matriz de compatibilidad, 5 es la abreviatura de 5-5 . |
5-7 | 5-∞. Indica lo siguiente:
5-7 en su matriz de compatibilidad. |
Ejemplo: Coincidencia HAL exitosa para múltiples módulos
La matriz de compatibilidad del marco establece la siguiente información de versión para HAL de vibrador y cámara:
<hal> <name>android.hardware.vibrator <version>1-2</version> <interface> <name>IVibrator</name> <instance>default</instance> <instance>specific</instance> </interface> </hal> <hal> <name>android.hardware.camera <version>5</version> <interface> <name>ICamera</name> <instance>default</instance> <regex-instance>[a-z]+/[0-9]+</regex-instance> </interface> </hal>
Un proveedor debe implementar todas estas instancias:
android.hardware.vibrator.IVibrator/default // version >= 1 android.hardware.vibrator.IVibrator/specific // version >= 1 android.hardware.camera.ICamera/default // version >= 5 android.hardware.camera.ICamera/${INSTANCE} // with version >= 5, where ${INSTANCE} matches [a-z]+/[0-9]+ // e.g. legacy/0
Coincidencias del núcleo
La sección <kernel>
de la matriz de compatibilidad del marco describe los requisitos del marco del kernel de Linux en el dispositivo. Esta información está destinada a compararse con la información sobre el kernel que informa el objeto VINTF del dispositivo.
Hacer coincidir las ramas del kernel
Cada sufijo de rama del kernel (por ejemplo, 5.4- r
) se asigna a una versión única de FCM del kernel (por ejemplo, 5). La asignación es la misma que la asignación entre letras de versión (por ejemplo, R) y versiones de FCM (por ejemplo, 5).
Las pruebas de VTS exigen que el dispositivo especifique explícitamente la versión de FCM del kernel en el manifiesto del dispositivo, /vendor/etc/vintf/manifest.xml
, si se cumple una de las siguientes condiciones:
- La versión de kernel de FCM es diferente de la versión de destino de FCM. Por ejemplo, el dispositivo antes mencionado tiene una versión de FCM de destino 4, y su versión de FCM de kernel es 5 (sufijo de rama de kernel
r
). - La versión de FCM del núcleo es mayor o igual a 5 (sufijo de rama del núcleo
r
).
Las pruebas de VTS imponen que, si se especifica la versión de FCM del kernel, la versión de FCM del kernel es mayor o igual que la versión de FCM de destino en el manifiesto del dispositivo.
Ejemplo: determinar la rama del kernel
Si el dispositivo tiene la versión 4 de FCM de destino (lanzada en Android 10), pero ejecuta el kernel desde la rama 4.19-r
, el manifiesto del dispositivo debe especificar lo siguiente:
<manifest version="2.0" type="device" target-level="4"> <kernel target-level="5" /> </manifest>
El objeto VINTF comprueba la compatibilidad del kernel con los requisitos de la rama del kernel 4.19-r
, que se especifica en la versión 5 de FCM. Estos requisitos se crean a partir de kernel/configs/r/android-4.19
en el árbol de fuentes de Android.
Ejemplo: determinar la rama del kernel para GKI
Si el dispositivo utiliza la imagen genérica del kernel (GKI) y la cadena de versión del kernel de /proc/version
es la siguiente:
5.4.42-android12-0-00544-ged21d463f856
Luego, el objeto VINTF obtiene la versión de Android de la versión del kernel y la usa para determinar la versión de FCM del kernel. En este ejemplo, android12
significa kernel FCM versión 6 (lanzado en Android 12).
Para obtener detalles sobre cómo se analiza la cadena de versión del kernel, consulte Control de versiones de GKI .
Hacer coincidir las versiones del kernel
Una matriz puede incluir múltiples secciones <kernel>
, cada una con un atributo de version
diferente usando el formato:
${ver}.${major_rev}.${kernel_minor_rev}
El objeto VINTF considera solo la sección <kernel>
del FCM con la versión FCM coincidente con el mismo ${ver}
y ${major_rev}
que el kernel del dispositivo (es decir, version="${ver}.${major_rev}.${matrix_minor_rev}")
; otras secciones son ignoradas. Además, la revisión menor del kernel debe ser un valor de la matriz de compatibilidad ( ${kernel_minor_rev} >= ${matrix_minor_rev}
;). Si ninguna sección <kernel>
cumple con estos requisitos, no coincide.
Ejemplo: Seleccione los requisitos para la coincidencia
Considere el siguiente caso hipotético donde los FCM en /system/etc/vintf
declaran los siguientes requisitos (se omiten las etiquetas de encabezado y pie de página):
<!-- compatibility_matrix.3.xml --> <kernel version="4.4.107" level="3"/> <!-- See kernel/configs/p/android-4.4/ for 4.4-p requirements --> <kernel version="4.9.84" level="3"/> <!-- See kernel/configs/p/android-4.9/ for 4.9-p requirements --> <kernel version="4.14.42" level="3"/> <!-- See kernel/configs/p/android-4.14/ for 4.14-p requirements --> <!-- compatibility_matrix.4.xml --> <kernel version="4.9.165" level="4"/> <!-- See kernel/configs/q/android-4.9/ for 4.9-q requirements --> <kernel version="4.14.105" level="4"/> <!-- See kernel/configs/q/android-4.14/ for 4.14-q requirements --> <kernel version="4.19.42" level="4"/> <!-- See kernel/configs/q/android-4.19/ for 4.19-q requirements --> <!-- compatibility_matrix.5.xml --> <kernel version="4.14.180" level="5"/> <!-- See kernel/configs/r/android-4.14/ for 4.14-r requirements --> <kernel version="4.19.123" level="5"/> <!-- See kernel/configs/r/android-4.19/ for 4.19-r requirements --> <kernel version="5.4.41" level="5"/> <!-- See kernel/configs/r/android-5.4/ for 5.4-r requirements -->
La versión de destino de FCM, la versión de kernel de FCM y la versión de kernel juntas seleccionan los requisitos del kernel de los FCM:
Versión de destino de FCM | Versión de núcleo FCM | Versión del núcleo | Juntar con |
---|---|---|---|
3 (P) | no especificado | 4.4.106 | Sin coincidencia (discrepancia de versión secundaria) |
3 (P) | no especificado | 4.4.107 | 4.4-p |
3 (P) | no especificado | 4.19.42 | 4.19-q (ver nota a continuación) |
3 (P) | no especificado | 5.4.41 | 5.4-r (ver nota a continuación) |
3 (P) | 3 (P) | 4.4.107 | 4.4-p |
3 (P) | 3 (P) | 4.19.42 | Sin coincidencia (sin rama del kernel 4.19-p ) |
3 (P) | 4 (Q) | 4.19.42 | 4.19-q |
4 (Q) | no especificado | 4.4.107 | Sin coincidencia (sin rama del kernel 4.4-q ) |
4 (Q) | no especificado | 4.9.165 | 4.9-q |
4 (Q) | no especificado | 5.4.41 | 5.4-r (ver nota a continuación) |
4 (Q) | 4 (Q) | 4.9.165 | 4.9-q |
4 (Q) | 4 (Q) | 5.4.41 | Sin coincidencia (sin rama del kernel 5.4-q ) |
4 (Q) | 5 (D) | 4.14.105 | 4.14-r |
4 (Q) | 5 (D) | 5.4.41 | 5.4-r |
5 (D) | no especificado | ningún | VTS falla (debe especificar la versión de FCM del kernel para la versión 5 de FCM de destino) |
5 (D) | 4 (Q) | ningún | VTS falla (versión de FCM del núcleo <versión de FCM de destino) |
5 (D) | 5 (D) | 4.14.180 | 4.14-r |
Hacer coincidir las configuraciones del kernel
Si la sección <kernel>
coincide, el proceso continúa intentando hacer coincidir los elementos de config
con /proc/config.gz
. Para cada elemento de configuración en la matriz de compatibilidad, busca /proc/config.gz
para ver si la configuración está presente. Cuando un elemento de configuración se establece en n
en la matriz de compatibilidad para la sección correspondiente <kernel>
, debe estar ausente de /proc/config.gz
. Finalmente, un elemento de configuración que no esté en la matriz de compatibilidad puede o no estar presente en /proc/config.gz
.
Ejemplo: hacer coincidir las configuraciones del kernel
-
<value type="string">bar</value>
coincide con"bar"
. Las comillas se omiten en la matriz de compatibilidad pero están presentes en/proc/config.gz
. -
<value type="int">4096</value>
coincide con4096
o0x1000
o0X1000
. -
<value type="int">0x1000</value>
coincide con4096
o0x1000
o0X1000
. -
<value type="int">0X1000</value>
coincide con4096
o0x1000
o0X1000
. -
<value type="tristate">y</value>
coincide cony
. -
<value type="tristate">m</value>
coincide conm
. -
<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 con1
,2
o3
, o su equivalente hexadecimal.
Ejemplo: Coincidencia de kernel exitosa
Una matriz de compatibilidad de framework con FCM versión 1 tiene la siguiente información del kernel:
<kernel version="4.14.42"> <config> <key>CONFIG_TRI</key> <value type="tristate">y</value> </config> <config> <key>CONFIG_NOEXIST</key> <value type="tristate">n</value> </config> <config> <key>CONFIG_DEC</key> <value type="int">4096</value> </config> <config> <key>CONFIG_HEX</key> <value type="int">0XDEAD</value> </config> <config> <key>CONFIG_STR</key> <value type="string">str</value> </config> <config> <key>CONFIG_EMPTY</key> <value type="string"></value> </config> </kernel>
La rama del núcleo se empareja primero. La rama del kernel se especifica en el manifiesto del dispositivo en manifest.kernel.target-level
, que por defecto es manifest.level
si no se especifica el primero. Si la rama del kernel en el manifiesto del dispositivo:
- es 1, continúa con el siguiente paso y verifica la versión del kernel.
- es 2, no coincide con la matriz. Los objetos VINTF leen los requisitos del núcleo de la matriz en la versión 2 de FCM.
Entonces, la versión del kernel se empareja. Si un dispositivo en uname()
informa:
- 4.9.84 (no coincide con la matriz a menos que haya una sección de kernel separada con
<kernel version="4.9.x">
, dondex <= 84
) - 4.14.41 (sin coincidencia con la matriz, más pequeña que la
version
) - 4.14.42 (coincidencia con matriz)
- 4.14.43 (coincidencia con matriz)
- 4.1.22 (no coincide con la matriz a menos que haya una sección del kernel separada con
<kernel version="4.1.x">
dondex <= 22
)
Después de seleccionar la sección <kernel>
adecuada, para cada elemento <config>
con un valor distinto de n
, esperamos que la entrada correspondiente esté presente en /proc/config.gz
; para cada elemento <config>
con valor n
, esperamos que la entrada correspondiente no esté presente en /proc/config.gz
. Esperamos que el contenido de <value>
coincida exactamente con el texto después del signo igual (incluidas las comillas), hasta el carácter de nueva línea o #
, con los espacios en blanco iniciales y finales truncados.
La siguiente configuración del kernel es un ejemplo de una coincidencia exitosa:
# comments don't matter CONFIG_TRI=y # CONFIG_NOEXIST shouldn't exist CONFIG_DEC = 4096 # trailing comments and whitespaces are fine CONFIG_HEX=57005 # 0XDEAD == 57005 CONFIG_STR="str" CONFIG_EMPTY="" # empty string must have quotes CONFIG_EXTRA="extra config items are fine too"
La siguiente configuración del núcleo es un ejemplo de una coincidencia fallida:
CONFIG_TRI="y" # mismatch: quotes CONFIG_NOEXIST=y # mismatch: CONFIG_NOEXIST exists CONFIG_HEX=0x0 # mismatch; value doesn't match CONFIG_DEC="" # mismatch; type mismatch (expect int) CONFIG_EMPTY=1 # mismatch; expects "" # mismatch: CONFIG_STR is missing
Coincidencias de política SE
La política SE requiere las siguientes coincidencias:
-
<sepolicy-version>
define un rango cerrado de versiones secundarias para cada versión principal. La versión de la política de seguridad informada por el dispositivo debe estar dentro de uno de estos rangos para ser compatible con el marco. Las reglas de coincidencia son similares a las versiones HAL; es una coincidencia si la versión de sepolicy es superior o igual a la versión mínima para el rango. La versión máxima es puramente informativa. -
<kernel-sepolicy-version>
es decir, versión de policydb. Debe ser menor quesecurity_policyvers()
informado por el dispositivo.
Ejemplo: Coincidencia de política de SE exitosa
La matriz de compatibilidad del marco establece la siguiente información de política:
<sepolicy> <kernel-sepolicy-version>30</kernel-sepolicy-version> <sepolicy-version>25.0</sepolicy-version> <sepolicy-version>26.0-3</sepolicy-version> </sepolicy>
En el dispositivo:
- El valor devuelto por
security_policyvers()
debe ser mayor o igual a 30. De lo contrario, no es una coincidencia. Por ejemplo:- Si un dispositivo devuelve 29, no es una coincidencia.
- Si un dispositivo devuelve 31, es una coincidencia.
- La versión de la política SE debe ser una de 25.0-∞ o 26.0-∞. De lo contrario, no es un partido. (El "
-3
" después de "26.0
" es puramente informativo).
Coincidencias de la versión AVB
La versión AVB contiene una versión MAYOR y una versión MENOR, con el formato MAYOR.MENOR (p. ej., 1.0, 2.1). Para obtener más información, consulte Control de versiones y compatibilidad . La versión AVB tiene las siguientes propiedades del sistema:
-
ro.boot.vbmeta.avb_version
es la versiónlibavb
en el gestor de arranque -
ro.boot.avb_version
es la versiónlibavb
en el sistema operativo Android (init/fs_mgr
)
La propiedad del sistema aparece solo cuando se ha utilizado el libavb correspondiente para verificar los metadatos de AVB (y devuelve OK). Está ausente si se produjo un error de verificación (o no se produjo ninguna verificación).
Una coincidencia de compatibilidad compara lo siguiente:
- sysprop
ro.boot.vbmeta.avb_version
conavb.vbmeta-version
de la matriz de compatibilidad del marco;-
ro.boot.vbmeta.avb_version.MAJOR == avb.vbmeta-version.MAJOR
-
ro.boot.vbmeta.avb_version.MINOR >= avb.vbmeta-version.MINOR
-
- sysprop
ro.boot.avb_version
conavb.vbmeta-version
de la matriz de compatibilidad del marco.-
ro.boot.avb_version.MAJOR == avb.vbmeta-version.MAJOR
-
ro.boot.avb_version.MINOR >= avb.vbmeta-version.MINOR
-
El cargador de arranque o el sistema operativo Android pueden contener dos copias de bibliotecas libavb
, cada una con una versión PRINCIPAL diferente para dispositivos de actualización y dispositivos de inicio. En este caso, se puede compartir la misma imagen del sistema sin firmar , pero las imágenes finales del sistema con firma son diferentes (con diferentes avb.vbmeta-version
):
![](https://source.android.google.cn/devices/architecture/images/treble_vintf_avb_o_p.png?authuser=2&hl=es-419)
/system
es P, todas las demás particiones son O).![](https://source.android.google.cn/devices/architecture/images/treble_vintf_avb_p.png?authuser=2&hl=es-419)
Ejemplo: Coincidencia de versión AVB exitosa
La matriz de compatibilidad del marco establece la siguiente información de AVB:
<avb> <vbmeta-version>2.1</vbmeta-version> </avb>
En el dispositivo:
ro.boot.avb_version == 1.0 && ro.boot.vbmeta.avb_version == 2.1 mismatch
ro.boot.avb_version == 2.1 && ro.boot.vbmeta.avb_version == 3.0 mismatch
ro.boot.avb_version == 2.1 && ro.boot.vbmeta.avb_version == 2.3 match
ro.boot.avb_version == 2.3 && ro.boot.vbmeta.avb_version == 2.1 match
Versión AVB coincidente durante OTA
Para dispositivos lanzados con Android 9 o anterior, al actualizar a Android 10, los requisitos de la versión de AVB en la matriz de compatibilidad del marco se comparan con la versión actual de AVB en el dispositivo. Si la versión de AVB tiene una actualización de versión principal durante una OTA (por ejemplo, de 0.0 a 1.0), la comprobación de compatibilidad de VINTF en OTA no refleja la compatibilidad después de la OTA.
Para mitigar el problema, un OEM puede colocar una versión AVB falsa en el paquete OTA ( compatibility.zip
) para pasar la verificación. Para hacerlo:
- Seleccione las siguientes CL para el árbol fuente de Android 9:
- Defina
BOARD_OTA_FRAMEWORK_VBMETA_VERSION_OVERRIDE
para el dispositivo. Su valor debe ser igual a la versión AVB antes de la OTA, es decir, la versión AVB del dispositivo cuando se lanzó. - Reconstruya el paquete OTA.
Estos cambios colocan automáticamente BOARD_OTA_FRAMEWORK_VBMETA_VERSION_OVERRIDE
como compatibility-matrix.avb.vbmeta-version
en los siguientes archivos:
-
/system/compatibility_matrix.xml
(que no se usa en Android 9) en el dispositivo -
system_matrix.xml
encompatibility.zip
en el paquete OTA
Estos cambios no afectan otras matrices de compatibilidad de framework, incluido /system/etc/vintf/compatibility_matrix.xml
. Después de la OTA, el nuevo valor en /system/etc/vintf/compatibility_matrix.xml
se usa para las comprobaciones de compatibilidad.
Coincidencias de versión de VNDK
La matriz de compatibilidad de dispositivos declara la versión VNDK requerida en compatibility-matrix.vendor-ndk.version
. Si la matriz de compatibilidad de dispositivos no tiene una etiqueta <vendor-ndk>
, no se imponen requisitos y, por lo tanto, siempre se considera una coincidencia.
Si la matriz de compatibilidad de dispositivos tiene una etiqueta <vendor-ndk <vendor-ndk>
, se busca una entrada <vendor-ndk>
con una <version>
coincidente en el conjunto de instantáneas de proveedores de VNDK que proporciona el marco en el manifiesto del marco. Si tal entrada no existe, no hay coincidencia.
Si tal entrada existe, el conjunto de bibliotecas enumeradas en la matriz de compatibilidad de dispositivos debe ser un subconjunto del conjunto de bibliotecas establecido en el manifiesto del marco; de lo contrario, la entrada no se considera una coincidencia.
- Como caso especial, si no se enumeran bibliotecas en la matriz de compatibilidad de dispositivos, la entrada siempre se considera una coincidencia, porque el conjunto vacío es un subconjunto de cualquier conjunto.
Ejemplo: Coincidencia de versión de VNDK exitosa
Si la matriz de compatibilidad de dispositivos establece el siguiente requisito en VNDK:
<!-- Example Device Compatibility Matrix --> <vendor-ndk> <version>27</version> <library>libjpeg.so</library> <library>libbase.so</library> </vendor-ndk>
En el manifiesto del marco, solo se considera la entrada con la versión 27.
<!-- Framework Manifest Example A --> <vendor-ndk> <version>27</version> <library>libjpeg.so</library> <library>libbase.so</library> <library>libfoo.so</library> </vendor-ndk>
El ejemplo A es una coincidencia, porque la versión 27 de VNDK está en el manifiesto del marco y {libjpeg.so, libbase.so, libfoo.so} ⊇ {libjpeg.so, libbase.so}
.
<!-- Framework Manifest Example B --> <vendor-ndk> <version>26</version> <library>libjpeg.so</library> <library>libbase.so</library> </vendor-ndk> <vendor-ndk> <version>27</version> <library>libbase.so</library> </vendor-ndk>
El ejemplo B no es una coincidencia. Aunque la versión 27 de VNDK está en el manifiesto del marco, libjpeg.so
no es compatible con el marco en esa instantánea. Se ignora la versión 26 de VNDK.
Coincidencias de la versión del SDK del sistema
La matriz de compatibilidad de dispositivos declara un conjunto de versiones requeridas del SDK del sistema en compatibility-matrix.system-sdk.version
. Hay una coincidencia solo si el conjunto es un subconjunto de las versiones del SDK del sistema proporcionadas como se declara en manifest.system-sdk.version
en el manifiesto del marco.
- Como caso especial, si no se enumeran versiones del SDK del sistema en la matriz de compatibilidad de dispositivos, siempre se considera una coincidencia, porque el conjunto vacío es un subconjunto de cualquier conjunto.
Ejemplo: coincidencia exitosa de la versión del SDK del sistema
Si la matriz de compatibilidad de dispositivos establece el siguiente requisito en el SDK del sistema:
<!-- Example Device Compatibility Matrix --> <system-sdk> <version>26</version> <version>27</version> </system-sdk>
Luego, el marco debe proporcionar las versiones 26 y 27 del SDK del sistema para que coincidan.
<!-- Framework Manifest Example A --> <system-sdk> <version>26</version> <version>27</version> </system-sdk>
El ejemplo A es una coincidencia.
<!-- Framework Manifest Example B --> <system-sdk> <version>26</version> <version>27</version> <version>28</version> </system-sdk>
El ejemplo B es una coincidencia.
<!-- Framework Manifest Example C --> <system-sdk> <version>26</version> </system-sdk>
El ejemplo C no coincide porque no se proporciona la versión 27 del SDK del sistema.