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

Infraestructura de pruebas automatizadas

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

Arquitectura

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

Automated test architecture

Figura 1. Arquitectura de infraestructura de pruebas automatizadas VTS

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

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

El proceso está 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 compilaciones, actualizarlas en los dispositivos e invocar pruebas (ya sea localmente o a través del 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 obtener detalles sobre el controlador de host, consulte Arquitectura del controlador de host.

Proveedores de recursos

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

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

  • Compilación de Android para socios . Acceso programático otorgado por cuenta.
  • Sistema de archivos local (o similar). Para socios que no usan la compilación de Android para socios.

Para usar en la actualización de los dispositivos más adelante, los recursos incluyen proveedores de compilación para ambas opciones, que se extienden desde un solo build_provider.py que almacena las compilaciones en directorios temporales locales.

Compilación de Android para socios

En Android 8.1 y versiones anteriores, los socios de Android debían visitar el sitio web de Partner Android Build ( https://partner.android.com/build ), navegar a su cuenta y obtener las últimas 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.

Establecimiento de acceso

El acceso mediante programación utiliza OAuth2 en las API de Google para acceder a las RPC requeridas. Usando el enfoque estándar para generar credenciales de OAuth2, el socio debe configurar un par de ID de cliente/secreto con Google. Cuando se apunta a PartnerAndroidBuildClient a ese secreto por primera vez, abre una ventana del navegador para que el usuario inicie sesión en su cuenta de Google, lo que genera las credenciales OAuth2 necesarias 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.

POST solicitud de URL

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

  • ID de compilación, objetivo de compilación
  • nombre del recurso
  • rama
  • nombre del candidato de lanzamiento y si el candidato es o no una compilación interna

La solicitud POST la recibe el método downloadBuildArtifact del RPC buildsvc , que devuelve una URL que se puede usar 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 es accesible con las credenciales OAuth2 correspondientes).
  • 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).

Obtener la URL

Para evitar la falsificación de solicitudes entre sitios, el RPC de buildsvc requiere que se publique un token XSRF con los otros parámetros. Si bien este token hace que el proceso sea más seguro, también hace que el acceso programático sea mucho más difícil, ya que ahora también se requiere el token (que está disponible solo en el JavaScript de la página PAB) para el acceso.

Para evitar este problema, Android 9 rediseña el esquema de nombres de URL para todos los archivos (no solo los APK) para usar nombres de URL predecibles para acceder a listas de artefactos y URL de artefactos. El PAB ahora usa un formato de URL conveniente que permite a los socios descargar recursos; Los scripts de HC pueden descargar esos APK fácilmente, ya que se conoce el formato de URL, y HC puede evitar los problemas de XSRF/cookie porque no necesita el RPC de buildsvc .

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. Puede usar la herramienta gsutil para copiar archivos de Google Cloud Storage a un directorio local.

Construcciones intermitentes

Después de que las imágenes más recientes del dispositivo se descargan al host, esas imágenes deben mostrarse en los dispositivos. Esto se hace mediante los comandos adb y fastboot estándar y los subprocesos de Python, en función de las rutas de archivos temporales almacenadas por los proveedores de compilación.

Acciones admitidas:

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

Ejecutando pruebas

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

Después de que los dispositivos estén preparados, puede invocar pruebas usando una de las siguientes opciones:

  • Cuando use TradeFed localmente, use el comando de test en el controlador del host, que toma el nombre de un plan de prueba de VTS (p. ej vts-selftest ) y ejecuta la prueba.
  • Cuando use un clúster TradeFed (opcionalmente conectado a MTT), use el comando de lease en la consola del controlador del host, que busca ejecuciones de prueba no completadas.

Si usa TradeFedCluster, TradeFed se ejecuta localmente como un administrador remoto . De lo contrario, las pruebas se invocan mediante subprocesos de Python.

Informe de resultados

VtsMultiDeviceTest informa automáticamente los resultados de las pruebas a algunos proyectos de panel de VtsMultiDeviceTest .