Desarrollo de CTS

Inicializa tu cliente de Repo

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

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

Compila y ejecuta CTS

Ejecuta los siguientes comandos para compilar CTS y, luego, iniciar la consola interactiva de CTS:

Compila CTS (AOSP 14 o versiones anteriores)

cd /path/to/android/root
source build/envsetup.sh
make cts -j32 TARGET_PRODUCT=aosp_arm64
cts-tradefed

Compila CTS (AOSP 15)

cd /path/to/android/root
source build/envsetup.sh
make cts -j32 TARGET_PRODUCT=aosp_arm64 TARGET_RELEASE=target-release
cts-tradefed

Consulta la siguiente tabla para seleccionar el valor target-release:

Ejecuta CTS

En la consola de CTS, ingresa lo siguiente:

tf> run cts --plan CTS

Escribe pruebas de CTS

Las pruebas de CTS usan JUnit y las APIs de pruebas de Android. Revisa el instructivo Prueba tu app y las pruebas existentes en el directorio cts/tests. Las pruebas de CTS siguen, en su mayoría, las mismas convenciones que se usan en otras pruebas de Android.

CTS se ejecuta en muchos dispositivos de producción, por lo que las pruebas deben seguir estas reglas:

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

Agrega una anotación de Java

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

Si tu prueba verifica un requisito del CDD, anota el ID del requisito (incluidos el ID de la sección del CDD y el ID del requisito) con @CddTest en el código de prueba de CTS, como se muestra en el siguiente ejemplo. En el mensaje de confirmación, menciona qué requisito del CDD prueba tu prueba haciendo referencia a los IDs de los requisitos del CDD. Los IDs de los requisitos del CDD son una combinación del ID de la sección y el ID del 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 de CTS, anota cada actividad en tu AndroidManifest.xml con el ID del CDD pertinente. Los formatos para los campos de valor son similares a los formatos de las anotaciones de Java en CTS. En el mensaje de confirmación, menciona qué requisito del CDD se aplica haciendo referencia al ID del requisito del CDD.

  <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é se debe agregar tu prueba y agrega vínculos pertinentes para obtener asistencia. Para las pruebas de CTS-D, incluye un vínculo a la propuesta de prueba que creaste en Google Issue Tracker como parte del 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, haz lo siguiente:

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 clase con un sufijo Test. Cada caso de prueba consta de varias pruebas, en las que cada prueba suele ejercitar un método específico de la clase que se está probando. Estas pruebas se organizan en una estructura de directorios en la que se agrupan en diferentes categorías, como "widgets" o "vistas".

Por ejemplo, la prueba de CTS para el paquete de Java android.widget.TextView es android.widget.cts.TextViewTest con su 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 está probando la prueba, seguido de .cts. En nuestro ejemplo, el nombre del paquete sería android.widget.cts.
• Nombre de la clase
  El nombre de la clase para las pruebas de CTS es el nombre de la clase que se está probando con "Test" anexado. Por ejemplo, si una prueba se orienta a TextView, el nombre de la clase debe ser TextViewTest.
• Nombre del módulo (solo CTS v2)
  CTS v2 organiza las pruebas por módulo. El nombre del módulo suele ser la segunda cadena del nombre del paquete de Java (en nuestro ejemplo, widget).

La estructura de directorios 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 detalles, consulta la 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 colocarlas. En esos casos, debes crear el directorio y copiar los 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 del módulo de tu paquete nuevo desde su Android.mk a CTS_COVERAGE_TEST_CASE_LIST en 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

Usa 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 archivos de muestra, ejecuta lo siguiente:

   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 "[Ss]ample" con la convención de nombres recomendada que se indicó anteriormente.
3. Actualiza SampleDeviceActivity para ejercitar la función que estás probando.
4. Actualiza SampleDeviceTest para asegurarte de que la actividad se realice correctamente o registre sus errores.

Directorios adicionales

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

Por lo general, el archivo 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)

Android.mk

Por último, modifica el archivo Android.mk en la raíz del proyecto 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))

Corrige o quita pruebas

Además de agregar pruebas nuevas, puedes corregir o quitar pruebas anotadas con BrokenTest o KnownFailure.

Enviar cambios

Sigue el flujo de trabajo Envío de cambios de código cuando contribuyas con cambios a CTS.

• Elige la rama de desarrollo según los niveles de API a los que se aplica el parche.
• Desarrolla o selecciona los cambios para la rama de prueba correcta con DO NOT MERGE o RESTRICT AUTOMERGE en el mensaje de confirmación.

Se asigna un revisor para que revise tu cambio y lo seleccione en el Gerrit interno según corresponda.

Programa de lanzamientos e información de las ramas

Los lanzamientos de CTS siguen este programa.

Fechas importantes durante el lanzamiento

• Fin de la primera semana: Congelamiento de código. Los cambios fusionados en la rama hasta el congelamiento de código se consideran para la próxima versión de CTS. Los envíos a la rama después del congelamiento de código o después de que se elija un candidato para el lanzamiento se consideran para el lanzamiento posterior.
• Segunda o tercera semana: CTS se publica en la página de descargas del Conjunto de pruebas de compatibilidad.

Flujo de fusión automática

Las ramas de desarrollo de CTS se configuraron de modo que los cambios enviados a cada rama se fusionen automáticamente con las ramas superiores.

Para los cambios directamente en una rama de desarrollo de prueba de AOSP, la ruta de fusión automática es la siguiente:
android13-tests-dev > android14-tests-dev > android15-tests-dev

• Para las versiones de CTS 16+, un revisor seleccionará el cambio en el Gerrit interno según corresponda.

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

Si una rama anterior requiere el cambio, se debe seleccionar el parche de la rama más reciente.

Para los cambios de prueba aplicables a la próxima versión de Android, después de subir un cambio propuesto, Google lo revisa y, si se acepta, lo seleccionará en el Gerrit interno.