A partire dal 27 marzo 2025, ti consigliamo di utilizzare android-latest-release anziché aosp-main per compilare e contribuire ad AOSP. Per ulteriori informazioni, vedi Modifiche ad AOSP.
CTS basato sugli sviluppatori
Mantieni tutto organizzato con le raccolte
Salva e classifica i contenuti in base alle tue preferenze.
Questa pagina illustra le linee guida per l'utilizzo di CTS (CTS-D) basato sugli sviluppatori.
Copertura test
CTS-D, come CTS e CTS Verifier, può applicare solo quanto segue:
- Tutte le API pubbliche descritte nell'SDK per sviluppatori
(developer.android.com) per un determinato livello API.
- Tutti i requisiti MUST inclusi nel Compatibility Definition Document (CDD) di Android per un determinato livello API.
I requisiti NON OBBLIGATORI, come FORTEMENTE CONSIGLIATO, DEVE, PUO, sono facoltativi
e non possono essere testati utilizzando CTS.
Poiché tutti i requisiti delle API e del CDD sono legati a un livello API specifico, tutti i test CTS (CTS, CTS-D e CTS Verifier) sono legati allo stesso livello API delle API o dei requisiti associati. Se un'API specifica viene ritirata o modificata,
il test corrispondente deve essere ritirato o aggiornato.
Regole per la creazione di test CTS
- Un test deve produrre lo stesso risultato oggettivo in modo coerente.
- Un test deve determinare se un dispositivo supera o meno il test testandolo
una volta fuori dalla confezione.
- I creator dei test devono rimuovere tutti i fattori che potrebbero influire sui risultati dei test.
- Se un dispositivo richiede una determinata condizione/ambiente/configurazione hardware, questa deve essere chiaramente definita nel messaggio di commit. Per istruzioni di configurazione di esempio, consulta Configurare CTS.
- Il test non deve essere eseguito per più di 6 ore alla volta. Se deve essere eseguito per più tempo, includi il ragionamento nella proposta di test per consentirci di esaminarlo.
Di seguito è riportato un esempio di condizioni di test per testare una limitazione dell'app:
- La rete Wi-Fi è stabile (per un test che si basa sul Wi-Fi).
- Il dispositivo rimane fermo durante il test (o meno, a seconda del test).
- Il dispositivo è scollegato da qualsiasi fonte di alimentazione con un livello della batteria pari al X percento.
- Non sono in esecuzione app, servizi in primo piano o servizi in background, ad eccezione di CTS.
- Lo schermo è spento durante l'esecuzione del CTS.
- Il dispositivo NON è
isLowRamDevice.
- Le restrizioni per il risparmio energetico / le app non sono state modificate rispetto allo stato "out-of-the-box".
Verifica l'idoneità
Accettiamo nuovi test che applicano un comportamento non testato dai test CTS,
CTS Verifier o CTS-D esistenti. Qualsiasi test che controlli un comportamento al di fuori dell'ambito della nostra copertura dei test verrà rifiutato.
Procedura di invio del CTS
- Scrivere una proposta di test: uno sviluppatore di app invia una proposta di test utilizzando
Google Issue Tracker,
descrivendo il problema che è stato identificato e proponendo un test per verificarlo. La proposta deve includere l'ID requisito CDD associato.
Il team di Android esamina la proposta.
- Sviluppare un test CTS: dopo l'approvazione di una proposta, l'utente che l'ha inviata crea un test CTS su AOSP nel ramo di rilascio più recente di Android (
android16-release). Il team di Android esamina il codice e, se accettato, seleziona la modifica e la unisce al ramo di sviluppo interno. Per maggiori dettagli, consulta
Dove devo proporre modifiche ad AOSP?.
Linee guida per la scrittura dei test CTS-D
- Segui la Java Code Style Guide.
- Segui tutti i passaggi descritti in Sviluppo CTS.
- Aggiungi i test al piano di test appropriato:
- Utilizza
include-filters per aggiungere i nuovi test al piano di test CTS-D: platform/cts/tools/cts-tradefed/res/config/cts-developer.xml.
- Utilizza
exclude-filters per escludere i nuovi test dal piano di test CTS principale: platform/cts/tools/cts-tradefed/res/config/cts-developer-exclude.xml.
- Gestisci tutti gli avvisi e i suggerimenti di
errorprone in build_error.log.
- Esegui la rebase delle modifiche su
head. Sono inclusi i piani di test cts-developer.xml e
cts-developer-exclude.xml.
- Collabora con il tuo contatto tecnico di Google per stabilire se il tuo caso di test può essere incluso in un modulo CTS esistente. In caso contrario, ti aiuteranno a creare un nuovo modulo.
- Per ogni nuovo modulo di test creato, crea un file OWNERS nella directory del nuovo modulo di test.
- Il file OWNERS deve contenere le seguenti informazioni, ottenute dal proprietario del test Google con cui collabori:
# Bug component: xxx- Proprietario del test Google ldap
- In
AndroidTest.xml, specifica i seguenti parametri. Consulta i file di esempio (1,
2) per esempi:
Instant_app o not_instant_appsecondary_user o not_secondary_userall_foldable_states o no_foldable_states
- Per specificare il valore minSDK corretto, consulta la documentazione di <uses-sdk>.
- Quando effettui il check-in di nuovi metodi, classi o moduli di test, aggiungili al piano di test CTS-D e li escludi dal piano di test CTS principale nello stesso modo in cui accade per i nuovi test.
Esegui il test CTS-D
Esegui il piano di test CTS-D dalla riga di comando utilizzando run cts --plan cts-developer.
Per eseguire un caso di test specifico, utilizza run cts --include-filter "test_module_name test_name".
Per informazioni sull'esecuzione del CTS completo, consulta Eseguire i test CTS.
Accettazione e rilascio
Una volta inviata una richiesta di test, un team interno la esaminerà per verificare che test un requisito del CDD o un comportamento dell'API documentato. Se viene stabilito che il test verifica la presenza di un requisito o un comportamento valido, il team inoltra questo caso di test a un ingegnere di Google per un'ulteriore revisione. L'ingegnere di Google ti contatterà per fornirti un feedback su come migliorare il test prima che possa essere accettato in CTS.
Per informazioni dettagliate sulla pianificazione dei rilasci di CTS, consulta la sezione Pianificazione dei rilasci e informazioni sui branch.
I campioni di contenuti e codice in questa pagina sono soggetti alle licenze descritte nella Licenza per i contenuti. Java e OpenJDK sono marchi o marchi registrati di Oracle e/o delle sue società consociate.
Ultimo aggiornamento 2025-07-27 UTC.
[[["Facile da capire","easyToUnderstand","thumb-up"],["Il problema è stato risolto","solvedMyProblem","thumb-up"],["Altra","otherUp","thumb-up"]],[["Mancano le informazioni di cui ho bisogno","missingTheInformationINeed","thumb-down"],["Troppo complicato/troppi passaggi","tooComplicatedTooManySteps","thumb-down"],["Obsoleti","outOfDate","thumb-down"],["Problema di traduzione","translationIssue","thumb-down"],["Problema relativo a esempi/codice","samplesCodeIssue","thumb-down"],["Altra","otherDown","thumb-down"]],["Ultimo aggiornamento 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."]]
