Android 9 Vendor Test Suite (VTS) admite un método de tiempo de ejecución para usar la configuración del dispositivo para identificar qué pruebas de VTS se deben omitir para ese dispositivo de destino.
Flexibilidad de prueba VTS
A partir de Android 8.0, se requieren pruebas VTS para todos los dispositivos lanzados con Android 8.0 y superior. Sin embargo, no todas las pruebas de VTS se aplican a todos los dispositivos de destino. Por ejemplo:
- Si un dispositivo específico no es compatible con una prueba HAL (por ejemplo, IR), VTS no necesita ejecutar pruebas para esa prueba HAL contra ese dispositivo objetivo.
- Si varios dispositivos comparten el mismo SoC y la imagen del proveedor pero tienen diferentes funcionalidades de hardware, VTS debe determinar si se debe ejecutar o omitir una prueba para un objetivo de dispositivo específico.
Tipos de prueba VTS
VTS incluye los siguientes tipos de pruebas:
- Las pruebas de cumplimiento garantizan la compatibilidad entre el marco y las particiones del proveedor. Estas pruebas deben ejecutarse (y aprobarse) en dispositivos que se inician con Android 8.0 o superior.
- Las pruebas de incumplimiento ayudan a los proveedores a mejorar la calidad del producto (rendimiento/fuzzing, etc.). Estas pruebas son opcionales para los proveedores.
Si una prueba es una prueba de cumplimiento o no, depende del plan al que pertenezca. Las pruebas que se ejecutan con el plan VTS se consideran pruebas de cumplimiento.
Determinar las HAL admitidas
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 HAL requeridas por el marco. 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 el marco requiere estrictamente HAL. - El archivo puede contener múltiples entradas para la misma HAL (con el mismo nombre) pero con diferentes versiones e interfaces.
- El archivo puede contener configuraciones de varias
version
para la misma entrada, lo que indica que el marco puede funcionar con diferentes versiones. -
version1.0-1
significa que el marco puede funcionar con la versión más baja 1.0 y no requiere una versión superior a la 1.1.
- El atributo
- Dispositivo
manifest.xml
. Reclama las instancias de HAL proporcionadas por 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 múltiples entradas para la misma HAL (con el mismo nombre) pero con diferentes versiones e interfaces.
- Si el archivo contiene solo una configuración de una sola
version
para una entrada,version1.2
significa que el proveedor admite todas las versiones desde la 1.0 a la 1.2.
- lshal . Una herramienta en el dispositivo que muestra información de tiempo de ejecución sobre los servicios HAL registrados con
hwservicemanager
. Ejemplo:android.hardware.vibrator@1.0::IVibrator/default
lshal
también muestra todas las HAL que tienen implementaciones de transferencia (es decir, que tienen 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 conformidad
Para las pruebas de cumplimiento, VTS se basa en el manifiesto del proveedor para determinar (y probar) todas las instancias de HAL proporcionadas por el dispositivo. Flujo de decisión:
Pruebas de incumplimiento
Para las pruebas de incumplimiento, VTS se basa en el manifiesto del proveedor y los resultados lshal
para determinar (y probar) las HAL experimentales que no se reclaman en el archivo manifest.xml
. Flujo de decisión:
Localice el manifiesto del proveedor
VTS busca el archivo manifest.xml
del proveedor en los siguientes lugares en el siguiente orden:
-
/vendor/etc/vintf/manifest.xml
+ manifiesto ODM (si se define el mismo HAL en ambos lugares, el manifiesto ODM anula el de/vendor/etc/vintf/manifest.xml
) -
/vendor/etc/vintf/manifest.xml
- Archivo ODM
manifest.xml
, 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
-
Comprobador de comprobabilidad VTS
El vts_testibility_checker
es un binario empaquetado con VTS y utilizado por el marco de prueba de VTS en tiempo de ejecución para determinar si una prueba HAL dada es comprobable o no. Se basa en libvintf
para cargar y analizar el archivo de manifiesto del proveedor e implementa el flujo de decisiones descrito en la sección anterior.
Para usar vts_testability_check
:
- 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 formato json:
{testable: <True/False> Instances: <list of instance names of HAL service>}
Determinar las HAL a las que se accedió
Para determinar a qué HAL acceden las pruebas de VTS, asegúrese de que cada prueba de HAL use la plantilla VtsHalHidlTargetTestEnvBase
para registrar las HAL a las que se accede en la prueba. El marco de prueba de VTS puede luego extraer los HAL registrados al preprocesar la prueba.
Para las pruebas de cumplimiento, también puede consultar /system/etc/vintf/manifest.xml
. Si aquí se define una HAL, VTS debería probarla. (Para los servicios HAL proporcionados por el sistema (p. ej., graphics.composer/vr
), los HAL se declaran en /system/manifest.xml
).