Paquete de pruebas
Para que una prueba forme parte de VTS, debe tener el siguiente parámetro de configuración en Android.bp.
test_suites: ["vts"],
Además, agregar la prueba al conjunto general-tests permite que forme parte de un conjunto de Test Mapping que se usa en las verificaciones previas a la confirmación.
Configuración de prueba
En la mayoría de los casos, la configuración de la prueba, que es un archivo XML que usa Trade Federation para ejecutar una prueba de VTS, se genera automáticamente durante la compilación. Sin embargo, puedes personalizar la configuración de la prueba.
Crea un archivo de configuración de prueba personalizado
Crear un nuevo archivo XML de prueba desde cero puede ser complicado, ya que implica comprender cómo funciona el arnés de prueba, así como la diferencia entre cada ejecutor de pruebas. El archivo de configuración de prueba generado automáticamente está diseñado para facilitar este proceso.
Si debes personalizar el archivo XML de prueba, puedes usar el archivo generado automáticamente como punto de partida.
Para ubicar el archivo de configuración de prueba generado automáticamente, primero ejecuta el comando make para compilar la configuración, como se muestra a continuación.
$ m VtsHalUsbV1_1TargetTest
En el directorio de compilación, puedes buscar el archivo de configuración según el nombre del módulo, como se muestra a continuación.
$ find out/ -name VtsHalUsbV1_1TargetTest.config
Puede haber varias copias del archivo, y puedes usar cualquiera de ellas.
Copia el archivo .config en el directorio donde se encuentra el archivo Android.bp.
Si solo hay un módulo de prueba en el archivo Android.bp, puedes cambiar el nombre del archivo XML a AndroidTest.xml, y el sistema de compilación lo usará automáticamente como el archivo de configuración del módulo de prueba. De lo contrario, agrega un atributo test_config al módulo, como se muestra en el siguiente ejemplo.
test_config: "VtsHalUsbV1_1TargetTest.xml",
Ahora tienes un archivo de configuración de prueba con el que puedes trabajar y, luego, implementar la personalización.
Cómo forzar la ejecución de la prueba con adb root
La mayoría de las pruebas de VTS requieren privilegios de raíz para ejecutarse. Si el archivo de configuración de prueba se genera automáticamente, puedes agregar el siguiente atributo a Android.bp.
require_root: true,
Si se personalizó el archivo de configuración de la prueba, agrega lo siguiente al archivo XML de la prueba.
<target_preparer class="com.android.tradefed.targetprep.RootTargetPreparer"/>
Detener el framework durante la prueba
Muchas pruebas de VTS no requieren que se ejecute el framework de Android, y ejecutar la prueba con el framework detenido permite que la prueba se ejecute con estabilidad sin verse afectada por las inestabilidades del dispositivo. Si el archivo de configuración de prueba se genera automáticamente, puedes agregar el siguiente atributo a Android.bp.
disable_framework: true,
Si se personalizó el archivo de configuración de la prueba, agrega lo siguiente al archivo XML de la prueba.
<target_preparer class="com.android.tradefed.targetprep.StopServicesSetup"/>
Cómo agregar argumentos de prueba adicionales
Es posible que algunas pruebas de gtest requieran más tiempo para ejecutarse. En esos casos, puedes agregar opciones del ejecutor de pruebas en el archivo XML.
Por ejemplo, el parámetro de configuración native-test-timeout en la siguiente entrada permite que la prueba se ejecute con un tiempo de espera de 3 minutos, en lugar del valor predeterminado de 1 minuto.
<test class="com.android.tradefed.testtype.GTest" >
<option name="native-test-device-path" value="/data/local/tmp" />
<option name="module-name" value="VtsHalNfcV1_0TargetTest" />
<option name="native-test-timeout" value="180000"/>
</test>
Cómo requerir un nivel de API mínimo
Algunas pruebas de VTS solo se pueden ejecutar en dispositivos con un nivel de API mínimo. Si el archivo de configuración de prueba se genera automáticamente, puedes agregar el siguiente atributo a Android.bp.
min_shipping_api_level: 29,
o
vsr_min_shipping_api_level: 202404,
Si se personalizó el archivo de configuración de la prueba, agrega el siguiente comando al archivo XML de la prueba.
<object type="module_controller" class="com.android.tradefed.testtype.suite.module.ShippingApiLevelModuleController">
<option name="min-api-level" value="29" />
</object>
o
<object type="module_controller" class="com.android.tradefed.testtype.suite.module.ShippingApiLevelModuleController">
<option name="vsr-min-api-level" value="202404" />
</object>
Propiedades del nivel de API
Android 12 define las propiedades ro.board.first_api_level y ro.board.api_level para mostrar el nivel de API de las imágenes del proveedor en estos dispositivos. Cuando se combinan estas propiedades con ro.product.first_api_level, los paquetes de pruebas eligen los casos de prueba adecuados para los dispositivos.
Android 13 define ro.vendor.api_level, que se establece automáticamente calculando el nivel de API del proveedor requerido con las propiedades ro.product.first_api_level, ro.board.first_api_level y ro.board.api_level.
Para obtener más detalles, consulta Nivel de API del proveedor.
ro.board.first_api_level
La propiedad ro.board.first_api_level es el nivel de API en el que las imágenes del proveedor para un SoC apto para la congelación del proveedor se lanzan por primera vez con esta propiedad. Esto no depende del nivel de API de lanzamiento del dispositivo, sino solo del primer nivel de API del SoC que define este valor. El valor es permanente durante la vida útil del SoC.
Para establecer ro.board.first_api_level, los fabricantes de dispositivos pueden definir BOARD_SHIPPING_API_LEVEL en su archivo device.mk, como se muestra en el siguiente ejemplo:
# BOARD_SHIPPING_API_LEVEL sets ro.product.first_api_level to indicate
# the first api level that the device has been commercially launched on.
BOARD_SHIPPING_API_LEVEL := 23
Definirá automáticamente la propiedad ro.board.first_api_level como vendor/build.prop en el dispositivo. El proceso init del proveedor establece la propiedad.
ro.board.api_level
La propiedad ro.board.api_level es el nivel de API del proveedor actual de las imágenes del proveedor que tienen el formato YYYYMM en el que se congeló la API del proveedor. El sistema de compilación lo establece automáticamente.
ro.vendor.api_level
La propiedad ro.vendor.api_level se introdujo en Android 13 para mostrar el nivel de API que deben admitir las imágenes del proveedor. Este valor se establece automáticamente en ro.product.first_api_level o ro.board.api_level si ro.board.first_api_level está presente y ro.board.api_level se establece en un nivel de API anterior a ro.product.first_api_level. La versión se reemplazará por el nivel de API del proveedor correspondiente si se establece en la versión de ro.product.first_api_level, que es mayor o igual que 35. Las pruebas para la implementación del proveedor que requieren la actualización de la imagen del proveedor se pueden excluir de los requisitos del proveedor para el SoC haciendo referencia a esta propiedad.
Proceso de fragmentación con VTS
En el caso de Android 10 o versiones posteriores, puedes realizar el proceso de fragmentación en varios dispositivos mientras realizas pruebas con los planes de VTS y CTS en GSI siguiendo las instrucciones que se indican a continuación.
run vts --shard-count <number of devices> -s <device serial> ...
Este comando divide el plan de VTS en fragmentos y los ejecuta en varios dispositivos.
run cts-on-gsi --shard-count <number of devices> -s <device serial> -s ...
Este comando divide el plan de CTS en GSI en fragmentos y los ejecuta en varios dispositivos.