Desenvolvimento CTS

Inicializando seu cliente Repo

Siga as instruções do Download the Source para obter e compilar o código-fonte do Android. Ao emitir o comando repo init , especifique uma ramificação CTS específica usando -b . Isso garante que suas alterações CTS sejam incluídas em versões CTS subsequentes.

O código de exemplo a seguir mostra como usar o 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

Construindo e executando CTS

Execute os seguintes comandos para construir o CTS e iniciar o console CTS interativo:

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

No console CTS, digite:

tf> run cts --plan CTS

Escrever testes CTS

Os testes CTS usam JUnit e as APIs de teste do Android. Revise o tutorial Test your app e os testes existentes no diretório cts/tests . Os testes CTS seguem principalmente as mesmas convenções usadas em outros testes Android.

O CTS é executado em muitos dispositivos de produção, portanto, os testes devem seguir estas regras:

  • Leve em consideração diferentes tamanhos de tela, orientações e layouts de teclado.
  • Use apenas métodos de API públicos. Em outras palavras, evite todas as classes, métodos e campos com a anotação hide .
  • Evite usar layouts de visualização ou confiar nas dimensões de recursos que podem não estar em alguns dispositivos.
  • Não confie em privilégios de root.

Adicionar anotação Java

Se seu teste verificar um comportamento de API, anote seu código de teste com @ApiTest e liste todas as APIs envolvidas no campo apis . Use o formato apropriado dentre os exemplos a seguir:

Tipo de API Formato de anotação Notas
Método android.example.ClassA#methodA O caso de uso mais comum.
Método com valores-chave android.example.ClassB#methodB(KeyA) Use somente quando seu teste usar um método de API para validar um campo, como neste exemplo.
Campo android.example.ClassC#FieldA Use somente quando seu teste validar um campo de API diretamente, como neste exemplo.

Se o seu teste verificar um requisito de CDD, anote o ID do requisito (incluindo o ID da seção CDD e o ID do requisito) com @CddTest no código de teste CTS, conforme mostrado no exemplo a seguir. Em sua mensagem de confirmação, mencione qual requisito de CDD é testado por seu teste, referindo-se aos IDs de requisitos de CDD. Os IDs de requisito de CDD são uma combinação de ID de seção e ID de requisito, conectados por uma barra (/) como em 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 Activity em seu AndroidManifest.xml com o ID CDD relevante. Os formatos para campos de valor são semelhantes aos formatos de anotações Java no CTS. Na mensagem de confirmação, mencione qual requisito de CDD é aplicado fazendo referência ao ID do 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>

Na mensagem de confirmação

Mencione claramente por que seu teste precisa ser adicionado e adicione links relevantes para suporte. Para testes CTS-D, inclua um link para a proposta de teste que você criou no Google Issue Tracker como parte do processo de envio do CTS-D .

Criar um subplano

Como exemplo, você pode adicionar um arquivo SubPlan.xml em android-cts/subplans da seguinte forma:

<?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 executar o subplano:

run cts --subplan aSubPlan

O formato de entrada do subplano é:

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" />

Nomeação e localização do teste

A maioria dos casos de teste CTS tem como alvo uma classe específica na API do Android. Esses testes têm nomes de pacotes Java com um sufixo cts e nomes de classes com um sufixo Test . Cada caso de teste consiste em vários testes, onde cada teste normalmente exercita um método específico da classe que está sendo testada. Esses testes são organizados em uma estrutura de diretórios onde os testes são agrupados em diferentes categorias, como "widgets" ou "views".

Por exemplo, o teste CTS para o pacote Java android.widget.TextView é android.widget.cts.TextViewTest com seu nome de pacote Java como android.widget.cts e seu nome de classe como TextViewTest .

  • Nome do pacote Java
    O nome do pacote Java para os testes CTS é o nome do pacote da classe que o teste está testando, seguido por .cts . Para nosso exemplo, o nome do pacote seria android.widget.cts .
  • Nome da classe
    O nome da classe para testes CTS é o nome da classe que está sendo testada com "Teste" anexado. Por exemplo, se um teste for direcionado a TextView , o nome da classe deverá ser TextViewTest .
  • Nome do módulo (somente CTS v2)
    O CTS v2 organiza os testes por módulo. O nome do módulo geralmente é a segunda string do nome do pacote Java (em nosso exemplo, widget ).

A estrutura de diretórios e o código de exemplo dependem de você estar usando CTS v1 ou CTS v2.

CTS v1

Para Android 6.0 ou inferior, use CTS v1. Para CTS v1, o código de exemplo está em cts/tests/tests/example .

A estrutura de diretórios nos testes CTS v1 se parece com isso:

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

CTS v2

Para Android 7.0 ou superior, use CTS v2. Para obter detalhes, consulte o teste de amostra no Android Open Source Project (AOSP) .

A estrutura de diretórios do CTS v2 se parece com isso:

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

Novos pacotes de amostra

Ao adicionar novos testes, pode não haver um diretório existente para colocar seu teste. Nesses casos, você precisa criar o diretório e copiar os arquivos de amostra apropriados.

CTS v1

Se você estiver usando o CTS v1, consulte o exemplo em cts/tests/tests/example e crie um novo diretório. Além disso, certifique-se de adicionar o nome do módulo do seu novo pacote de seu Android.mk para CTS_COVERAGE_TEST_CASE_LIST em cts/CtsTestCaseList.mk . build/core/tasks/cts.mk usa este makefile para combinar todos os testes e criar o pacote CTS final.

CTS v2

Use o teste de amostra /cts/tests/sample/ para iniciar rapidamente seu novo módulo de teste com as seguintes etapas:

  1. Para criar o diretório de teste e copiar os arquivos de amostra, execute: 
    mkdir cts/tests/module-name && cp -r cts/tests/sample/* cts/tests/module-name
  2. Navegue até cts/tests/ module-name e substitua todas as instâncias de "[Ss]ample" pela convenção de nomenclatura recomendada acima.
  3. Atualize SampleDeviceActivity para exercitar o recurso que você está testando.
  4. Atualize SampleDeviceTest para garantir que a atividade seja bem-sucedida ou registre seus erros.

Diretórios adicionais

Outros diretórios do Android, como assets , jni , libs e res também podem ser adicionados. Para adicionar o código JNI, crie um diretório na raiz do projeto ao lado de src com o código nativo e um makefile Android.mk nele.

O makefile normalmente contém as seguintes configurações:

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)

arquivo Android.mk

Por fim, modifique o arquivo Android.mk na raiz do projeto para construir o código nativo e depender dele, conforme mostrado abaixo:

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

Corrigindo ou removendo testes

Além de adicionar novos testes, você pode corrigir ou remover testes anotados com BrokenTest ou KnownFailure .

Enviando suas alterações

Ao enviar patches CTS ou VTS no AOSP, escolha sua ramificação de desenvolvimento com base em quais níveis de API o patch se aplica.

  • Para alterações que se aplicam a vários níveis de API, primeiro desenvolva um patch no aosp/master e, em seguida, selecione o branch de teste mais upstream . Permita que o automerger mescle as alterações downstream nas ramificações de teste do AOSP. Consulte Agenda de lançamento e informações de ramificação para obter a lista de ramificações e informações de caminho de mesclagem automática.
  • Para alterações específicas de um nível de API específico, desenvolva ou selecione as alterações para a ramificação de teste correta com DO NOT MERGE ou RESTRICT AUTOMERGE na mensagem de confirmação.

Siga o fluxo de trabalho de envio de patches para contribuir com alterações no CTS. Um revisor será designado para revisar sua alteração de acordo.

Cronograma de lançamento e informações da filial

Os lançamentos do CTS seguem este cronograma.

Versão Nível da API Ramo Frequência
12L 32 android12L-tests-dev Trimestral
12 31 android12-tests-dev Trimestral
11 30 android11-tests-dev Trimestral
10 29 android10-tests-dev Trimestral
Nenhum lançamento adicional está planejado para as versões 9.0, 8.1, 8.0, 7.1, 7.0, 6.0, 5.1, 5.0, 4.4, 4.3 e 4.2.

Datas importantes durante o lançamento

  • Fim da primeira semana: congelamento de código. As alterações mescladas na ramificação até o congelamento do código são consideradas para a próxima versão do CTS. Os envios para a ramificação após o congelamento do código, ou após a escolha de um candidato para lançamento, são considerados para o lançamento subsequente.
  • Segunda ou terceira semana: CTS é publicado em AOSP .

Fluxo de mesclagem automática

As agências de desenvolvimento CTS foram configuradas para que as alterações enviadas a cada agência se unam automaticamente às agências superiores.

Para alterações diretamente em uma ramificação AOSP, o caminho de mesclagem automática é:
pie-cts-dev > android10-tests-dev > android11-tests-dev > android12-tests-dev > android12L-tests-dev > aosp/master

Para alterações em uma próxima versão do Android, o caminho de mesclagem automática é:
aosp/master > <private-development-branch for Android T (AOSP experimental)> .

Se uma lista de alterações (CL) não for mesclada corretamente, o autor do patch receberá um e-mail com instruções sobre como resolver o conflito. Na maioria dos casos, o autor do patch pode usar as instruções para pular o automerge do CL conflitante.

Se uma ramificação mais antiga exigir a alteração, o patch precisa ser selecionado a partir da ramificação mais recente.

,

Inicializando seu cliente Repo

Siga as instruções do Download the Source para obter e compilar o código-fonte do Android. Ao emitir o comando repo init , especifique uma ramificação CTS específica usando -b . Isso garante que suas alterações CTS sejam incluídas em versões CTS subsequentes.

O código de exemplo a seguir mostra como usar o 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

Construindo e executando CTS

Execute os seguintes comandos para construir o CTS e iniciar o console CTS interativo:

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

No console CTS, digite:

tf> run cts --plan CTS

Escrever testes CTS

Os testes CTS usam JUnit e as APIs de teste do Android. Revise o tutorial Test your app e os testes existentes no diretório cts/tests . Os testes CTS seguem principalmente as mesmas convenções usadas em outros testes Android.

O CTS é executado em muitos dispositivos de produção, portanto, os testes devem seguir estas regras:

  • Leve em consideração diferentes tamanhos de tela, orientações e layouts de teclado.
  • Use apenas métodos de API públicos. Em outras palavras, evite todas as classes, métodos e campos com a anotação hide .
  • Evite usar layouts de visualização ou confiar nas dimensões de recursos que podem não estar em alguns dispositivos.
  • Não confie em privilégios de root.

Adicionar anotação Java

Se seu teste verificar um comportamento de API, anote seu código de teste com @ApiTest e liste todas as APIs envolvidas no campo apis . Use o formato apropriado dentre os exemplos a seguir:

Tipo de API Formato de anotação Notas
Método android.example.ClassA#methodA O caso de uso mais comum.
Método com valores-chave android.example.ClassB#methodB(KeyA) Use somente quando seu teste usar um método de API para validar um campo, como neste exemplo.
Campo android.example.ClassC#FieldA Use somente quando seu teste validar um campo de API diretamente, como neste exemplo.

Se o seu teste verificar um requisito de CDD, anote o ID do requisito (incluindo o ID da seção CDD e o ID do requisito) com @CddTest no código de teste CTS, conforme mostrado no exemplo a seguir. Em sua mensagem de confirmação, mencione qual requisito de CDD é testado por seu teste, referindo-se aos IDs de requisitos de CDD. Os IDs de requisito de CDD são uma combinação de ID de seção e ID de requisito, conectados por uma barra (/) como em 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 Activity em seu AndroidManifest.xml com o ID CDD relevante. Os formatos para campos de valor são semelhantes aos formatos de anotações Java no CTS. Na mensagem de confirmação, mencione qual requisito de CDD é aplicado fazendo referência ao ID do 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>

Na mensagem de confirmação

Mencione claramente por que seu teste precisa ser adicionado e adicione links relevantes para suporte. Para testes CTS-D, inclua um link para a proposta de teste que você criou no Google Issue Tracker como parte do processo de envio do CTS-D .

Criar um subplano

Como exemplo, você pode adicionar um arquivo SubPlan.xml em android-cts/subplans da seguinte forma:

<?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 executar o subplano:

run cts --subplan aSubPlan

O formato de entrada do subplano é:

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" />

Nomeação e localização do teste

A maioria dos casos de teste CTS tem como alvo uma classe específica na API do Android. Esses testes têm nomes de pacotes Java com um sufixo cts e nomes de classes com um sufixo Test . Cada caso de teste consiste em vários testes, onde cada teste normalmente exercita um método específico da classe que está sendo testada. Esses testes são organizados em uma estrutura de diretórios onde os testes são agrupados em diferentes categorias, como "widgets" ou "views".

Por exemplo, o teste CTS para o pacote Java android.widget.TextView é android.widget.cts.TextViewTest com seu nome de pacote Java como android.widget.cts e seu nome de classe como TextViewTest .

  • Nome do pacote Java
    O nome do pacote Java para os testes CTS é o nome do pacote da classe que o teste está testando, seguido por .cts . Para nosso exemplo, o nome do pacote seria android.widget.cts .
  • Nome da classe
    O nome da classe para testes CTS é o nome da classe que está sendo testada com "Teste" anexado. Por exemplo, se um teste for direcionado a TextView , o nome da classe deverá ser TextViewTest .
  • Nome do módulo (somente CTS v2)
    O CTS v2 organiza os testes por módulo. O nome do módulo geralmente é a segunda string do nome do pacote Java (em nosso exemplo, widget ).

A estrutura de diretórios e o código de exemplo dependem de você estar usando CTS v1 ou CTS v2.

CTS v1

Para Android 6.0 ou inferior, use CTS v1. Para CTS v1, o código de exemplo está em cts/tests/tests/example .

A estrutura de diretórios nos testes CTS v1 se parece com isso:

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

CTS v2

Para Android 7.0 ou superior, use CTS v2. Para obter detalhes, consulte o teste de amostra no Android Open Source Project (AOSP) .

A estrutura de diretórios do CTS v2 se parece com isso:

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

Novos pacotes de amostra

Ao adicionar novos testes, pode não haver um diretório existente para colocar seu teste. Nesses casos, você precisa criar o diretório e copiar os arquivos de amostra apropriados.

CTS v1

Se você estiver usando o CTS v1, consulte o exemplo em cts/tests/tests/example e crie um novo diretório. Além disso, certifique-se de adicionar o nome do módulo do seu novo pacote de seu Android.mk para CTS_COVERAGE_TEST_CASE_LIST em cts/CtsTestCaseList.mk . build/core/tasks/cts.mk usa este makefile para combinar todos os testes e criar o pacote CTS final.

CTS v2

Use o teste de amostra /cts/tests/sample/ para iniciar rapidamente seu novo módulo de teste com as seguintes etapas:

  1. Para criar o diretório de teste e copiar os arquivos de amostra, execute: 
    mkdir cts/tests/module-name && cp -r cts/tests/sample/* cts/tests/module-name
  2. Navegue até cts/tests/ module-name e substitua todas as instâncias de "[Ss]ample" pela convenção de nomenclatura recomendada acima.
  3. Atualize SampleDeviceActivity para exercitar o recurso que você está testando.
  4. Atualize SampleDeviceTest para garantir que a atividade seja bem-sucedida ou registre seus erros.

Diretórios adicionais

Outros diretórios do Android, como assets , jni , libs e res também podem ser adicionados. Para adicionar o código JNI, crie um diretório na raiz do projeto ao lado de src com o código nativo e um makefile Android.mk nele.

O makefile normalmente contém as seguintes configurações:

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)

arquivo Android.mk

Por fim, modifique o arquivo Android.mk na raiz do projeto para construir o código nativo e depender dele, conforme mostrado abaixo:

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

Corrigindo ou removendo testes

Além de adicionar novos testes, você pode corrigir ou remover testes anotados com BrokenTest ou KnownFailure .

Enviando suas alterações

Ao enviar patches CTS ou VTS no AOSP, escolha sua ramificação de desenvolvimento com base em quais níveis de API o patch se aplica.

  • Para alterações que se aplicam a vários níveis de API, primeiro desenvolva um patch no aosp/master e, em seguida, selecione o branch de teste mais upstream . Permita que o automerger mescle as alterações downstream nas ramificações de teste do AOSP. Consulte Agenda de lançamento e informações de ramificação para obter a lista de ramificações e informações de caminho de mesclagem automática.
  • Para alterações específicas de um nível de API específico, desenvolva ou selecione as alterações para a ramificação de teste correta com DO NOT MERGE ou RESTRICT AUTOMERGE na mensagem de confirmação.

Siga o fluxo de trabalho de envio de patches para contribuir com alterações no CTS. Um revisor será designado para revisar sua alteração de acordo.

Cronograma de lançamento e informações da filial

Os lançamentos do CTS seguem este cronograma.

Versão Nível da API Ramo Frequência
12L 32 android12L-tests-dev Trimestral
12 31 android12-tests-dev Trimestral
11 30 android11-tests-dev Trimestral
10 29 android10-tests-dev Trimestral
Nenhum lançamento adicional está planejado para as versões 9.0, 8.1, 8.0, 7.1, 7.0, 6.0, 5.1, 5.0, 4.4, 4.3 e 4.2.

Datas importantes durante o lançamento

  • Fim da primeira semana: congelamento de código. As alterações mescladas na ramificação até o congelamento do código são consideradas para a próxima versão do CTS. Os envios para a ramificação após o congelamento do código, ou após a escolha de um candidato para lançamento, são considerados para o lançamento subsequente.
  • Segunda ou terceira semana: CTS é publicado em AOSP .

Fluxo de mesclagem automática

As agências de desenvolvimento CTS foram configuradas para que as alterações enviadas a cada agência se unam automaticamente às agências superiores.

Para alterações diretamente em uma ramificação AOSP, o caminho de mesclagem automática é:
pie-cts-dev > android10-tests-dev > android11-tests-dev > android12-tests-dev > android12L-tests-dev > aosp/master

Para alterações em uma próxima versão do Android, o caminho de mesclagem automática é:
aosp/master > <private-development-branch for Android T (AOSP experimental)> .

Se uma lista de alterações (CL) não for mesclada corretamente, o autor do patch receberá um e-mail com instruções sobre como resolver o conflito. Na maioria dos casos, o autor do patch pode usar as instruções para pular o automerge do CL conflitante.

Se uma ramificação mais antiga exigir a alteração, o patch precisa ser selecionado a partir da ramificação mais recente.