El conjunto de pruebas de proveedores (VTS) de Android 9 admite lo siguiente: método de tiempo de ejecución para usar la configuración del dispositivo a fin de identificar qué pruebas de VTS se deben omitir para esa orientación por dispositivo.
Flexibilidad de pruebas de VTS
A partir de Android 8.0, las pruebas de VTS son obligatorias para todos los dispositivos lanzados con Android 8.0 y versiones posteriores Sin embargo, no todas las pruebas de VTS se aplican a todos los dispositivos objetivos. Por ejemplo:
- Si un dispositivo específico no admite una HAL de prueba (por ejemplo, IR), el VTS sí lo hace. 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 del proveedor, pero tienen funciones de hardware diferentes, los VTS deben determinar si se deben ejecutarse u omitirse para una segmentación por dispositivo específica.
Tipos de pruebas de VTS
El VTS incluye los siguientes tipos de prueba:
- Las pruebas de cumplimiento garantizan la compatibilidad entre el marco de trabajo y las particiones de proveedor. Es necesario que estas pruebas se ejecuten (y aprueben) en dispositivos que se lanzan con Android 8.0 o versiones posteriores.
- Las pruebas de incumplimiento ayudan a los proveedores a mejorar el producto calidad (rendimiento/fuzzing, etc.). Estas pruebas son opcionales para los proveedores.
Que una prueba sea una prueba de cumplimiento o no depende del plan a la que pertenezca a los que tiene acceso una cuenta. Pruebas que se ejecutan con plan de VTS se consideran pruebas de cumplimiento.
Cómo determinar las HAL admitidas
El VTS puede usar los siguientes archivos para determinar si el dispositivo de destino admite una HAL específica:
/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
optional
indica si la HAL está que requiere el framework. - El archivo puede contener varias entradas para la misma HAL (con el mismo nombre). pero con diferentes versiones e interfaces.
- El archivo puede contener varias configuraciones
version
para la misma entrada, lo que indica que el framework puede funcionar con diferentes versiones. version1.0-1
significa que el framework puede funcionar con la menor versión 1.0 y no requiere una versión posterior a 1.1.
- El atributo
- Dispositivo
manifest.xml
. Reclama las instancias de HAL que proporciona el con el proveedor de servicios en la nube. 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 diferentes versiones e interfaces.
- Si el archivo contiene una sola configuración
version
para una entrada,version1.2
significa que el proveedor admite todas las versiones de 1.0 a 1.2.
- lshal. Una herramienta en el dispositivo que muestra información del tiempo de ejecución sobre
los servicios de HAL registrados con
hwservicemanager
Ejemplo:android.hardware.vibrator@1.0::IVibrator/default
lshal
también muestra todas las HALs que tienen transferencia implementaciones (es decir, tener el archivo-impl.so
correspondiente 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
Para las pruebas de cumplimiento, VTS se basa en el manifiesto del proveedor para determinar (y prueba) todas las instancias HAL proporcionadas por el dispositivo. Flujo de decisiones:
Pruebas de incumplimiento
Para las pruebas de incumplimiento, el VTS se basa en el manifiesto del proveedor y
lshal
salidas para determinar (y probar) las HAL experimentales que no
reclamado en el archivo manifest.xml
. Flujo de decisiones:
Ubica el manifiesto del proveedor
El VTS verifica el archivo manifest.xml
del proveedor en la siguiente situación:
lugares en el siguiente orden:
/vendor/etc/vintf/manifest.xml
+ manifiesto de ODM (si es la misma HAL) se define en ambos lugares, el manifiesto ODM anula el que aparece en/vendor/etc/vintf/manifest.xml
)/vendor/etc/vintf/manifest.xml
- Archivo ODM
manifest.xml
, cargado de 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
El
vts_testibility_checker
es un objeto binario empaquetado con VTS y utilizado por
VTS en el tiempo de ejecución para determinar si una prueba HAL determinada se
comprobable o no. Se basa en
libvintf
para cargar y analizar el archivo de manifiesto del proveedor e implementa el flujo de decisión
que se describe en la sección anterior.
Para usar vts_testability_check
, haz lo siguiente:
- Para una prueba de cumplimiento:
vts_testability_check -c -b <bitness> <hal@version>
- Para una prueba de incumplimiento:
vts_testability_check -b <bitness> <hal@version>
La salida de vts_testability_check
usa el siguiente JSON.
formato:
{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
usa el
VtsHalHidlTargetTestEnvBase
para registrar las HAL a las que se accedió en la prueba. Las pruebas de VTS
Luego, el framework puede extraer las HAL registradas cuando realiza el procesamiento previo de la prueba.
Para las pruebas de cumplimiento, también puedes consultar
/system/etc/vintf/manifest.xml
Si aquí se define una HAL, los VTS
deberías probarlo. (Para los servicios HAL que proporciona el sistema (p.ej.,
graphics.composer/vr
), las HAL se declaran en
/system/manifest.xml
).