À partir du 27 mars 2025, nous vous recommandons d'utiliser android-latest-release au lieu de aosp-main pour créer et contribuer à AOSP. Pour en savoir plus, consultez la section Modifications apportées à AOSP.
CTS optimisé par les développeurs
Restez organisé à l'aide des collections
Enregistrez et classez les contenus selon vos préférences.
Cette page présente les consignes d'utilisation de CTS-D (Developer-Powered CTS).
Couverture des tests
CTS-D, comme CTS et CTS Verifier, ne peut appliquer que les éléments suivants:
- Toutes les API publiques décrites dans le SDK du développeur (developer.android.com) pour un certain niveau d'API.
- Toutes les exigences obligatoires incluses dans le document de définition de la compatibilité Android (CDD) pour un niveau d'API donné.
Les exigences non obligatoires, telles que "FORTEMENT RECOMMANDÉ", "DEVRA" et "PEUT", sont facultatives et ne peuvent pas être testées à l'aide de CTS.
Étant donné que toutes les API et les exigences du CDD sont associées à un niveau d'API spécifique, tous les tests CTS (CTS, CTS-D et CTS Verifier) sont associés au même niveau d'API que leurs API ou exigences associées. Si une API spécifique est abandonnée ou modifiée, son test correspondant doit être abandonné ou mis à jour.
Règles de création de tests CTS
- Un test doit produire le même résultat objectif de manière cohérente.
- Un test doit déterminer si un appareil est conforme ou non en le testant une seule fois.
- Les créateurs de tests doivent supprimer tous les facteurs possibles qui pourraient affecter les résultats des tests.
- Si un appareil nécessite une certaine condition/configuration/configuration matérielle, cette configuration doit être clairement définie dans le message de validation. Pour obtenir des exemples d'instructions de configuration, consultez Configurer CTS.
- Le test ne doit pas s'exécuter pendant plus de six heures à la fois. Si le test doit s'exécuter plus longtemps, veuillez inclure le raisonnement dans votre proposition de test afin que nous puissions l'examiner.
Voici un exemple d'ensemble de conditions de test pour tester une restriction d'application:
- Le Wi-Fi est stable (pour un test qui repose sur le Wi-Fi).
- L'appareil reste immobile pendant le test (ou non, selon le test).
- L'appareil est débranché de toute source d'alimentation et la batterie est chargée à X %.
- Aucune application, aucun service de premier plan ni aucun service en arrière-plan n'est en cours d'exécution, à l'exception du CTS.
- L'écran est éteint pendant l'exécution de CTS.
- L'appareil n'est PAS
isLowRamDevice.
- Les restrictions de l'économiseur de batterie / des applications n'ont pas été modifiées par rapport à l'état "prêt à l'emploi".
Éligibilité aux tests
Nous acceptons les nouveaux tests qui appliquent un comportement qui n'est pas testé par les tests CTS, CTS Verifier ou CTS-D existants. Tout test qui vérifie un comportement en dehors du champ d'application de notre couverture de test sera rejeté.
Processus d'envoi des CTS
- Écrire une proposition de test:un développeur d'applications envoie une proposition de test à l'aide de Google Issue Tracker, décrivant le problème identifié et proposant un test pour le vérifier. La proposition doit inclure l'ID de l'exigence de la CDD associé.
L'équipe Android examine la proposition.
- Développer un test CTS:une fois qu'une proposition est approuvée, son auteur crée un test CTS sur AOSP dans la branche de la dernière version d'Android (
android16-release). L'équipe Android examine le code et, si elle l'accepte, sélectionne la modification et la fusionne dans la branche de développement interne. Pour en savoir plus, consultez Où proposer des modifications à l'AOSP ?.
Consignes de rédaction des tests CTS-D
- Suivez le guide de style du code Java.
- Suivez toutes les étapes décrites dans la section Développement CTS.
- Ajoutez vos tests au plan de test approprié :
- Utilisez
include-filters pour ajouter vos nouveaux tests au plan de test CTS-D: platform/cts/tools/cts-tradefed/res/config/cts-developer.xml.
- Utilisez
exclude-filters pour exclure vos nouveaux tests du plan de test CTS principal: platform/cts/tools/cts-tradefed/res/config/cts-developer-exclude.xml.
- Gérez tous les avertissements et suggestions
errorprone dans build_error.log.
- Rebasez vos modifications sur
head. Cela inclut les plans de test cts-developer.xml et cts-developer-exclude.xml.
- Contactez votre ingénieur Google pour déterminer si votre cas de test peut être inclus dans un module CTS existant. Si ce n'est pas possible, ils vous aideront à créer un nouveau module.
- Pour chaque nouveau module de test créé, créez un fichier OWNERS dans le répertoire du nouveau module de test.
- Votre fichier OWNERS doit contenir les informations suivantes, obtenues auprès du propriétaire de test Google avec lequel vous travaillez:
# Bug component: xxx- LDAP du propriétaire de test Google
- Dans
AndroidTest.xml, spécifiez les paramètres suivants. Reportez-vous aux exemples de fichiers (1, 2) pour en savoir plus :
Instant_app ou not_instant_appsecondary_user ou not_secondary_userall_foldable_states ou no_foldable_states
- Pour spécifier la version minimale de SDK correcte, consultez la documentation <uses-sdk>.
- Lorsque vous envoyez de nouvelles méthodes, classes ou modules de test, ajoutez-les au plan de test CTS-D et excluez-les du plan de test CTS principal de la même manière que pour les nouveaux tests.
Exécuter votre test CTS-D
Exécutez le plan de test CTS-D à partir de la ligne de commande à l'aide de run cts --plan cts-developer.
Pour exécuter un scénario de test spécifique, utilisez run cts --include-filter "test_module_name test_name".
Pour savoir comment exécuter le CTS complet, consultez Exécuter des tests CTS.
Acceptation et publication
Une fois une demande de test envoyée, une équipe interne l'examinera pour s'assurer qu'elle teste une exigence de CDD ou un comportement d'API documenté. Si l'équipe détermine que le test vérifie une exigence ou un comportement valide, elle transmettra ce cas de test à un ingénieur Google pour examen approfondi. L'ingénieur Google vous contactera pour vous indiquer comment améliorer le test avant qu'il ne puisse être accepté dans le CTS.
Pour en savoir plus sur le calendrier de publication du CTS, consultez la section Calendrier de publication et informations sur la branche.
Le contenu et les exemples de code de cette page sont soumis aux licences décrites dans la Licence de contenu. Java et OpenJDK sont des marques ou des marques déposées d'Oracle et/ou de ses sociétés affiliées.
Dernière mise à jour le 2025/07/27 (UTC).
[[["Facile à comprendre","easyToUnderstand","thumb-up"],["J'ai pu résoudre mon problème","solvedMyProblem","thumb-up"],["Autre","otherUp","thumb-up"]],[["Il n'y a pas l'information dont j'ai besoin","missingTheInformationINeed","thumb-down"],["Trop compliqué/Trop d'étapes","tooComplicatedTooManySteps","thumb-down"],["Obsolète","outOfDate","thumb-down"],["Problème de traduction","translationIssue","thumb-down"],["Mauvais exemple/Erreur de code","samplesCodeIssue","thumb-down"],["Autre","otherDown","thumb-down"]],["Dernière mise à jour le 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."]]
