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 paquete general-tests permite que se realice
como parte de un paquete de asignación de pruebas
que se usa en las 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 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 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 conjunto de pruebas, así como la diferencia entre cada ejecutor de pruebas. El archivo de configuración de prueba generado automáticamente este proceso sea más fácil.
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 está el archivo Android.bp.
Si solo hay un módulo de prueba en el archivo Android.bp, puedes
se cambiará el nombre del archivo XML a AndroidTest.xml, y el sistema de compilación
lo usa 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
ejemplo a continuación.
test_config: "VtsHalUsbV1_1TargetTest.xml",
Ahora tienes un archivo de configuración de prueba para implementar y trabajar 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 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 el framework de Android para ejecutarse, y ejecutar la
la prueba con el framework detenido permite que la prueba se ejecute de manera estable
sin verse afectada por las fragmentos 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 botón
de configuración de prueba se genera automáticamente, puedes agregar los siguientes
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 del nivel de API
Android 12 define ro.board.first_api_level y
Propiedades ro.board.api_level para mostrar el nivel de API de las imágenes de proveedores
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 es
que se establece automáticamente calculando el nivel de API requerido por el proveedor mediante la
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 corresponde al nivel de API cuando las imágenes del proveedor
para un SoC calificado para
bloqueo del proveedor son los primeros
lanzados con esta propiedad. Esto no depende de la API de inicio del dispositivo
pero solo depende del primer nivel de API del SoC que define este valor. El
es permanente durante el ciclo de vida 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 a continuación
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 proveedor init establece la propiedad.
el proceso de administración de recursos.
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 configura automáticamente.
ro.vendor.api_level
La propiedad ro.vendor.api_level se introdujo en
Android 13 para mostrar el nivel de API con el que las imágenes del proveedor
que se requieren para admitirlas. 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 será
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. Pruebas
para la implementación del proveedor que requiera la actualización de la imagen del proveedor podría excluirse
de los requisitos de proveedores para el SoC consultando esta propiedad.
Proceso de fragmentación con VTS
En Android 10 o versiones posteriores, puedes realizar el proceso de fragmentación en varios dispositivos mientras realiza pruebas con planes de VTS y CTS en GSI de acuerdo con lo siguiente: las siguientes instrucciones.
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.