Pruebas de HAL con reconocimiento del nombre del servicio

Android 9 incluye compatibilidad para obtener el nombre del servicio de una instancia de HAL determinada en función del dispositivo en el que se ejecutan las pruebas del paquete de pruebas del proveedor (VTS). Ejecutar pruebas de HAL de VTS que tengan reconocimiento del nombre del servicio permite a los desarrolladores automatizar las pruebas de extensiones del proveedor, varios HAL y varias instancias de HAL en las ejecuciones de pruebas de VTS del destino y del host.

Acerca de los nombres de servicios

Cada instancia del servicio HAL en ejecución se registra con un nombre de servicio.

En versiones anteriores de Android, los desarrolladores que ejecutaban pruebas de HAL de VTS debían establecer el nombre de servicio correcto para el cliente de prueba en getService() o dejar el nombre vacío y recurrir al nombre de servicio predeterminado. Las desventajas de este enfoque incluyen lo siguiente:

  • Dependencia del conocimiento del desarrollador de la prueba para establecer el nombre del servicio correcto.
  • De forma predeterminada, se limita a las pruebas en una sola instancia de servicio.
  • Mantenimiento manual de los nombres de los servicios (es decir, como los nombres están codificados, se deben actualizar de forma manual si cambia el nombre del servicio)

En Android 9, los desarrolladores pueden obtener automáticamente el nombre del servicio para una instancia de HAL determinada en función del dispositivo que se está probando. Entre las ventajas de este enfoque, se incluye la compatibilidad con las pruebas:

  • Extensiones del HAL del proveedor Por ejemplo, cuando un proveedor tiene una implementación de la HAL camera.provider que se ejecuta en dispositivos del proveedor con un nombre de servicio personalizado, VTS puede identificar la instancia del proveedor y ejecutar la prueba en ella.
  • Varias instancias de HAL. Por ejemplo, cuando el HAL graphics.composer tiene dos instancias (una con el nombre de servicio "default" y otra con el nombre de servicio "vr"), VTS puede identificar ambas instancias y ejecutar la prueba en cada una de ellas.
  • Pruebas de varios HAL. Se usa cuando se prueban varios HAL con varias instancias. Por ejemplo, cuando se ejecuta la prueba de VTS que verifica cómo funcionan juntos los HAL de KeyMint (anteriormente Keymaster) y Gatekeeper, VTS puede probar todas las combinaciones de instancias de servicio para esos HAL.

Pruebas del lado del destino

Para habilitar el reconocimiento del nombre del servicio para las pruebas del lado del destino, Android 9 incluye un entorno de prueba personalizable (VtsHalHidlTargetTestEnvBase) que proporciona interfaces para lo siguiente:

  • Registra los HAL de segmentación en la prueba.
  • Enumera todos los HALs registrados.
  • Obtén los nombres de los servicios para los HAL registrados que proporciona el framework de VTS.

Además, el framework de VTS proporciona compatibilidad con el tiempo de ejecución para lo siguiente:

  • Preprocesamiento del archivo binario de prueba para obtener todos los HAL de prueba registrados.
  • Identificar todas las instancias de servicio en ejecución y obtener el nombre de servicio de cada instancia (recuperado según vendor/manifest.xml).
  • Se calculan todas las combinaciones de instancias (para admitir varias pruebas de HAL).
  • Generar una prueba nueva para cada instancia (combinación) de servicio

Ejemplo:

Compatibilidad con el tiempo de ejecución para pruebas del lado del destino

Figura 1: Compatibilidad con el tiempo de ejecución del framework de VTS para pruebas del lado del destino

Configura pruebas del lado del destino que tengan reconocimiento del nombre del servicio

Para configurar tu entorno de pruebas para las pruebas que tienen en cuenta el nombre del servicio del destino, haz lo siguiente:

  1. Define un testEnvironment basado en VtsHalHidlTargetTestEnvBase y registra los HAL de prueba:
    #include <VtsHalHidlTargetTestEnvBase.h>
    class testEnvironment  : public::testing::VtsHalHidlTargetTestEnvBase {
          virtual void registerTestServices() override {
        registerTestService<IFoo>();
          }
    };
  2. Usa getServiceName() proporcionado por el entorno de prueba para pasar el nombre del servicio:
    ::testing::VtsHalHidlTargetTestBase::getService<IFoo>(testEnv->getServiceName<IFoo>("default"));
    // "default" is the default service name you want to use.
  3. Registra el entorno de prueba en main() y initTest:
    int main(int argc, char** argv) {
            testEnv = new testEnvironment();
            ::testing::AddGlobalTestEnvironment(testEnv);
            ::testing::InitGoogleTest(&argc, argv);
            testEnv->init(argc, argv);
            return RUN_ALL_TESTS();
    }

Para obtener ejemplos adicionales, consulta VtsHalCameraProviderV2_4TargetTest.cpp.

Pruebas del VTS del lado del host

Las pruebas del lado del host de VTS ejecutan secuencias de comandos de prueba en el lado del host en lugar de objetos binarios de prueba en el dispositivo de destino. Para habilitar el reconocimiento del nombre del servicio en estas pruebas, puedes usar plantillas del host para ejecutar el mismo guion de prueba varias veces con diferentes parámetros (de manera similar a la prueba parametrizada de gtest).

Compatibilidad con el tiempo de ejecución para pruebas del host

Figura 2: Compatibilidad con el tiempo de ejecución del framework de VTS para pruebas del host
  • La secuencia de comandos de hal test especifica los servicios de HAL de destino en la prueba.
  • El hal_hidl_host_test (subclase de param_test) toma los HAL de prueba registrados del script de prueba, identifica los nombres de servicio correspondientes para el HAL de prueba y, luego, genera combinaciones de nombres de servicio (para pruebas de varios HAL) como parámetros de prueba. También proporciona un método getHalServiceName() que devuelve el nombre del servicio correspondiente según el parámetro que se pasa al caso de prueba actual.
  • La plantilla param_test admite lógica para aceptar una lista de parámetros y ejecutar todos los casos de prueba proporcionados en cada parámetro. Es decir, para cada caso de prueba, genera N casos de prueba nuevos parametrizados (N = tamaño de los parámetros), cada uno con un parámetro determinado.

Configura pruebas del lado del host con reconocimiento del nombre del servicio

Para configurar tu entorno de pruebas para las pruebas que tienen en cuenta el nombre del servicio del host, haz lo siguiente:

  1. Especifica el servicio HAL de destino en la secuencia de comandos de prueba:
    TEST_HAL_SERVICES = { "android.hardware.foo@1.0::IFoo" }
  2. Llama a getHalServiceName() y pasa el nombre a init hal:
    self.dut.hal.InitHidlHal(
                target_type='foo',
                target_basepaths=self.dut.libPaths,
                target_version=1.0,
                target_package='android.hardware.foo',
                target_component_name='IFoo',
                hw_binder_service_name
                      =self.getHalServiceName("android.hardware.foo@1.0::IFoo"),
                bits=int(self.abi_bitness))

Para obtener ejemplos adicionales, consulta VtsHalMediaOmxStoreV1_0HostTest.py.

Cómo registrar HALs de prueba

En versiones anteriores de Android, VTS identificaba el HAL de prueba con la opción <precondition-lshal> configurada en AndroidTest.xml. Este enfoque era difícil de mantener (ya que dependía de que los desarrolladores configuraran la prueba correctamente y actualizaran la configuración según correspondiera) y era impreciso (ya que solo contenía la información del paquete y la versión, y no la información de la interfaz).

En Android 9, VTS identifica el HAL de prueba con reconocimiento del nombre del servicio. Los HAL de prueba registrados también son útiles para lo siguiente:

  • Verificaciones de condiciones previas. Antes de ejecutar una prueba de HAL, VTS puede confirmar que la HAL de prueba está disponible en el dispositivo de destino y omitir las pruebas si no lo está (consulta la verificación de capacidad de prueba de VTS).
  • Medición de la cobertura. VTS admite la medición de la cobertura del código entre procesos a través del conocimiento sobre los servicios HAL de prueba que desea medir (es decir, para vaciar la cobertura del proceso del servicio HAL).