Desarrollo del CTS

Cómo inicializar 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 en CTS se incluyan en versiones posteriores de CTS.

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

Cómo compilar y ejecutar CTS

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

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 o versiones posteriores)

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:

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 Cómo probar 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 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 de administrador.

Agrega una anotación de Java

Si la 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 prueba del CTS, como se muestra en el siguiente ejemplo. En el mensaje de confirmación, menciona qué requisito de la CDD se prueba con tu prueba haciendo referencia a los IDs de los requisitos de la 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()));
    }

Para CTS Verifier, anota cada actividad en tu AndroidManifest.xml con el ID de CDD relevante. Los formatos de 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 de CDD se aplica haciendo referencia al ID de requisito de 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 la prueba y agrega vínculos relevantes para obtener asistencia. Para las pruebas de 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 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 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 una suele ejecutar 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 el nombre de paquete Java como android.widget.cts y el 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 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 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 del directorio 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. 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 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 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 de 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 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 los 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 sustituye todas las instancias de "[Ss]ample" por 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 de configuración 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)

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))

Corrige o quita pruebas

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

Envía tus cambios

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

• Para los cambios que se aplican a varios niveles de API, primero desarrolla un parche en aosp/main y, luego, selecciona la rama de prueba más upstream. Permite que la combinación automática combine los cambios en las ramas de prueba de AOSP. Consulta Información de las ramas y el programa de lanzamientos para obtener la lista de ramas y la información de la ruta de combinación automática.
• Para los cambios específicos de un nivel de API específico, desarrolla o elige los cambios en la rama de prueba correcta con DO NOT MERGE o RESTRICT AUTOMERGE en el mensaje de confirmación.

Sigue el flujo de trabajo para enviar parches para realizar contribuciones de cambios en CTS. Se asignará un revisor para que revise tu cambio 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 fusionan en la rama hasta la inmovilización del código se consideran para la próxima versión de CTS. Los envíos a la rama después de la inmovilizació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: CTS se publica en AOSP.

Flujo de combinación automática

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

Para los cambios directamente en una rama de dev de prueba de AOSP, la ruta de combinación automática es:
android11-tests-dev > android12-tests-dev > android12L-tests-dev > android13-tests-dev > android14-tests-dev > android15-tests-dev > aosp-main

Para los cambios solo en la siguiente versión de Android, la ruta de combinación automática es:
aosp-main > <Internal git_main>.

Si una lista de cambios (CL) no se fusiona 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 de la CL en conflicto.

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