Banco de pruebas
Para que una prueba sea parte de VTS, debe tener la siguiente configuración en Android.bp .
test_suites: ["vts"],
Además, agregar la prueba a la suite general-tests le permite ser parte de una suite de mapeo de prueba utilizada en comprobaciones previas al envío.
Configuración de prueba
En la mayoría de los casos, la configuración de prueba, que es un archivo XML utilizado por Trade Federation para ejecutar una prueba VTS, se genera automáticamente durante la compilación. Sin embargo, puede personalizar la configuración de la prueba.
Crear 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 corredor de prueba. El archivo de configuración de prueba generado automáticamente está diseñado para facilitar este proceso.
Si debe personalizar el archivo XML de prueba, puede utilizar el archivo generado automáticamente como punto de partida.
Para ubicar el archivo de configuración de prueba generado automáticamente, primero ejecute el comando make para crear la configuración, como se muestra a continuación.
$ m VtsHalUsbV1_1TargetTest
En su directorio de compilación, puede 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 múltiples copias del archivo y puede usar cualquiera de ellas. Copie 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 , puede cambiar el nombre del archivo XML a AndroidTest.xml y el sistema de compilación lo usa automáticamente como el archivo de configuración del módulo de prueba. De lo contrario, agregue un atributo test_config al módulo, como se muestra en el siguiente ejemplo.
test_config: "VtsHalUsbV1_1TargetTest.xml",
Ahora tiene un archivo de configuración de prueba para trabajar e implementar la personalización.
Forzar la ejecución de la prueba con adb root
La mayoría de las pruebas de VTS requieren privilegios de root para ejecutarse. Si el archivo de configuración de prueba se genera automáticamente, puede agregar el siguiente atributo a Android.bp .
require_root: true,
Si el archivo de configuración de prueba está personalizado, agregue lo siguiente al archivo XML de prueba.
<target_preparer class="com.android.tradefed.targetprep.RootTargetPreparer"/>
Detener marco durante la prueba
Muchas pruebas de VTS no requieren el marco de Android para ejecutarse, y ejecutar la prueba con el marco detenido permite que la prueba se ejecute con estabilidad sin verse afectada por fallas del dispositivo. Si el archivo de configuración de prueba se genera automáticamente, puede agregar el siguiente atributo a Android.bp .
disable_framework: true,
Si el archivo de configuración de prueba está personalizado, agregue lo siguiente al archivo XML de prueba.
<target_preparer class="com.android.tradefed.targetprep.StopServicesSetup"/>
Agregar argumentos de prueba adicionales
Algunas pruebas gtest pueden requerir más tiempo para ejecutarse. En tales casos, puede agregar opciones de ejecutor de pruebas en el archivo XML.
Por ejemplo, la 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>
Requerir nivel mínimo de API
Algunas pruebas de VTS solo pueden ejecutarse en dispositivos con un nivel mínimo de API. Si el archivo de configuración de prueba se genera automáticamente, puede agregar el siguiente atributo a Android.bp .
test_min_api_level: 29,
Si el archivo de configuración de prueba está personalizado, agregue el siguiente comando al archivo XML de prueba.
<object type="module_controller" class="com.android.tradefed.testtype.suite.module.MinApiLevelModuleController">
<option name="min-api-level" value="29" />
</object>
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. Al combinar estas propiedades con ro.product.first_api_level , los conjuntos de pruebas eligen los casos de prueba adecuados para los dispositivos.
Android 13 define ro.vendor.api_level que se configura automáticamente al calcular el nivel de API del proveedor requerido mediante las propiedades ro.product.first_api_level , ro.board.first_api_level y ro.board.api_level .
ro.board.first_api_level
La propiedad ro.board.first_api_level es el nivel de API cuando las imágenes del proveedor para un SoC se publican por primera vez con esta propiedad. Esto no depende del nivel de API de inicio del dispositivo, sino que solo depende del primer nivel de API del SoC que define este valor. El valor es permanente durante la vida útil del SoC.
Para configurar 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 para vendor/build.prop en el dispositivo. La propiedad la establece el proceso init del proveedor.
ro.board.api_level
La propiedad ro.board.api_level es el nivel de API actual de las imágenes del proveedor para un SoC. Cuando se actualiza el nivel de API de la imagen del proveedor que tiene ro.board.first_api_level , el dispositivo que usa el SoC debe definir la propiedad ro.board.api_level con el nivel de API actual de la imagen del proveedor en lugar de actualizar ro.board.first_api_level . Si no se establece esta propiedad, se utilizará ro.board.first_api_level de manera predeterminada.
Para configurar ro.board.api_level , defina BOARD_API_LEVEL en el archivo device.mk con el valor deseado.
ro.vendor.api_level
La propiedad ro.vendor.api_level se introdujo en Android 13 para mostrar el nivel de API que las imágenes del proveedor deben admitir. Esto se establece automáticamente al mínimo de ro.board.api_level (o ro.board.first_api_level si ro.board.api_level no está definido) y ro.product.first_api_level . Las pruebas para la implementación del proveedor que requieren una actualización de la imagen del proveedor pueden excluirse de los requisitos del proveedor para el SoC haciendo referencia a esta propiedad.
Proceso de fragmentación usando VTS
Para la versión de Android 10 o superior, puede realizar el proceso de fragmentación en varios dispositivos mientras realiza pruebas con los planes VTS y CTS-on-GSI siguiendo las instrucciones a continuación.
run vts --shard-count <number of devices> -s <device serial> ...
Este comando divide el plan 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 CTS-on-GSI en fragmentos y los ejecuta en varios dispositivos.