Desarrollo CTS

Inicializando tu cliente Repo

Siga las instrucciones de Descarga de la 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 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

Construyendo y ejecutando 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 de CTS usan 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 de CTS en su mayoría siguen 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:

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

Agregar anotación de 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 . Use el formato apropiado de 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 valores clave android.example.ClassB#methodB(KeyA) Úselo solo cuando su prueba use un método API para validar un campo, como en este ejemplo.
Campo android.ejemplo.ClassC#FieldA Úselo solo cuando su prueba valide un campo API directamente, como en este ejemplo.

Si su prueba verifica un requisito de CDD, anote el ID del requisito (incluido el ID de la sección de 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 prueba su prueba haciendo referencia a los ID de requisitos de CDD. Los ID de requisito de CDD son una combinación de ID de sección e ID de requisito, conectados por una barra inclinada (/) 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 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 tienen como objetivo 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 suele ejercer un método específico de la clase que se está probando. Estas pruebas se organizan 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 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 Java
    El nombre del paquete de Java para las pruebas CTS es el nombre del paquete de la clase que está probando la prueba, seguido de .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 CTS es el nombre de la clase que se está probando con "Prueba" adjunto. Por ejemplo, si una prueba apunta 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 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, use CTS v1. Para CTS v1, el código de muestra está en cts/tests/tests/example .

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

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 superior, use CTS v2. Para obtener más información, consulte la prueba de muestra en Android Open Source Project (AOSP) .

La estructura de directorios de CTS v2 se ve así:

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 apropiados.

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 de 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.

CTS v2

Use 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 a cts/tests/ module-name y sustituya todas las instancias de "[Ss]ample" con la convención de nomenclatura recomendada de arriba.
  3. Actualice SampleDeviceActivity para ejercitar la característica 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 de Android.mk .

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

Corrección o eliminación de pruebas

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

Enviando sus cambios

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

  • Para los cambios que se aplican a varios niveles de API, primero desarrolle un parche en aosp/master y luego seleccione la rama de prueba más avanzada. Permita que la fusión automática combine los cambios aguas abajo en las ramas de prueba de AOSP. Consulte Programación de lanzamiento e información de sucursales para ver la lista de sucursales y la información de la ruta de combinación automática.
  • Para los 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 RESTRINGIR AUTOMERGE en el mensaje de confirmación.

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

Horario de lanzamiento e información de la sucursal

Los lanzamientos de CTS siguen este calendario.

Versión nivel de API Rama Frecuencia
12L 32 Android12L-pruebas-dev Trimestral
12 31 android12-tests-dev Trimestral
11 30 android11-pruebas-dev Trimestral
10 29 android10-tests-dev Trimestral
No se planean más lanzamientos para las versiones 9.0, 8.1, 8.0, 7.1, 7.0, 6.0, 5.1, 5.0, 4.4, 4.3 y 4.2.

Fechas importantes durante el lanzamiento

  • Fin de la primera semana: congelación de código. Los cambios combinados en la rama hasta que se congele el 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 elija un candidato para el lanzamiento, se consideran para el lanzamiento posterior.
  • Segunda o tercera semana: CTS se publica en AOSP .

Flujo de combinación automática

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

Para cambios directamente a una rama AOSP, la ruta de combinación automática es:
pie-cts-dev > android10-tests-dev > android11-tests-dev > android12-tests-dev > android12L-tests-dev > aosp/master

Para los cambios a una próxima versión de Android, la ruta de combinación automática es:
aosp/master > <private-development-branch for Android T (AOSP experimental)> .

Si una lista de cambios (CL) no se fusiona correctamente, se envía un correo electrónico al autor del parche 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 de la CL en conflicto.

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

,

Inicializando tu cliente Repo

Siga las instrucciones de Descarga de la 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 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

Construyendo y ejecutando 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 de CTS usan 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 de CTS en su mayoría siguen 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:

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

Agregar anotación de 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 . Use el formato apropiado de 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 valores clave android.example.ClassB#methodB(KeyA) Úselo solo cuando su prueba use un método API para validar un campo, como en este ejemplo.
Campo android.ejemplo.ClassC#FieldA Úselo solo cuando su prueba valide un campo API directamente, como en este ejemplo.

Si su prueba verifica un requisito de CDD, anote el ID del requisito (incluido el ID de la sección de 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 prueba su prueba haciendo referencia a los ID de requisitos de CDD. Los ID de requisito de CDD son una combinación de ID de sección e ID de requisito, conectados por una barra inclinada (/) 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 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 tienen como objetivo una clase específica en la API de Android. Estas pruebas tienen nombres de paquetes Java con un sufijo cts y nombres de clase con un sufijo Test . Cada caso de prueba consta de varias pruebas, donde cada prueba suele ejercer un método específico de la clase que se está probando. Estas pruebas se organizan 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 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 Java
    El nombre del paquete de Java para las pruebas CTS es el nombre del paquete de la clase que está probando la prueba, seguido de .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 CTS es el nombre de la clase que se está probando con "Prueba" adjunto. Por ejemplo, si una prueba apunta 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 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, use CTS v1. Para CTS v1, el código de muestra está en cts/tests/tests/example .

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

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 superior, use CTS v2. Para obtener más información, consulte la prueba de muestra en Android Open Source Project (AOSP) .

La estructura de directorios de CTS v2 se ve así:

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 apropiados.

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 de 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.

CTS v2

Use 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 a cts/tests/ module-name y sustituya todas las instancias de "[Ss]ample" con la convención de nomenclatura recomendada de arriba.
  3. Actualice SampleDeviceActivity para ejercitar la característica 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 de Android.mk .

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

Corrección o eliminación de pruebas

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

Enviando sus cambios

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

  • Para los cambios que se aplican a varios niveles de API, primero desarrolle un parche en aosp/master y luego seleccione la rama de prueba más avanzada. Permita que la fusión automática combine los cambios aguas abajo en las ramas de prueba de AOSP. Consulte Programación de lanzamiento e información de sucursales para ver la lista de sucursales y la información de la ruta de combinación automática.
  • Para los 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 RESTRINGIR AUTOMERGE en el mensaje de confirmación.

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

Horario de lanzamiento e información de la sucursal

Los lanzamientos de CTS siguen este calendario.

Versión nivel de API Rama Frecuencia
12L 32 Android12L-pruebas-dev Trimestral
12 31 android12-tests-dev Trimestral
11 30 android11-pruebas-dev Trimestral
10 29 android10-tests-dev Trimestral
No se planean más lanzamientos para las versiones 9.0, 8.1, 8.0, 7.1, 7.0, 6.0, 5.1, 5.0, 4.4, 4.3 y 4.2.

Fechas importantes durante el lanzamiento

  • Fin de la primera semana: congelación de código. Los cambios combinados en la rama hasta que se congele el 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 elija un candidato para el lanzamiento, se consideran para el lanzamiento posterior.
  • Segunda o tercera semana: CTS se publica en AOSP .

Flujo de combinación automática

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

Para cambios directamente a una rama AOSP, la ruta de combinación automática es:
pie-cts-dev > android10-tests-dev > android11-tests-dev > android12-tests-dev > android12L-tests-dev > aosp/master

Para los cambios a una próxima versión de Android, la ruta de combinación automática es:
aosp/master > <private-development-branch for Android T (AOSP experimental)> .

Si una lista de cambios (CL) no se fusiona correctamente, se envía un correo electrónico al autor del parche 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 de la CL en conflicto.

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