O Google tem o compromisso de promover a igualdade racial para as comunidades negras. Saiba como.

Esta página foi traduzida pela API Cloud Translation.

Desenvolvimento de CTS

Inicializar seu cliente do repo

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

O código de exemplo abaixo 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 seguintes comandos para criar o CTS e iniciar o Console do CTS:

Observação:é possível usar aosp_x86_64 como alternativa ao aosp_arm64.

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

No console do CTS, digite:

tf> run cts --plan CTS

Criar testes CTS

Os testes CTS usam JUnit e as APIs de teste do Android. Analise o Teste seu app e os testes atuais no diretório cts/tests. Na maioria das vezes, os testes de CTS seguem as mesmas convenções usadas em outros testes do Android.

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

Considere vários 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 dos recursos que podem não estar em alguns dispositivos.
Não dependa dos privilégios 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 apropriado entre os exemplos a seguir:

API type	Formato de 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 somente quando o teste usar um método de API para validar um campo, como em neste exemplo.
Campo	android.example.ClassC#FieldA	Use somente quando seu teste validar um campo de API diretamente, como em neste exemplo.

Se o teste verificar um requisito do CDD, anote o ID dele (incluindo a seção do CDD) ID e ID do requisito) por @CddTest no código de teste do CTS, conforme mostrado exemplo a seguir. Na mensagem de confirmação, mencione qual requisito do CDD é testado pelo seu consultando os IDs de requisitos do CDD. Os IDs de requisitos do CDD são uma combinação dos IDs de seção e o código 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 de anotações Java no o CTS. Na mensagem de confirmação, mencione qual requisito do CDD é aplicado referenciando o CDD. ID do requisito.


  <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 receber suporte. Para CTS-D testes, inclua um link para a proposta de teste que você criou no Google Issue Tracker como parte do o processo de envio do CTS-D.

Criar um subplano

Por exemplo, você pode adicionar um arquivo SubPlan.xml ao 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 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" />

Nome e local do teste

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

Por exemplo, o teste 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 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 dos testes de CTS é Nome da classe que está sendo testada com "Test" anexado. Para exemplo, se um teste segmentar 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 nossa exemplo, widget).

A estrutura do diretório e o exemplo de código dependem de você usar o CTS v1 ou CTS v2.

CTS v1

Para o Android 6.0 ou anterior, 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 mais recente, use o CTS v2. Para mais detalhes, consulte exemplo de teste no Android Open Source Project (AOSP).

A estrutura de diretórios do CTS v2 tem esta aparência:

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 seus teste. Nesses casos, você precisa criar o diretório e copiar o os arquivos de amostra apropriados.

CTS v1

Se você usar 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 pelo Android.mk para CTS_COVERAGE_TEST_CASE_LIST pol cts/CtsTestCaseList.mk build/core/tasks/cts.mk usa este makefile para combinar todos os testes e criar o pacote CTS final.

CTS v2

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

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

Navegue até cts/tests/module-name e substitua todas as instâncias de "[Ss]amplo" com o convenção de nomenclatura recomendada acima.
Atualize o SampleDeviceActivity para exercitar o recurso que você está testando.
Atualize o SampleDeviceTest para garantir que a atividade tenha êxito ou que os registros sejam registrados os erros dela.

Diretórios adicionais

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

O makefile geralmente 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 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 remove testes anotados com BrokenTest ou KnownFailure.

Enviar as mudanças

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

Para mudanças que se aplicam a vários níveis de API, primeiro desenvolver um patch em aosp/main e selecionar a a mais ramificação de teste upstream. Permitir que a mesclagem automática mescle as mudanças downstream em Ramificações de teste do AOSP. Consulte Informações sobre a programação de lançamentos e ramificações para 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 escolha as mudanças para a ramificação de teste correta com DO NOT MERGE ou RESTRINGIR AUTOMERGE na mensagem de confirmação.

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

Programação de lançamentos e informações da filial

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

Versão	Nível da API	Filial	Frequência
15	35	Android15-tests-dev	Trimestralmente
14	34	Android14-tests-dev	Trimestralmente
13	33	Android13-tests-dev	Trimestralmente
12L	32	android12L-tests-dev	Trimestralmente
12	31	desenvolvimento do Android 12	Trimestralmente

Datas importantes durante o lançamento

Fim da primeira semana: congelamento do código. Alterações mescladas na ramificação até que o congelamento do código seja considerado para a próxima versão do CTS. Os envios para a ramificação após o congelamento do código ou após um candidato a é escolhido, são considerados para a versão subsequente.
Segunda ou terceira semana:o CTS é publicado em AOSP:

Fluxo da mesclagem automática

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

Para mudanças feitas diretamente em uma ramificação de desenvolvimento de teste do AOSP, o caminho de mesclagem automática é:
android11-tests-dev > android12-tests-dev > android12L-tests-dev > android13-tests-dev > android14-tests-dev > android15-tests-dev > aosp-main

Para mudanças apenas na próxima versão do Android, o caminho da mesclagem automática é:
aosp-main > <Internal git_main>

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

Se uma ramificação mais antiga exigir a mudança, o patch precisará ser escolhidos a dedo a partir da ramificação mais recente.