Google se compromete a impulsar la igualdad racial para las comunidades afrodescendientes. Obtén información al respecto.

Infraestructura de prueba automatizada

Android 9 incluye una infraestructura Vendor Test Suite (VTS) para pruebas automatizadas de VTS, CTS u otras pruebas en dispositivos de socios que ejecutan la imagen del sistema genérico (GSI) de AOSP. Anteriormente, ejecutar estas pruebas era una operación muy manual; la nueva infraestructura de prueba de VTS está diseñada para admitir pruebas automatizadas varias veces al día en varios dispositivos.

Arquitectura

La infraestructura de pruebas automatizadas de VTS utiliza la siguiente arquitectura:

Automated test architecture

Figura 1. VTS arquitectura de infraestructura de prueba automatizada

Cuando se activa una prueba, la infraestructura de pruebas automatizadas de VTS realiza las siguientes tareas:

  1. Obtiene artefactos de construcción y recursos de prueba desde diferentes ubicaciones:
    • Construir socio de Android (PAB). Para el marco GSI, VTS y algunas otras compilaciones.
    • Sistema de ficheros local, Google Cloud Storage, u otro sistema de construcción específica del proveedor. Para socios que no almacenan compilaciones en la nube de Google.
  2. Los flashes construyen artefactos (desde el dispositivo) y el GSI (desde AOSP) en los dispositivos conectados.
  3. Ejecuta pruebas de VTS utilizando TradeFed local o TradeFed en la nube.
  4. Reporta los resultados de las pruebas al tablero de VTS

El proceso es coordinado por el controlador de host VTS (HC), una máquina en el laboratorio que dirige el comportamiento de todos los dispositivos conectados bajo prueba. El HC es responsable de obtener las últimas versiones, actualizarlas en los dispositivos e invocar las pruebas (ya sea localmente o mediante el comandante). También se comunica con un programador en la nube y dirige el tráfico entre el programador y la instancia de TradeFed (o algún otro arnés) que se ejecuta en el HC. Para más detalles sobre el controlador de host, consulte Arquitectura de controlador de host .

Proveedores de recursos

Las pruebas automatizadas requieren recursos como compilaciones del sistema, archivos de prueba y artefactos VTS. Si bien es posible compilarlos desde la fuente, es más fácil compilarlos desde la punta del árbol con regularidad y luego publicar los artefactos para su descarga.

Los socios pueden acceder a los recursos de automatización utilizando las siguientes ubicaciones:

  • Construir socio de Android. Acceso programático otorgado por cuenta.
  • Sistema de ficheros local (o similar). Para socios que no utilizan la compilación de Android para socios.

Para su uso en los dispositivos de parpadear después, los recursos incluyen los proveedores de construcción para las dos opciones, que se extiende desde un solo build_provider.py que almacena las compilaciones en los directorios temporales locales.

Compilación de Android para socios

En Android 8.1 y menores emisiones, se exigió a los socios de Android para visitar el sitio web de socios de Android Construido ( https://partner.android.com/build ), acceda a su cuenta, y obtener los últimos imágenes del sistema a través de la interfaz de usuario. Para ayudar a los socios a evitar este proceso lento y laborioso, Android 9 incluye soporte para descargar automáticamente estos recursos de PAB cuando se proporcionan las credenciales adecuadas.

Estableciendo acceso

El acceso programático utiliza OAuth2 en las API de Google para acceder a las RPC necesarias. Utilizando el enfoque estándar para la generación de credenciales OAuth2, el socio debe establecer un ID de cliente / par secreto con Google. Cuando el PartnerAndroidBuildClient se refirió a ese secreto, por primera vez, se abre una ventana del navegador para que el usuario ingrese a su cuenta de Google, que genera las credenciales OAuth2 necesarios para seguir adelante. Las credenciales (token de acceso y token de actualización) se almacenan localmente, lo que significa que los socios deben iniciar sesión solo una vez.

Solicitud POST de URL

Al hacer clic en el enlace de un recurso en la PAB, se envía una solicitud POST que incluye los datos necesarios para ese recurso, que incluyen:

  • ID de compilación, objetivo de compilación
  • nombre del recurso
  • rama
  • Publicar el nombre del candidato y si el candidato es una compilación interna.

La solicitud POST es recibida por el downloadBuildArtifact método de la buildsvc RPC, que devuelve una URL que se puede utilizar para acceder al recurso.

  • Para los recursos APK de Clockwork Companion, la URL es una URL legible alojada en PAB (que está protegida por autenticación y accesible con las credenciales de OAuth2 adecuadas).
  • Para otros recursos, la URL es una URL larga y no protegida de la API de compilación interna de Android (que caduca después de cinco minutos).

Obteniendo la URL

Para evitar cross-site solicitud falsificación, la buildsvc RPC requiere una XSRF de contadores a ser publicado con los otros parámetros. Si bien este token hace que el proceso sea más seguro, también dificulta el acceso mediante programación, ya que el token (que solo está disponible en el JavaScript de la página PAB) ahora también es necesario para acceder.

Para evitar este problema, Android 9 rediseña el esquema de nomenclatura de URL para todos los archivos (no solo APK) para usar nombres de URL predecibles para acceder a listas de artefactos y URL de artefactos. La PAB ahora usa un formato de URL conveniente que permite a los socios descargar recursos; HC guiones pueden descargar los archivos APK de fácil, ya que se conoce el formato de URL, y HC pueden pasar por alto las cuestiones XSRF / galletas, ya que no necesita el buildsvc RPC.

Sistema de archivos local

Dado un directorio con una lista (o archivo zip) de artefactos, el proveedor de compilación establece las imágenes relevantes en función de lo que hay en el directorio. Se puede utilizar el gsutil herramienta para copiar archivos desde Google Cloud Storage en un directorio local.

Construcciones intermitentes

Una vez que se descargan las imágenes más recientes del dispositivo en el host, esas imágenes deben actualizarse en los dispositivos. Esto se hace utilizando los estándares adb y fastboot comandos de Python y subprocesos, basado en las rutas de archivos temporales almacenados por los proveedores de construcción.

Acciones apoyadas:

  • Parpadeando solo el GSI
  • Intermitente imágenes individuales del sistema principal (por ejemplo, fastboot flash boot boot.img )
  • Destellando todas las imágenes del sistema principal. Ejemplo:
    • fastboot flashall (utilizando el incorporado en flashall utilidad)
    • fastboot flash (uno a la vez)

Ejecutando pruebas

En Android 9, la infraestructura de pruebas automatizadas de VTS solo admite el arnés de prueba TradeFed, pero podría ampliarse para admitir otros arneses en el futuro.

Una vez preparados los dispositivos, puede invocar las pruebas mediante una de las siguientes opciones:

  • Cuando se utiliza TradeFed localmente, utilice la test de comandos en el controlador de host, que lleva el nombre de un plan de pruebas VTS (por ejemplo, vts-selftest ) y se ejecuta la prueba.
  • Cuando se utiliza un clúster TradeFed (opcionalmente conectado a MTT), utilizar el lease de comandos en la consola de controlador de host, que se ve para las ejecuciones de prueba no cumplidas.

Si se utiliza TradeFedCluster, TradeFed se ejecuta localmente como gerente a distancia . De lo contrario, las pruebas se invocan mediante subprocesos de Python.

Informe de resultados

Los resultados se informan automáticamente a algunos proyectos salpicadero VTS por VtsMultiDeviceTest .