Verificación de capacidad de prueba de HAL

El conjunto de pruebas del proveedor (VTS) de Android 9 admite un método de tiempo de ejecución para usar la configuración del dispositivo y, así, identificar las pruebas de VTS que deberían omitirse para ese objetivo del dispositivo.

Flexibilidad de las pruebas de VTS

A partir de Android 8.0, las pruebas de VTS son obligatorias para todos los dispositivos que se lancen 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 objetivo del dispositivo.
• Si varios dispositivos comparten el mismo SoC y la misma imagen del proveedor, pero tienen diferentes funcionalidades de hardware, el VTS debe determinar si se debe ejecutar o omitir una prueba para un destino de dispositivo específico.

Tipos de pruebas de VTS

El VTS incluye los siguientes tipos de pruebas:

• Las pruebas de cumplimiento garantizan la compatibilidad entre las particiones del framework y del proveedor. Estas pruebas deben ejecutarse (y aprobarse) en los dispositivos que se lancen con Android 8.0 o versiones posteriores.
• Las pruebas de incumplimiento ayudan a los proveedores a mejorar la calidad del producto (rendimiento, 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 los HAL compatibles

VTS puede usar los siguientes archivos para determinar si el destino del dispositivo 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 optional indica si el HAL es estrictamente necesario para el framework.
  • El archivo puede contener varias entradas para el mismo HAL (con el mismo nombre), pero con diferentes versiones e interfaces.
  • El archivo puede contener varios parámetros de configuración de 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 versión más baja, 1.0, y no requiere una versión superior a 1.1.
• 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 varias entradas para el mismo HAL (con el mismo nombre), pero con diferentes versiones e interfaces.
  • Si el archivo contiene solo una configuración de version para una entrada, version1.2 significa 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 de HAL registrados con hwservicemanager. Ejemplo:

  android.hardware.vibrator@1.0::IVibrator/default

  
  lshal también muestra todos los 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 cumplimiento

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, el VTS se basa en el manifiesto del proveedor y en los resultados de lshal para determinar (y probar) los HAL experimentales que no se reclaman en el archivo manifest.xml. Flujo de decisión:

Cómo ubicar el manifiesto del proveedor

VTS verifica el archivo manifest.xml del proveedor en los siguientes lugares y en el siguiente orden:

1. /vendor/etc/vintf/manifest.xml + manifiesto del ODM (si se define el mismo HAL en ambos lugares, el manifiesto del ODM anula el de /vendor/etc/vintf/manifest.xml)
2. /vendor/etc/vintf/manifest.xml
3. Archivo manifest.xml del ODM, cargado desde los siguientes archivos en el siguiente orden:
   1. /odm/etc/vintf/manifest_$(ro.boot.product.hardware.sku).xml
   2. /odm/etc/vintf/manifest.xml
   3. /odm/etc/manifest_$(ro.boot.product.hardware.sku).xml
   4. /odm/etc/manifest.xml
   5. /vendor/manifest.xml

Verificador de capacidad de prueba de VTS

vts_testibility_checker es un archivo binario empaquetado con VTS y utilizado por el marco de trabajo de prueba de VTS en el tiempo de ejecución para determinar si una prueba de HAL determinada es apta para la prueba o no. Se basa en libvintf para cargar y analizar el archivo de manifiesto del proveedor, y, además, implementa el flujo de decisiones que se describió 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>

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 los HAL a los que se accedió

Para determinar a qué HAL 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 durante el preprocesamiento de la prueba.

En el caso de las pruebas de cumplimiento, también puedes consultar /system/etc/vintf/manifest.xml. Si se define un HAL aquí, VTS debería probarlo. (En el caso de los servicios de HAL proporcionados por el sistema, p.ej., graphics.composer/vr, los HAL se declaran en /system/manifest.xml).