desarrollo de CTS

Inicialice su cliente Repo

Siga las instrucciones de Descarga del código fuente para obtener y compilar el código fuente de Android. Al emitir el comando repo init , especifique una rama CTS específica usando -b . Esto garantiza que sus cambios de CTS se incluyan en versiones posteriores de CTS.

El siguiente código de ejemplo muestra cómo utilizar repo init .

Construir y ejecutar CTS

Ejecute los siguientes comandos para compilar CTS e iniciar la consola CTS interactiva:

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

En la consola CTS, ingrese:

tf> run cts --plan CTS

Escribir pruebas CTS

Las pruebas CTS utilizan JUnit y las API de prueba de Android. Revise el tutorial Pruebe su aplicación y las pruebas existentes en el directorio cts/tests . Las pruebas CTS siguen en su mayoría las mismas convenciones utilizadas en otras pruebas de Android.

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

• Tenga en cuenta los distintos tamaños de pantalla, orientaciones y distribuciones de teclado.
• Utilice únicamente métodos API públicos. En otras palabras, evite todas las clases, métodos y campos con la anotación hide .
• Evite utilizar diseños de vista o confiar en las dimensiones de los recursos que pueden no estar en algunos dispositivos.
• No confíe en los privilegios de root.

Agregar anotación Java

Si su prueba verifica el comportamiento de una API, anote su código de prueba con @ApiTest y enumere todas las API involucradas en el campo apis . Utilice el formato apropiado de entre los siguientes ejemplos:

Si su prueba verifica un requisito de CDD, anote el ID del requisito (incluido el ID de la sección CDD y el ID del requisito) con @CddTest en el código de prueba CTS como se muestra en el siguiente ejemplo. En su mensaje de confirmación, mencione qué requisito de CDD se prueba en su prueba haciendo referencia a los ID de requisitos de CDD. Los ID de requisitos de CDD son una combinación de ID de sección e 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, anote cada actividad en su AndroidManifest.xml con el ID de CDD correspondiente. 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, mencione qué requisito de CDD se aplica haciendo referencia al ID del 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

Mencione claramente por qué es necesario agregar su prueba y agregue enlaces relevantes para obtener soporte. Para las pruebas CTS-D, incluya un enlace a la propuesta de prueba que creó en Google Issue Tracker como parte del proceso de envío de CTS-D .

Crear un subplan

Como ejemplo, puede 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:

run cts --subplan aSubPlan

El formato de entrada del subplan es:

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 apuntan 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, donde cada prueba normalmente ejercita un método específico de la clase que se está probando. Estas pruebas están organizadas en una estructura de directorio donde las pruebas se agrupan en diferentes categorías, como "widgets" o "vistas".

Por ejemplo, la prueba 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 Java
  El nombre del paquete Java para las pruebas CTS es el nombre del paquete de la clase que la prueba está probando, seguido de .cts . Para nuestro ejemplo, el nombre del paquete sería android.widget.cts .
• Nombre de la clase
  El nombre de clase para las pruebas CTS es el nombre de la clase que se está probando con "Prueba" añadido. Por ejemplo, si una prueba tiene como objetivo 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 Java (en nuestro ejemplo, widget ).

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

CTS v1

Para Android 6.0 o inferior, utilice CTS v1. Para CTS v1, el código de muestra está en cts/tests/tests/example .

La estructura de directorios en las pruebas CTS v1 se ve así:

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

CTSv2

Para Android 7.0 o superior, utilice CTS v2. Para obtener más información, consulte la prueba de muestra en Android Open Source Project (AOSP) .

La estructura del directorio CTS v2 tiene este aspecto:

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

Nuevos paquetes de muestra

Al agregar nuevas pruebas, es posible que no haya un directorio existente para colocar su prueba. En esos casos, debe crear el directorio y copiar los archivos de muestra adecuados.

CTS v1

Si está utilizando CTS v1, consulte el ejemplo en cts/tests/tests/example y cree un nuevo directorio. Además, asegúrese de agregar el nombre del módulo de su nuevo paquete desde 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 CTS final.

CTSv2

Utilice la prueba de muestra /cts/tests/sample/ para iniciar rápidamente su nuevo módulo de prueba con los siguientes pasos:

1. Para crear el directorio de prueba y copiar archivos de muestra, ejecute:

   mkdir cts/tests/module-name && cp -r cts/tests/sample/* cts/tests/module-name

2. Navegue hasta cts/tests/ module-name y sustituya todas las instancias de "[Ss]ample" con la convención de nomenclatura recomendada anteriormente.
3. Actualice SampleDeviceActivity para ejercitar la función que está probando.
4. Actualice SampleDeviceTest para asegurarse 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, cree un directorio en la raíz del proyecto junto a src con el código nativo y un archivo MAKE Android.mk en él.

El archivo MAKE normalmente contiene las siguientes configuraciones:

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

Finalmente, modifique el archivo Android.mk en la raíz del proyecto para construir 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))

Corregir o eliminar pruebas

Además de agregar nuevas pruebas, puede corregir o eliminar pruebas anotadas con BrokenTest o KnownFailure .

Envía tus cambios

Al enviar parches CTS o VTS en AOSP, elija su rama de desarrollo según los niveles de API a los que se aplica el parche.

• Para los cambios que se aplican a múltiples niveles de API, primero desarrolle un parche en aosp/main y luego seleccione la rama de prueba más ascendente . Permita que la fusión automática combine los cambios posteriores en las ramas de prueba de AOSP. Consulte Programación de lanzamiento e información de sucursales para obtener la lista de sucursales y la información de la ruta de fusión automática.
• Para cambios que son específicos de un nivel de API específico, desarrolle o seleccione los cambios en la rama de prueba correcta con NO MERGE o RESTRICT AUTOMERGE en el mensaje de confirmación.

Siga el flujo de trabajo Envío de parches para contribuir con cambios a CTS. Se asignará un revisor para revisar su cambio en consecuencia.

Calendario de lanzamientos e información de sucursales.

Los lanzamientos de CTS siguen este cronograma.

Fechas importantes durante el lanzamiento.

• Fin de la primera semana: congelación del código. Los cambios fusionados en la rama hasta la congelación del código se consideran para la próxima versión de CTS. Los envíos a la sucursal después de la congelación del código, o después de que se elige un candidato para la publicación, se consideran para la publicación posterior.
• Segunda o tercera semana: CTS se publica en AOSP .

Flujo de fusión automática

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

Para cambios directamente en una rama de desarrollo de pruebas de AOSP, la ruta de fusión automática es:
android11-tests-dev > android12-tests-dev > android12L-tests-dev > android13-tests-dev > android14-tests-dev > aosp/main

Para cambios únicamente a la siguiente versión de Android, la ruta de fusión automática es:
aosp/main > <Internal git/main> .

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

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