Desarrollo del CTS

Cómo inicializar tu cliente de Repo

Sigue las instrucciones del artículo Cómo descargar la fuente para obtener y compila el código fuente de Android. Cuando emitas el comando repo init, especifica una rama específica del CTS con -b. Esto garantiza que se incluyan los cambios del CTS en versiones posteriores de CTS.

En el siguiente código de ejemplo, se muestra cómo usar repo init.

mkdir android11-tests-dev && cd android11-tests-dev && repo init -c -u https://android.googlesource.com/platform/manifest -b android11-tests-dev --use-superproject --partial-clone --partial-clone-exclude=platform/frameworks/base --clone-filter=blob:limit=10M && repo sync -c -j8

Compila y ejecuta el CTS

Ejecuta los siguientes comandos para compilar el CTS e iniciar la interfaz Consola de CTS:

cd /path/to/android/root
make cts -j32 TARGET_PRODUCT=aosp_arm64
cts-tradefed

En la consola de CTS, ingresa lo siguiente:

tf> run cts --plan CTS

Cómo escribir pruebas de CTS

Las pruebas de CTS usan JUnit y las APIs de prueba de Android. Revisa el Prueba tu app y las pruebas existentes en el directorio cts/tests. En general, las pruebas de CTS siguen las mismas convenciones que se usan en otras pruebas de Android.

El CTS se ejecuta en muchos dispositivos de producción, por lo que las pruebas deben cumplir con los siguientes requisitos: estas reglas:

  • Ten en cuenta los diferentes tamaños de pantalla, orientaciones y diseños del teclado.
  • Usar solo métodos de API públicas En otras palabras, evita todas las clases, métodos y campos con la anotación hide.
  • Evita usar diseños de vista o depender de las dimensiones de los recursos que pueden no estar en algunos dispositivos.
  • No dependas de los privilegios raíz.

Agrega la anotación de Java

Si la prueba verifica el comportamiento de una API, anota el código de prueba con @ApiTest y agrega una lista. todas las APIs involucradas en el campo apis. Usa el formato adecuado entre los siguientes ejemplos:

Tipo de API Formato de anotación Notas
Método android.example.ClassA#methodA El caso de uso más común.
Método con pares clave-valor android.example.ClassB#methodB(KeyA) Úsalo solo cuando la prueba use un método de API para validar un campo, como en este ejemplo.
Campo android.ejemplo.ClaseC#CampoA Úsalo solo cuando la prueba valide directamente un campo de API, como en este ejemplo.

Si la prueba verifica un requisito de CDD, anota el ID del requisito (incluida la sección del CDD). ID de requisito) con @CddTest en el código de prueba de CTS, como se muestra en el siguiente ejemplo. En tu mensaje de confirmación, menciona qué requisito de CDD prueba tu consulta los IDs de requisitos de CDD. Los ID de requisitos del CDD son una combinación del ID de la sección y el ID de requisito, conectados por una barra (/), como en 7.3.1/C-1-1. 


/**
* Verify Passpoint configuration management APIs for a Passpoint
* @throws Exception
*/
    @CddTest(requirement="7.4.2.3/C-1-1,C-2-1")
    public void testAddPasspointConfigWithUserCredential() throws Exception {
        if (!WifiFeature.isWifiSupported(getContext())) {
            // skip the test if WiFi is not supported
            return;
        }      testAddPasspointConfig(generatePasspointConfig(generateUserCredential()));
    }

Para el verificador del CTS, debes anotar cada actividad en tu AndroidManifest.xml con el el ID del CDD correspondiente. Los formatos para los campos de valor son similares a los formatos de las anotaciones Java en del CTS En el mensaje de confirmación, menciona qué requisito de CDD se aplica haciendo referencia al CDD. el ID de requisito. 


  <activity>
    ......
    <!-- OPTIONAL: Add a meta data attribute to indicate CDD requirements. -->
    <meta-data android:name="cdd_test" android:value="7.4.1/C-4-1" />

    <!-- OPTIONAL: Add a meta data attribute to indicate APIs being tested. -->
    <meta-data android:name="api_test"
               android:value="com.example.MyClass#myMethod" />

    <!-- OPTIONAL: Add a metadata attribute to indicate the reason why the test doesn't enforce any CDD requirement but still useful in CTS-V. -->
    <meta-data android:name="non_compliance_test"
               android:value="detailed reasons" />
  </activity>

En el mensaje de confirmación

Menciona claramente por qué debes agregar la prueba y agrega vínculos relevantes para obtener asistencia. Para CTS-D pruebas, incluyen un vínculo a la propuesta de prueba que creaste en la Herramienta de seguimiento de errores de Google como parte de el proceso de envío de CTS-D.

Crea un subplan

Por ejemplo, puedes agregar un archivo SubPlan.xml en android-cts/subplans de la siguiente manera:

<?xml version="1.0" encoding="utf-8" standalone="no"?>
<SubPlan version="2.0">
<Entry include="CtsSystemIntentTestCases" />
<Entry include="CtsSystemUiHostTestCases" />
<Entry include="CtsSecurityHostTestCases android.security.cts.SELinuxHostTest#testAospFileContexts" />
<Entry include="CtsSecurityHostTestCases android.security.cts.SELinuxHostTest#testAospServiceContexts" />
</SubPlan>

Para ejecutar el subplan, sigue estos pasos:

run cts --subplan aSubPlan

El formato de entrada del subplan es el siguiente:

Include a module name as follows:
<Entry include="MODULE_NAME" />

Include a package:
<Entry include="MODULE_NAME PACKAGE_NAME" />

Include a class:
<Entry include="MODULE_NAME PACKAGE_NAME.CLASS_NAME" />

Include an individual test:
<Entry include="MODULE_NAME PACKAGE_NAME.CLASS_NAME#TEST_NAME" />

Nombre y ubicación de la prueba

La mayoría de los casos de prueba de CTS se orientan a una clase específica en la API de Android. Estas pruebas tienen nombres de paquetes de Java con un sufijo cts y nombres de clases con un Sufijo Test. Cada caso de prueba consta de varias pruebas, en las que cada prueba generalmente usa un método específico de la clase que se está probando. Estas pruebas se organizan en una estructura de directorios en la que las pruebas se agrupan en categorías diferentes, como "widgets" o "vistas".

Por ejemplo, la prueba de CTS para el paquete de Java android.widget.TextView es android.widget.cts.TextViewTest por el nombre de paquete de Java como android.widget.cts y su nombre de clase como TextViewTest

  • Nombre del paquete de Java
    El nombre del paquete de Java para las pruebas de CTS es el nombre del paquete de la clase que la prueba está probando, seguido del .cts Para nuestro ejemplo, el nombre del paquete sería android.widget.cts
  • Nombre de la clase
    El nombre de la clase para las pruebas del CTS es el nombre de la clase que se está probando con "Test" se anexan. Para Por ejemplo, si una prueba se orienta a TextView, el nombre de la clase debe ser el siguiente: TextViewTest
  • Nombre del módulo (solo CTS v2)
    CTS v2 organiza las pruebas por módulo. El nombre del módulo es generalmente la segunda cadena del nombre del paquete de Java (en nuestra por ejemplo, widget).

La estructura del directorio y el código de muestra dependen de si usas CTS v1 o CTS v2.

CTS v1

Para Android 6.0 o versiones anteriores, usa CTS v1. Para CTS v1, el código de muestra se encuentra en cts/tests/tests/example

La estructura de directorios en las pruebas de CTS v1 se ve de la siguiente manera: 

cts/
  tests/
    tests/
      package-name/
        Android.mk
        AndroidManifest.xml
        src/
          android/
            package-name/
              SampleDeviceActivity.java
              cts/
                SampleDeviceTest.java

CTS v2

Para Android 7.0 o versiones posteriores, usa CTS v2. Para obtener más información, consulta el prueba de muestra en el Proyecto de código abierto de Android (AOSP).

La estructura de directorios de CTS v2 se ve de la siguiente manera: 

cts/
  tests/
    module-name/
      Android.mk
      AndroidManifest.xml
      src/
        android/
          package-name/
            SampleDeviceActivity.java
            cts/
              SampleDeviceTest.java

Nuevos paquetes de muestra

Cuando agregues pruebas nuevas, es posible que no haya un directorio existente para colocar tus la prueba. En esos casos, debes crear el directorio y copiar el archivo archivos de muestra adecuados.

CTS v1

Si usas CTS v1, consulta el ejemplo en cts/tests/tests/example y crea un directorio nuevo. Además, asegúrate de agregar el nombre de módulo de tu paquete nuevo desde su Android.mk. a CTS_COVERAGE_TEST_CASE_LIST in cts/CtsTestCaseList.mk build/core/tasks/cts.mk usa este archivo makefile. para combinar todas las pruebas y crear el paquete de CTS final.

CTS v2

Cómo usar la prueba de muestra /cts/tests/sample/ para iniciar rápidamente tu nuevo módulo de prueba con los siguientes pasos:

  1. Para crear el directorio de prueba y copiar los archivos de muestra, ejecuta el siguiente comando: 
    mkdir cts/tests/module-name && cp -r cts/tests/sample/* cts/tests/module-name
  2. Navega a cts/tests/module-name y reemplaza todas las instancias de "[S]amplio" con el convención de nomenclatura recomendada anterior.
  3. Actualiza SampleDeviceActivity para usar la función que estás probando.
  4. Actualiza SampleDeviceTest para asegurarte de que la actividad se realice correctamente o se registre sus errores.

Directorios adicionales

Otros directorios de Android, como assets, jni, También se pueden agregar libs y res. Para agregar el código JNI, crea un directorio en la raíz del proyecto junto a src con el directorio y un archivo makefile Android.mk.

Por lo general, el makefile contiene la siguiente configuración: 

LOCAL_PATH := $(call my-dir)
include $(CLEAR_VARS)
LOCAL_MODULE := libCtsSample_jni

# don't include this package in any target
LOCAL_MODULE_TAGS := optional
LOCAL_SRC_FILES := list of source code files
LOCAL_C_INCLUDES := $(JNI_H_INCLUDE)

# Tag this module as a cts test artifact
LOCAL_COMPATIBILITY_SUITE := cts
LOCAL_SHARED_LIBRARIES := libnativehelper
LOCAL_SDK_VERSION := current
include $(BUILD_SHARED_LIBRARY)

Archivo Android.mk

Por último, modifica el archivo Android.mk en la raíz de la para compilar el código nativo y depender de él, como se muestra a continuación:

# All tests should include android.test.runner.
LOCAL_JAVA_LIBRARIES := android.test.runner

# Includes the jni code as a shared library
LOCAL_JNI_SHARED_LIBRARIES := libCtsSample_jni

# Include for InstrumentationCtsTestRunner
LOCAL_STATIC_JAVA_LIBRARIES := ctstestrunner...
LOCAL_SDK_VERSION := currentinclude $(BUILD_CTS_PACKAGE)

#Tells make to look in subdirectories for more make files to include
include $(call all-makefiles-under,$(LOCAL_PATH))

Cómo corregir o quitar pruebas

Además de agregar pruebas nuevas, puedes corregir Quita las pruebas con anotaciones BrokenTest o KnownFailure.

Cómo enviar los cambios

Cuando envíes parches de CTS o VTS en el AOSP, elige tu rama de desarrollo según los niveles de API a los que se aplique el parche.

  • En el caso de los cambios que se aplican a varios niveles de API, primero desarrollar un parche en aosp/main y, luego, seleccionar la mayoría de las opciones rama de prueba upstream. Permitir que la combinación automática combine los cambios posteriores Ramas de pruebas del AOSP. Consulta El programa de lanzamientos y la información de las ramas para la lista de ramas y autocombinar información de rutas de acceso.
  • Para los cambios específicos de un nivel de API específico, realiza el desarrollo o una selección exclusiva. los cambios en la rama de prueba correcta con DO NOT MERGE RESTRICT AUTOMERGE en el mensaje de confirmación

Sigue el flujo de trabajo para enviar parches. para contribuir con cambios al CTS. Se asignará un revisor para revisar tu cambio según corresponda.

Información de las ramas y el programa de lanzamientos

Las versiones de CTS siguen este programa.

Versión Nivel de API Branch Frecuencia
15 35 pruebas-android15 Trimestral
14 34 pruebas-android14 Trimestral
13 33 pruebas-android13 Trimestral
12L 32 Pruebas-de-android12L Trimestral
12 31 pruebas-android12 Trimestral

Fechas importantes durante el lanzamiento

  • Fin de la primera semana: Se bloquea el código. Cambios combinados en la rama hasta que se considere que el código queda inmovilizado para la próxima versión del CTS. Los envíos a la rama después de que se congela el código o después de un candidato versión original, se consideran para la versión posterior.
  • Segunda o tercera semana: El CTS se publica en AOSP.

Combinar flujo

Se configuraron ramas de desarrollo de CTS para que los cambios enviados a cada se fusionará automáticamente con las ramas superiores.

En el caso de los cambios directos en una rama de desarrollo de pruebas de AOSP, la ruta de acceso de autocombinación es la siguiente:
android11-tests-dev > android12-tests-dev android12L-tests-dev > android13-tests-dev > android14-tests-dev > android15-tests-dev > aosp-main

En el caso de los cambios realizados solo en la próxima versión de Android, la ruta de acceso de autocombinación es la siguiente:
aosp-main > <Internal git_main>

Si una lista de cambios (CL) no se combina de forma correcta, se envía el autor del parche. un correo electrónico con instrucciones para resolver el conflicto. En la mayoría de las casos, el autor del parche puede usar las instrucciones para omitir la combinación automática de la CL en conflicto.

Si una rama antigua requiere el cambio, entonces el parche debe cerezas de la rama más nueva.