Pruebas de plataforma Android

AOSP proporciona varias herramientas y conjuntos de pruebas para probar varias partes de su implementación. Antes de continuar con esta sección, debes estar familiarizado con los siguientes términos:

Dispositivo compatible con Android
Un dispositivo que puede ejecutar cualquier aplicación de terceros escrita por desarrolladores externos utilizando el SDK y el NDK de Android. Los dispositivos compatibles con Android deben cumplir con los requisitos del Documento de definición de compatibilidad (CDD) y pasar el Conjunto de pruebas de compatibilidad (CTS) . Los dispositivos compatibles con Android son elegibles para participar en el ecosistema de Android, que incluye una posible licencia de Google Play Store, una posible licencia del conjunto de aplicaciones y API de Google Mobile Services (GMS) y el uso de la marca registrada Android. Cualquiera puede utilizar el código fuente de Android, pero para ser considerado parte del ecosistema de Android, un dispositivo debe ser compatible con Android.
artefacto
Los artefactos son registros relacionados con la compilación que permiten la resolución de problemas locales.
Documento de definición de compatibilidad (CDD)
Un documento que enumera los requisitos de software y hardware para un dispositivo compatible con Android.
Conjunto de pruebas de compatibilidad (CTS)

Un conjunto de pruebas gratuito de calidad comercial, disponible para descargar como binario o como fuente en AOSP. El CTS es un conjunto de pruebas unitarias diseñadas para integrarse en su flujo de trabajo diario. La intención de CTS es revelar incompatibilidades y garantizar que el software siga siendo compatible durante todo el proceso de desarrollo.

Las pruebas CTS y de plataforma no son mutuamente excluyentes. Aquí hay algunas pautas generales:

  • Si una prueba afirma la exactitud de las funciones o comportamientos de la API del marco y debe aplicarse a todos los socios OEM, debe realizarse en CTS.
  • Si una prueba está destinada a detectar regresiones durante el desarrollo de la plataforma y puede requerir permiso privilegiado para llevarse a cabo y puede depender de los detalles de implementación (como se publica en AOSP), debe ser una prueba de plataforma.
Servicios móviles de Google (GMS)

Una colección de aplicaciones y API de Google que se pueden preinstalar en los dispositivos.

Prueba de Google (GTest)

GTest es un marco de pruebas y burlas de C++. Los binarios de GTest generalmente acceden a capas de abstracción de nivel inferior o realizan IPC sin procesar en varios servicios del sistema. El enfoque de prueba de GTest suele estar estrechamente relacionado con el servicio que se está probando. CTS contiene el marco GTest.

prueba de instrumentación

Una prueba de instrumentación proporciona un entorno de ejecución de prueba especial iniciado por el comando am instrument , donde el proceso de aplicación objetivo se reinicia e inicializa con el contexto básico de la aplicación, y se inicia un subproceso de instrumentación dentro de la máquina virtual del proceso de aplicación. CTS contiene pruebas de instrumentación.

logcat

Logcat es una herramienta de línea de comandos que crea un registro de mensajes del sistema, incluidos seguimientos de pila de cuando el dispositivo arroja un error y mensajes que usted ha escrito desde su aplicación con la clase Log .

Inicio sesión

El registro se refiere al uso de un registro para realizar un seguimiento de los eventos del sistema informático, como los errores. Iniciar sesión en Android es complejo debido a la combinación de estándares utilizados que se combinan en la herramienta Logcat.

prueba posterior al envío

Las pruebas posteriores al envío de Android se realizan cuando se envía un nuevo parche a una rama común del kernel. Al ingresar aosp_kernel como nombre de rama parcial, puede ver una lista de ramas del kernel con resultados disponibles. Por ejemplo, los resultados de android-mainline se pueden encontrar en https://ci.android.com/builds/branches/aosp_kernel-common-android-mainline/grid .

prueba previa al envío

Las pruebas previas al envío se utilizan para evitar que se introduzcan fallas en los núcleos comunes.

Federación de Comercio

Trade Federation, también llamada Tradefed, es un marco de prueba continuo diseñado para ejecutar pruebas en dispositivos Android. Por ejemplo, Tradefed se utiliza para ejecutar pruebas de Compatibility Test Suite y Vendor Test Suite.

Conjunto de pruebas de proveedores (VTS)

Android Vendor Test Suite (VTS) proporciona amplias capacidades para pruebas de Android, promueve un proceso de desarrollo basado en pruebas y automatiza las pruebas del kernel HAL y OS.

Tipos de prueba de plataforma

Una prueba de plataforma generalmente interactúa con uno o más de los servicios del sistema Android o capas de capa de abstracción de hardware (HAL), ejercita las funcionalidades del sujeto bajo prueba y afirma la exactitud del resultado de la prueba. Una prueba de plataforma podría:

  • (tipo 1) API del marco de ejercicio utilizando el marco de Android. Las API específicas que se ejercen pueden incluir:
    • API públicas destinadas a aplicaciones de terceros
    • API ocultas destinadas a aplicaciones privilegiadas, es decir, API del sistema o API privadas ( @hide , or protected , paquete privado`)
  • (tipo 2) Invoque los servicios del sistema Android utilizando un enlazador sin formato o servidores proxy IPC directamente.
  • (tipo 3) Interactuar directamente con HAL utilizando API de bajo nivel o interfaces IPC.

Las pruebas de tipo 1 y 2 suelen ser pruebas de instrumentación, mientras que las pruebas de tipo 3 suelen ser pruebas GT.

¿Que sigue?

A continuación se muestra una lista de los próximos documentos que podría leer: