Banco de pruebas
Para que una prueba forme parte de VTS, debe tener la siguiente configuración en Android.bp .
test_suites: ["vts"],
Además, agregar la prueba al conjunto general-tests le permite ser parte de un conjunto de mapeo de pruebas utilizado 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.
Cree un archivo de configuración de prueba personalizado
Crear un nuevo archivo XML de prueba desde cero puede resultar 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 varias copias del archivo y puede utilizar cualquiera de ellas. Copie el archivo .config al directorio donde está 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 usará automáticamente como 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 con el que trabajar e implementar la personalización.
Forzar la ejecución de la prueba con adb root
La mayoría de las pruebas 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 el marco durante la prueba.
Muchas pruebas de VTS no requieren la ejecución del marco de Android, 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 de gtest pueden requerir más tiempo para ejecutarse. En tales casos, puede agregar opciones del 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 API mínimo
Algunas pruebas VTS solo pueden ejecutarse en dispositivos con un nivel API mínimo. 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 establece automáticamente calculando 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 toda 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 en 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 API actual de las imágenes del proveedor para un SoC. Cuando se actualiza el nivel API de la imagen del proveedor que tiene ro.board.first_api_level , el dispositivo que utiliza el SoC debe definir la propiedad ro.board.api_level con el nivel API actual de la imagen del proveedor en lugar de actualizar ro.board.first_api_level . Si esta propiedad no está configurada, se utilizará ro.board.first_api_level de forma 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 en el 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 al hacer referencia a esta propiedad.
Proceso de fragmentación usando VTS
Para la versión 10 de Android o superior, puede realizar el proceso de fragmentación en varios dispositivos mientras realiza pruebas con 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.