Desenvolvimento do CTS

Inicializar o cliente do Repo

Siga as instruções em Como fazer o download da origem para baixar e criar o código-fonte do Android. Ao emitir o comando repo init, especifique uma ramificação do CTS usando -b. Isso garante que as mudanças na CTS sejam incluídas em versões subsequentes.

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

Criar e executar o CTS

Execute os comandos a seguir para criar o CTS e iniciar o console interativo do CTS:

Criar o CTS (AOSP 14 ou anterior)

cd /path/to/android/root
source build/envsetup.sh
make cts -j32 TARGET_PRODUCT=aosp_arm64
cts-tradefed

Criar 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

Consulte a tabela a seguir para selecionar o valor de target-release:

Filial Versão de destino
android15-tests-dev ap3a

Executar o CTS

No console do CTS, digite:

tf> run cts --plan CTS

Criar testes do CTS

.

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

O CTS é executado em muitos dispositivos de produção. Portanto, os testes precisam seguir estas regras:

  • Considere os diferentes tamanhos e orientações de tela 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 depender das dimensões de recursos que podem não estar em alguns dispositivos.
  • Não dependa de privilégios de raiz.

Adicionar anotação Java

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

API type Formato da anotação Observações
Método android.example.ClassA#methodA O caso de uso mais comum.
Método com chaves-valor android.example.ClassB#methodB(KeyA) Use apenas quando o teste usar um método de API para validar um campo, como neste exemplo.
Campo android.example.ClassC#FieldA Use apenas quando o teste validar um campo de API diretamente, como neste exemplo.

Se o teste verificar um requisito do CDD, anote o ID do requisito (incluindo o ID da seção do CDD e o ID do requisito) com @CddTest no código de teste do CTS, conforme mostrado no exemplo a seguir. Na mensagem de commit, mencione qual requisito do CDD é testado pelo seu teste, referindo-se aos IDs dos requisitos do CDD. Os IDs de requisitos do 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 o CTS Verifier, anote cada atividade no AndroidManifest.xml com o ID do CDD relevante. Os formatos dos campos de valor são semelhantes aos formatos das anotações Java no CTS. Na mensagem de commit, mencione qual requisito de CDD é aplicado referenciando o 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 inclua links relevantes para suporte. Para testes do CTS-D, inclua um link para a proposta de teste criada no Google Issue Tracker como parte do processo de envio do CTS-D.

Criar um subplano

Por exemplo, é possível adicionar um arquivo SubPlan.xml em android-cts/subplans da seguinte maneira:

<?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 da entrada de 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" />

Nome e local do teste

A maioria dos casos de teste do CTS tem como destino 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, em que cada teste geralmente exercita um método específico da classe que está sendo testada. Esses testes são organizados em uma estrutura de diretórios em que são agrupados em diferentes categorias, como "widgets" ou "views".

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

  • Nome do pacote Java
    O nome do pacote Java para os testes do CTS é o nome do pacote da classe que o teste está testando, seguido por .cts. No nosso exemplo, o nome do pacote seria android.widget.cts.
  • Nome da classe
    O nome da classe para testes do CTS é o nome da classe testada com "Test" anexado. Por exemplo, se um teste segmenta TextView, o nome da classe deve 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 (no nosso exemplo, widget).

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

CTS v1

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

A estrutura de diretórios nos testes do CTS v1 é assim: 

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

CTS v2

Para o Android 7.0 ou versões mais recentes, use o CTS v2. Para mais detalhes, consulte o teste de amostra no Android Open Source Project (AOSP).

A estrutura de diretórios do CTS v2 é assim: 

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

Novos pacotes de amostras

Ao adicionar novos testes, talvez não haja um diretório para colocar seu teste. Nesses casos, é necessário criar o diretório e copiar os arquivos de amostra adequados.

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, adicione o nome do módulo do novo pacote do arquivo Android.mk ao CTS_COVERAGE_TEST_CASE_LIST em cts/CtsTestCaseList.mk. O build/core/tasks/cts.mk usa este makefile para combinar todos os testes e criar o pacote final do CTS.

CTS v2

Use o teste de amostra /cts/tests/sample/ para iniciar rapidamente seu novo módulo de teste com estas 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. Acesse cts/tests/module-name e substitua todas as instâncias de "[Ss]ample" pela convenção de nomenclatura recomendada acima.
  3. Atualize SampleDeviceActivity para testar o recurso que você está testando.
  4. Atualize SampleDeviceTest para garantir que a atividade seja concluída ou registre os erros.

Outros diretórios

Outros diretórios do Android, como assets, jni, libs e res, também podem ser adicionados. Para adicionar 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 criar 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))

Corrigir ou remover testes

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

Enviar as mudanças

Siga o fluxo de trabalho Enviar mudanças no código ao contribuir com mudanças no CTS.

  • Escolha a ramificação de desenvolvimento com base nos níveis de API a que o patch se aplica.
  • Desenvolva ou selecione as mudanças para a ramificação de teste correta com DO NOT MERGE ou RESTRICT AUTOMERGE na mensagem de commit.

Um revisor é atribuído para analisar sua mudança e fazer cherrypick dela no Gerrit interno de acordo com isso.

Programação de lançamentos e informações sobre ramificações

As versões do CTS seguem esta programação.

Versão Nível da API Branch de desenvolvimento Frequência de lançamento
16+ 36+ Gerrit interno Trimestralmente
15 35 android15-tests-dev Trimestralmente
14 34 android14-tests-dev Trimestralmente
13 33 android13-tests-dev Trimestralmente

Datas importantes durante o lançamento

  • Fim da primeira semana:congelamento de código. As mudanças mescladas na ramificação até o congelamento do código são consideradas para a próxima versão do CTS. As confirmações na ramificação após o congelamento do código ou depois que um candidato a lançamento é escolhido são consideradas para o lançamento subsequente.
  • Segunda ou terceira semana:o CTS é publicado na página Downloads do conjunto de teste de compatibilidade.

Fluxo de fusão automática

As ramificações de desenvolvimento do CTS foram configuradas para que as mudanças enviadas a cada ramificação sejam mescladas automaticamente com ramificações superiores.

Para mudanças diretamente em uma ramificação de desenvolvimento de teste do AOSP, o caminho de fusão automática é:
android13-tests-dev > android14-tests-dev > android15-tests-dev

  • Para versões do CTS 16 ou mais recentes, um revisor vai fazer o cherrypick da mudança no Gerrit interno.

Se uma lista de mudanças (CL) não for mesclada corretamente, o autor do patch vai 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 ignorar a mesclagem automática da CL conflitante.

Se uma ramificação mais antiga exigir a mudança, o patch precisará ser cherry-picked da ramificação mais recente.

Para mudanças de teste aplicáveis à próxima versão do Android, depois que você faz upload de uma mudança proposta, o Google a analisa e, se aceita, faz o cherrypick dela no Gerrit interno.