El paquete de pruebas para proveedores (VTS) de Android 9 admite un método de tiempo de ejecución para usar la configuración del dispositivo y así identificar qué pruebas de VTS se deben omitir para ese dispositivo de destino.
Flexibilidad de las pruebas del VTS
A partir de Android 8.0, las pruebas de VTS son obligatorias para todos los dispositivos que se lanzan con Android 8.0 y versiones posteriores. Sin embargo, no todas las pruebas de VTS se aplican a todos los destinos de dispositivos. Por ejemplo:
- Si un dispositivo específico no admite un HAL de prueba (p.ej., IR), VTS no necesita ejecutar pruebas para esa prueba de HAL en ese dispositivo de destino.
- Si varios dispositivos comparten el mismo SoC y la misma imagen de proveedor, pero tienen diferentes funcionalidades de hardware, VTS debe determinar si se debe ejecutar o omitir una prueba para una segmentación por dispositivo específica.
Tipos de pruebas de VTS
La VTS incluye los siguientes tipos de pruebas:
- Las pruebas de cumplimiento garantizan la compatibilidad entre las particiones del marco de trabajo y las del proveedor. Estas pruebas deben ejecutarse (y aprobarse) en dispositivos que se inician con Android 8.0 o versiones posteriores.
- Las pruebas de incumplimiento ayudan a los proveedores a mejorar la calidad de los productos (rendimiento o fuzzing, etcétera). Estas pruebas son opcionales para los proveedores.
Si una prueba es de cumplimiento o no depende del plan al que pertenece. Las pruebas que se ejecutan con el plan de VTS se consideran pruebas de cumplimiento.
Cómo determinar las HAL admitidas
VTS puede usar los siguientes archivos para determinar si el dispositivo de destino admite un HAL específico:
/system/compatibility_matrix.xml: Reclama las instancias de HAL que requiere el framework. Ejemplo:<hal format="hidl" optional="true"> <name>android.hardware.vibrator</name> <version>1.0-1</version> <interface> <name>IVibrator</name> <instance>default</instance> </interface> </hal>- El atributo
optionalindica si el framework requiere estrictamente el HAL. - El archivo puede contener varias entradas para el mismo HAL (con el mismo nombre), pero con diferentes versiones e interfaces.
- El archivo puede contener varias configuraciones de
versionpara la misma entrada, lo que indica que el framework puede funcionar con diferentes versiones. version1.0-1significa que el framework puede funcionar con la versión 1.0 más baja y no requiere una versión superior a 1.1.
- El atributo
- Dispositivo
manifest.xml. Reclama las instancias de HAL que proporciona el proveedor. Ejemplo:<hal format="hidl"> <name>android.hardware.vibrator</name> <transport>hwbinder</transport> <version>1.2</version> <interface> <name>IVibrator</name> <instance>default</instance> </interface> </hal>- El archivo puede contener varias entradas para la misma HAL (con el mismo nombre), pero con interfaces y versiones diferentes.
- Si el archivo contiene solo una configuración
versionpara una entrada,version1.2significa que el proveedor admite todas las versiones de 1.0 a 1.2.
- lshal. Es una herramienta en el dispositivo que muestra información del tiempo de ejecución sobre los servicios HAL registrados con el
hwservicemanager. Ejemplo:android.hardware.vibrator@1.0::IVibrator/default
lshaltambién muestra todas las HALs con implementaciones de transferencia (es decir, que tienen el archivo-impl.socorrespondiente en el dispositivo). Ejemplo:android.hardware.nfc@1.0::I*/* (/vendor/lib/hw/) android.hardware.nfc@1.0::I*/* (/vendor/lib64/hw/)
Pruebas de cumplimiento
En el caso de las pruebas de cumplimiento, VTS se basa en el manifiesto del proveedor para determinar (y probar) todas las instancias de HAL que proporciona el dispositivo. Flujo de decisión:
Pruebas de incumplimiento
En el caso de las pruebas de incumplimiento, VTS se basa en el manifiesto del proveedor y en los resultados de lshal para determinar (y probar) los HAL experimentales que no se reclamaron en el archivo manifest.xml. Flujo de decisiones:
Ubica el manifiesto del proveedor
VTS busca el archivo manifest.xml del proveedor en las siguientes ubicaciones en el siguiente orden:
/vendor/etc/vintf/manifest.xml+ manifiesto de ODM (si se define la misma HAL en ambos lugares, el manifiesto de ODM anula el de/vendor/etc/vintf/manifest.xml)/vendor/etc/vintf/manifest.xml- Archivo
manifest.xmlde ODM, cargado desde los siguientes archivos en el siguiente orden:/odm/etc/vintf/manifest_$(ro.boot.product.hardware.sku).xml/odm/etc/vintf/manifest.xml/odm/etc/manifest_$(ro.boot.product.hardware.sku).xml/odm/etc/manifest.xml/vendor/manifest.xml
Verificador de capacidad de prueba de VTS
vts_testibility_checker es un objeto binario empaquetado con VTS que usa el framework de pruebas de VTS durante el tiempo de ejecución para determinar si se puede probar una prueba de HAL determinada. Se basa en libvintf para cargar y analizar el archivo de manifiesto del proveedor y, luego, implementa el flujo de decisión descrito en la sección anterior.
Para usar vts_testability_check, haz lo siguiente:
- Para una prueba de cumplimiento, haz lo siguiente:
vts_testability_check -c -b <bitness> <hal@version>
- Para una prueba de incumplimiento, haz lo siguiente:
vts_testability_check -b <bitness> <hal@version>
El resultado de vts_testability_check usa el siguiente formato JSON:
{testable: <True/False> Instances: <list of instance names of HAL service>}Cómo determinar las HAL a las que se accedió
Para determinar a qué HALs acceden las pruebas de VTS, asegúrate de que cada prueba de HAL use la plantilla VtsHalHidlTargetTestEnvBase para registrar los HAL a los que se accede en la prueba. Luego, el framework de pruebas de VTS puede extraer los HAL registrados cuando se preprocesa la prueba.
Para realizar pruebas de cumplimiento, también puedes verificar /system/etc/vintf/manifest.xml. Si se define un HAL aquí, VTS debería probarlo. (Para los servicios de HAL que proporciona el sistema (p.ej., graphics.composer/vr), los HAL se declaran en /system/manifest.xml).