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 ejecutes el comando repo init, especifica una rama de CTS específica con -b. Esto garantiza que los cambios del CTS se incluyan en las versiones posteriores del CTS.

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

Compila y ejecuta el CTS

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

Compila el 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 el 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 de target-release:

Ejecuta el CTS

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 pruebas de Android. Revisa el tutorial Prueba tu app y las pruebas existentes en el directorio cts/tests. Las pruebas del CTS suelen seguir las mismas convenciones que se usan en otras pruebas de Android.

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

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

Agrega una anotación de Java

Si tu prueba verifica el comportamiento de una API, anota el código de prueba con @ApiTest y enumera todas las APIs involucradas en el campo apis. Usa el formato adecuado entre 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 la prueba del CTS, como se muestra en el siguiente ejemplo. En el mensaje de confirmación, menciona qué requisito del CDD se prueba haciendo referencia a los IDs de los requisitos del CDD. Los IDs de requisitos del CDD son una combinación del ID de 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()));
    }

En el caso de CTS Verifier, anota cada actividad en tu AndroidManifest.xml con el ID de CDD pertinente. Los formatos de los campos de valor son similares a los formatos de las anotaciones de Java en el CTS. En el mensaje de confirmación, menciona qué requisito de la CDD se aplica haciendo referencia al ID del requisito de la 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 relevantes para obtener asistencia. En el caso de las pruebas del CTS-D, incluye un vínculo a la propuesta de prueba que creaste en la herramienta de seguimiento de errores de Google como parte del proceso de envío del CTS-D.

Cómo crear un plan secundario

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 del CTS se dirigen a una clase específica en la API de Android. Estas pruebas tienen nombres de paquetes Java con el sufijo cts y nombres de clases con el sufijo Test. Cada caso de prueba consta de varias pruebas, en las que cada una 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 Java android.widget.TextView es android.widget.cts.TextViewTest con su nombre de paquete 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 del CTS es el nombre del paquete de la clase que se está probando, 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" agregado. Por ejemplo, si una prueba se dirige a TextView, el nombre de la clase debe ser TextViewTest.
• Nombre del módulo (solo para 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

En el caso de Android 6.0 y versiones anteriores, usa CTS v1. En el caso de 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 del 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 muestras

Cuando agregues pruebas nuevas, es posible que no haya un directorio existente para colocar tu prueba. 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 nuevo paquete desde su Android.mk a CTS_COVERAGE_TEST_CASE_LIST en cts/CtsTestCaseList.mk. build/core/tasks/cts.mk usa este archivo make para combinar todas las pruebas y crear el paquete final del CTS.

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 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 "[Ss]ample" por la convención de nomenclatura recomendada que se indicó anteriormente.
3. Actualiza SampleDeviceActivity para probar 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 make Android.mk en él.

Por lo general, el archivo makefile contiene los siguientes parámetros de 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 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))

Cómo corregir o quitar pruebas

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

Envía tus cambios

Sigue el flujo de trabajo de Envío de cambios de código cuando contribuyas con cambios al 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 incluya en la versión interna de Gerrit según corresponda.

Información de las ramas y el programa de lanzamientos

Las versiones de CTS siguen este programa.

Fechas importantes durante el lanzamiento

• Fin de la primera semana: Se congela el código. Los cambios que se fusionen en la rama hasta la congelación del código se tendrán en cuenta para la próxima versión del CTS. Las confirmaciones en la rama después de la congelación del código o después de que se elige un candidato para la versión se consideran para la versión posterior.
• Segunda o tercera semana: El CTS se publica en la página de descargas del Conjunto de pruebas de compatibilidad.

Flujo de combinación automática

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

En el caso de los cambios directos en una rama de desarrollo de prueba del AOSP, la ruta de combinación automática es la siguiente:
android13-tests-dev > android14-tests-dev > android15-tests-dev

• En el caso de las versiones del CTS 16 y posteriores, un revisor seleccionará el cambio para incluirlo en el Gerrit interno según corresponda.

Si una lista de cambios (CL) no se combina correctamente, se le 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 combinación automática del CL en conflicto.

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

En el caso de los cambios de prueba aplicables a la próxima versión de Android, después de que subas un cambio propuesto, Google lo revisará y, si se acepta, lo incluirá en el Gerrit interno.