A partir de 27 de março de 2025, recomendamos usar android-latest-release em vez de aosp-main para criar e contribuir com o AOSP. Para mais informações, consulte Mudanças no AOSP.
CTS com tecnologia de desenvolvedor
Mantenha tudo organizado com as coleções
Salve e categorize o conteúdo com base nas suas preferências.
Esta página descreve as diretrizes de uso do CTS com tecnologia de desenvolvedor (CTS-D).
Cobertura de teste
O CTS-D, assim como o CTS e o CTS Verifier, só pode aplicar o seguinte:
- Todas as APIs públicas descritas no SDK para desenvolvedores
(developer.android.com) para um determinado nível de API.
- Todos os requisitos obrigatórios incluídos no Documento de definição de compatibilidade
do Android (CDD, na sigla em inglês) para um determinado nível de API.
Os requisitos não obrigatórios, como FORTEMENTE RECOMENDADO, DEVE, PODE, são opcionais
e não podem ser testados usando o CTS.
Como todas as APIs e os requisitos do CDD estão vinculados a um nível de API específico, todos os testes do CTS (CTS, CTS-D e CTS Verifier) são vinculados ao mesmo nível de API que as
APIs ou os requisitos associados. Se uma API específica for descontinuada ou alterada,
o teste correspondente precisará ser descontinuado ou atualizado.
Regras de criação de testes CTS
- Um teste precisa produzir o mesmo resultado objetivo de forma consistente.
- Um teste precisa determinar se um dispositivo é aprovado ou reprovado testando-o
uma vez.
- Os criadores de testes precisam remover todos os fatores possíveis que possam afetar os resultados.
- Se um dispositivo precisar de uma determinada condição/ambiente/configuração de hardware, essa configuração
precisa ser claramente definida na mensagem de confirmação. Para conferir exemplos de instruções de configuração,
consulte Como configurar o CTS.
- O teste não pode ser executado por mais de 6 horas de cada vez. Se precisar ser executado por
mais tempo, inclua o raciocínio na proposta de teste para que possamos analisá-la.
Confira a seguir um exemplo de conjunto de condições de teste para testar uma restrição
de app:
- O Wi-Fi está estável (para um teste que depende do Wi-Fi).
- O dispositivo permanece parado durante o teste (ou não, dependendo do teste).
- O dispositivo está desconectado de qualquer fonte de alimentação com X% de nível de bateria.
- Nenhum app, serviço em primeiro plano ou serviço em segundo plano está em execução, exceto o
CTS.
- A tela fica desligada durante a execução do CTS.
- O dispositivo NÃO é
isLowRamDevice.
- A economia de bateria / restrições de app não foram alteradas do
estado "padrão".
Testar a qualificação
Aceitamos novos testes que apliquem um comportamento que não é testado por testes de CTS,
CTS Verifier ou CTS-D. Qualquer teste que verifique um comportamento fora do escopo
da nossa cobertura de teste será rejeitado.
Processo de envio do CTS
- Escrever uma proposta de teste:um desenvolvedor de apps envia uma proposta de teste usando o
Google Issue Tracker,
descrevendo o problema identificado e propondo um teste para verificar
isso. A proposta precisa incluir o ID do requisito de CDD associado.
A equipe do Android analisa a proposta.
- Desenvolver um teste do CTS:depois que uma proposta é aprovada, o remetente cria
um teste do CTS no AOSP na versão mais recente do Android
(
android16-release). A equipe do Android analisa o código e,
se aceito, seleciona a mudança e a mescla no branch de
desenvolvimento interno. Para mais detalhes, consulte
Onde propor mudanças no AOSP?.
Diretrizes para a elaboração de testes CTS-D
- Siga o Guia de estilo de código Java.
- Siga todas as etapas descritas em Desenvolvimento do CTS.
- Adicione seus testes ao plano de teste apropriado:
- Use
include-filters para adicionar novos testes ao plano de teste do CTS-D: platform/cts/tools/cts-tradefed/res/config/cts-developer.xml.
- Use
exclude-filters para excluir os novos testes do plano de teste principal do CTS: platform/cts/tools/cts-tradefed/res/config/cts-developer-exclude.xml.
- Processe todos os avisos e sugestões de
errorprone em build_error.log.
- Rebaseie as mudanças em
head. Isso inclui os planos de teste cts-developer.xml e
cts-developer-exclude.xml.
- Trabalhe com seu contato de engenharia do Google para determinar se o caso de teste
pode ser incluído em um módulo CTS existente. Se não for possível, eles vão ajudar você
a criar um novo módulo.
- Para cada novo módulo de teste criado, crie um arquivo OWNERS no diretório do novo módulo
de teste.
- O arquivo OWNERS precisa conter as seguintes informações, obtidas do proprietário do teste do Google com quem você está trabalhando:
# Bug component: xxx- Proprietário do teste do Google ldap
- Em
AndroidTest.xml, especifique os seguintes parâmetros. Consulte
os arquivos de exemplo (1,
2)
para conferir exemplos:
Instant_app ou not_instant_appsecondary_user ou not_secondary_userall_foldable_states ou no_foldable_states
- Para especificar o minSDK correto, consulte a documentação de <uses-sdk>.
- Ao verificar novos métodos, classes ou módulos de teste, adicione-os ao plano de teste do CTS-D
e exclua-os do plano de teste principal do CTS da mesma forma que para
novos testes.
Executar o teste CTS-D
Execute o plano de teste CTS-D na linha de comando
usando run cts --plan cts-developer.
Para executar um caso de teste específico, use run cts --include-filter "test_module_name test_name".
Para informações sobre como executar o CTS completo, consulte Executar testes do CTS.
Aceitação e liberação
Depois que uma solicitação de teste é enviada, uma equipe interna a analisa para garantir
que ela testa um requisito do CDD ou um comportamento documentado da API. Se o teste for
determinado como uma verificação de requisito ou comportamento válido, a equipe
vai encaminhar o caso de teste a um engenheiro do Google para uma análise mais detalhada. O engenheiro do Google
vai entrar em contato com você para dar feedback sobre como o teste pode ser melhorado
antes de ser aceito no CTS.
Consulte
Programação de lançamentos e informações sobre ramificações
para saber mais sobre a programação de lançamentos do CTS.
O conteúdo e os exemplos de código nesta página estão sujeitos às licenças descritas na Licença de conteúdo. Java e OpenJDK são marcas registradas da Oracle e/ou suas afiliadas.
Última atualização 2025-07-27 UTC.
[[["Fácil de entender","easyToUnderstand","thumb-up"],["Meu problema foi resolvido","solvedMyProblem","thumb-up"],["Outro","otherUp","thumb-up"]],[["Não contém as informações de que eu preciso","missingTheInformationINeed","thumb-down"],["Muito complicado / etapas demais","tooComplicatedTooManySteps","thumb-down"],["Desatualizado","outOfDate","thumb-down"],["Problema na tradução","translationIssue","thumb-down"],["Problema com as amostras / o código","samplesCodeIssue","thumb-down"],["Outro","otherDown","thumb-down"]],["Última atualização 2025-07-27 UTC."],[],[],null,["# Developer-Powered CTS\n\nThis page outlines the usage guidelines for Developer-Powered CTS (CTS-D).\n\nTest coverage\n-------------\n\nCTS-D, like CTS \\& CTS Verifier, can only enforce the following:\n\n- All public APIs that are described in the developer SDK (developer.android.com) for a certain API level.\n- All MUST requirements that are included in the Android Compatibility Definition Document (CDD) for a certain API level.\n\nNon-MUST requirements, such as STRONGLY RECOMMENDED, SHOULD, MAY, are optional\nand can't be tested using CTS.\n\nBecause all APIs and CDD requirements are tied to a specific API level, all CTS\ntests (CTS, CTS-D, and CTS Verifier) are tied to the same API level as their\nassociated APIs or requirements. If a specific API is deprecated or changed,\nits corresponding test must be deprecated or updated.\n\nCTS test creation rules\n-----------------------\n\n- A test must produce the same objective result consistently.\n- A test must determine whether a device passes or fails by testing that device one time out of the box.\n- Test creators must remove all possible factors that could affect test results.\n- If a device needs a certain hardware condition/environment/setup, that setup must be clearly defined in the commit message. For example setup instructions, see [Setting Up CTS](/docs/compatibility/cts/setup).\n- The test must not run for more than 6 hours at a time. If it needs to run for longer, please include the reasoning in your test proposal so that we can review it.\n\nThe following is an example set of test conditions for testing an app\nrestriction:\n\n- Wifi is stable (for a test that relies on Wifi).\n- The device remains stationary during the test (or not, depending on the test).\n- The device is unplugged from any power source with X percent of battery level.\n- No apps, foreground services, or background services are running, except for CTS.\n- The screen is off while running CTS.\n- The device is NOT `isLowRamDevice`.\n- Battery saver / app restrictions have not been changed from the \"out-of-the-box\" state.\n\n### Test eligibility\n\nWe accept new tests that enforce a behavior that isn't tested by existing CTS,\nCTS Verifier, or CTS-D tests. Any test that checks a behavior outside the scope\nof [our test coverage](#coverage) will be rejected.\n\nCTS submission process\n----------------------\n\n1. **Write a test proposal:** An app developer submits a test proposal using [Google Issue Tracker](https://issuetracker.google.com/issues/new?component=1124973&template=1633344), describing the issue that has been identified and proposing a test to check for it. The proposal must include the associated [CDD requirement ID](/docs/compatibility/cts/development#annotation). The Android team reviews the proposal.\n2. **Develop a CTS test:** After a proposal is approved, its submitter creates a CTS test on AOSP on the Android latest release branch (`android16-release`). The Android team reviews the code and if accepted, cherrypicks the change and merges it into the internal development branch. For details, see [Where should I propose changes to AOSP?](/docs/setup/about/faqs#changes-aosp).\n\nCTS-D test writing guidelines\n-----------------------------\n\n- Follow the [Java Code Style Guide](/docs/setup/contribute/code-style).\n- Follow all the steps described in [CTS Development](/docs/compatibility/cts/development).\n- Add your tests to the appropriate test plan:\n - Use `include-filters` to add your new tests to the CTS-D test plan: `platform/cts/tools/cts-tradefed/res/config/cts-developer.xml`.\n - Use `exclude-filters` to exclude your new tests from the main CTS test plan: `platform/cts/tools/cts-tradefed/res/config/cts-developer-exclude.xml`.\n- Handle all `errorprone` warnings and suggestions in `build_error.log`.\n- Rebase your changes to `head`. This includes the `cts-developer.xml` and `cts-developer-exclude.xml` test plans.\n- Work with your Google engineering contact to determine whether your test case can be included in an existing CTS module. If it can't, they'll help you create a new module.\n- For each new test module created, create an OWNERS file in the new test module directory.\n - Your OWNERS file should contain the following information, obtained from the Google test owner you're working with:\n - `# Bug component: xxx`\n - Google test owner ldap\n- In `AndroidTest.xml`, specify the following parameters. Refer to the sample files ([1](https://cs.android.com/android/platform/superproject/+/android-latest-release:cts/tests/sample/), [2](https://cs.android.com/android/platform/superproject/+/android-latest-release:cts/hostsidetests/sample/)) for examples:\n - `Instant_app` or `not_instant_app`\n - `secondary_user` or `not_secondary_user`\n - `all_foldable_states` or `no_foldable_states`\n- To specify the correct minSDK, refer to [the \\\u003cuses-sdk\\\u003e documentation](https://developer.android.com/guide/topics/manifest/uses-sdk-element).\n- When checking in new test methods, classes, or modules, add them to the CTS-D test plan and exclude them from the main CTS test plan in the same way as for new tests.\n\nRun your CTS-D test\n-------------------\n\nRun the CTS-D test plan [from the command line](/docs/compatibility/cts/command-console-v2)\nusing `run cts --plan cts-developer`.\n\nTo run a specific test case, use `run cts --include-filter \"test_module_name test_name\"`.\n\nFor information on running the full CTS, see [Run CTS tests](/docs/compatibility/cts/run).\n\nAcceptance and release\n----------------------\n\nOnce a test request is submitted, an internal team will review it to make sure\nit tests a CDD requirement or a documented API behavior. If the test is\ndetermined to be checking for a valid requirement or behavior, the team\nwill forward this test case to a Google engineer for further review. The Google\nengineer will reach out to you with feedback on how the test can be improved\nbefore it can be accepted into CTS.\n\nSee\n[Release schedule and branch information](/docs/compatibility/cts/development#release-schedule)\nfor details on the CTS release schedule."]]
