Paquete 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 asignación de pruebas que se usa en las verificaciones 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 que Trade Federation usa 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 en formato XML de prueba desde cero puede ser complicado, ya que implica comprender cómo funciona el agente de prueba y 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 tu 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 en formato XML por 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, 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 para trabajar y, luego, implementar la personalización.
Fuerza la ejecución de la prueba con raíz de adb
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 el archivo de configuración de prueba está personalizado, agrega lo siguiente al archivo XML de prueba.
<target_preparer class="com.android.tradefed.targetprep.RootTargetPreparer"/>
Detén 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 se ejecute con estabilidad sin verse afectada por los errores 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 el archivo de configuración de prueba está personalizado, agrega lo siguiente al archivo XML de 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 en formato 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>
Se requiere 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 el archivo de configuración de prueba está personalizado, agrega el siguiente comando al archivo XML de 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 de 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 configura 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 cuando las imágenes de proveedor de un SoC calificado para la inhabilitación de proveedores se lanzan por primera vez con esta propiedad. Esto no depende del nivel de API de lanzamiento 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 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 actual del proveedor de las imágenes del proveedor que tiene 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 las imágenes del proveedor deben admitir. 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 que ro.product.first_api_level. La versión se reemplazará por el nivel de API del proveedor correspondiente si está configurada en la versión de ro.product.first_api_level que es mayor o igual que 35. Si se hace referencia a esta propiedad, se pueden excluir de los requisitos del proveedor para el SoC las pruebas de implementación del proveedor que requieran la actualización de la imagen del proveedor.
Proceso de fragmentación con VTS
Para Android 10 o versiones posteriores, puedes realizar el proceso de fragmentación en varios dispositivos mientras realizas pruebas con planes de VTS y CTS en GSI. Para ello, sigue 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.