A partir del 27 de marzo de 2025, te recomendamos que uses android-latest-release en lugar de aosp-main para compilar y contribuir a AOSP. Para obtener más información, consulta Cambios en AOSP.
CTS con tecnología de desarrollador
Organiza tus páginas con colecciones
Guarda y categoriza el contenido según tus preferencias.
En esta página, se describen los lineamientos de uso de CTS con tecnología de desarrollador (CTS-D).
Cobertura de pruebas
CTS-D, al igual que CTS y el verificador de CTS, solo puede aplicar lo siguiente:
- Todas las APIs públicas que se describen en el SDK para desarrolladores (developer.android.com) para un nivel de API determinado
- Todos los requisitos que DEBEN incluirse en el documento de definición de compatibilidad de Android (CDD) para un nivel de API determinado.
Los requisitos que no son OBLIGATORIOS, como ALTAMENTE RECOMENDADO, DEBERÍA, PUEDE, son opcionales y no se pueden probar con CTS.
Debido a que todas las APIs y los requisitos del CDD están vinculados a un nivel de API específico, todas las pruebas de CTS (CTS, CTS-D y CTS Verifier) están vinculadas al mismo nivel de API que sus APIs o requisitos asociados. Si una API específica deja de estar disponible o cambia,
la prueba correspondiente debe dejar de estar disponible o actualizarse.
Reglas de creación de pruebas de CTS
- Una prueba debe producir el mismo resultado objetivo de forma coherente.
- Una prueba debe determinar si un dispositivo es aprobado o no probándolo una vez sin configurarlo.
- Los creadores de pruebas deben quitar todos los factores posibles que puedan afectar los resultados de las pruebas.
- Si un dispositivo necesita una condición, un entorno o una configuración de hardware específicos, esa configuración debe definirse claramente en el mensaje de confirmación. Para obtener instrucciones de configuración de ejemplo, consulta Cómo configurar CTS.
- La prueba no debe ejecutarse durante más de 6 horas a la vez. Si necesita ejecutarse durante más tiempo, incluye el razonamiento en tu propuesta de prueba para que podamos revisarla.
El siguiente es un ejemplo de un conjunto de condiciones de prueba para probar una restricción de app:
- La red Wi-Fi es estable (para una prueba que depende de Wi-Fi).
- El dispositivo permanece inmóvil durante la prueba (o no, según la prueba).
- El dispositivo está desconectado de cualquier fuente de alimentación con un porcentaje X de batería.
- No se están ejecutando apps, servicios en primer plano ni servicios en segundo plano, excepto por CTS.
- La pantalla está apagada mientras se ejecuta CTS.
- El dispositivo NO es
isLowRamDevice.
- No se cambiaron las restricciones del Ahorro de batería ni de las apps desde el estado "listo para usar".
Cómo probar la elegibilidad
Aceptamos pruebas nuevas que apliquen un comportamiento que no se pruebe con las pruebas existentes de CTS, CTS Verifier o CTS-D. Se rechazará cualquier prueba que verifique un comportamiento fuera del alcance de nuestra cobertura de pruebas.
Proceso de envío de CTS
- Escribir una propuesta de prueba: Un desarrollador de apps envía una propuesta de prueba con la herramienta de seguimiento de errores de Google, en la que describe el problema que se identificó y propone una prueba para verificarlo. La propuesta debe incluir el ID del requisito de la CDD asociado.
El equipo de Android revisa la propuesta.
- Desarrolla una prueba de CTS: Después de que se aprueba una propuesta, quien la envía crea una prueba de CTS en AOSP en la rama de la versión más reciente de Android (
android16-release). El equipo de Android revisa el código y, si se acepta, selecciona el cambio y lo combina con la rama de desarrollo interna. Para obtener más información, consulta ¿Dónde debo proponer cambios en AOSP?.
Lineamientos para la redacción de pruebas de CTS-D
- Sigue la Guía de estilo de código Java.
- Sigue todos los pasos que se describen en Desarrollo de CTS.
- Agrega tus pruebas al plan de prueba adecuado:
- Usa
include-filters para agregar tus pruebas nuevas al plan de pruebas de CTS-D: platform/cts/tools/cts-tradefed/res/config/cts-developer.xml.
- Usa
exclude-filters para excluir tus pruebas nuevas del plan de pruebas de CTS principal: platform/cts/tools/cts-tradefed/res/config/cts-developer-exclude.xml.
- Controla todas las advertencias y sugerencias de
errorprone en build_error.log.
- Vuelve a basar los cambios en
head. Esto incluye los planes de prueba cts-developer.xml y cts-developer-exclude.xml.
- Trabaja con tu contacto de Ingeniería de Google para determinar si tu caso de prueba
puede incluirse en un módulo de CTS existente. Si no es posible, te ayudarán a
crear uno nuevo.
- Para cada módulo de prueba nuevo que crees, crea un archivo OWNERS en el directorio del módulo de prueba nuevo.
- Tu archivo OWNERS debe contener la siguiente información, obtenida del
propietario de pruebas de Google con el que estás trabajando:
# Bug component: xxx- LDAP del propietario de prueba de Google
- En
AndroidTest.xml, especifica los siguientes parámetros. Consulta los archivos de muestra (1, 2) para ver ejemplos:
Instant_app o not_instant_appsecondary_user o not_secondary_userall_foldable_states o no_foldable_states
- Para especificar el minSDK correcto, consulta la documentación de <uses-sdk>.
- Cuando revises métodos, clases o módulos de prueba nuevos, agrégalos al plan de pruebas de CTS-D y exclúyelos del plan de pruebas principal de CTS de la misma manera que lo haces con las pruebas nuevas.
Ejecuta la prueba CTS-D
Ejecuta el plan de pruebas de CTS-D desde la línea de comandos con run cts --plan cts-developer.
Para ejecutar un caso de prueba específico, usa run cts --include-filter "test_module_name test_name".
Para obtener información sobre cómo ejecutar el CTS completo, consulta Cómo ejecutar pruebas de CTS.
Aceptación y lanzamiento
Una vez que se envíe una solicitud de prueba, un equipo interno la revisará para asegurarse de que pruebe un requisito de CDD o un comportamiento documentado de la API. Si se determina que la prueba está verificando un requisito o comportamiento válido, el equipo reenviará este caso de prueba a un ingeniero de Google para que lo revise en más detalle. El ingeniero de Google se comunicará contigo para enviarte comentarios sobre cómo mejorar la prueba antes de que se pueda aceptar en CTS.
Consulta la sección Información de las ramas y el programa de lanzamientos para obtener detalles sobre el programa de lanzamientos de CTS.
El contenido y las muestras de código que aparecen en esta página están sujetas a las licencias que se describen en la Licencia de Contenido. Java y OpenJDK son marcas registradas de Oracle o sus afiliados.
Última actualización: 2025-07-27 (UTC)
[[["Fácil de comprender","easyToUnderstand","thumb-up"],["Resolvió mi problema","solvedMyProblem","thumb-up"],["Otro","otherUp","thumb-up"]],[["Falta la información que necesito","missingTheInformationINeed","thumb-down"],["Muy complicado o demasiados pasos","tooComplicatedTooManySteps","thumb-down"],["Desactualizado","outOfDate","thumb-down"],["Problema de traducción","translationIssue","thumb-down"],["Problema con las muestras o los códigos","samplesCodeIssue","thumb-down"],["Otro","otherDown","thumb-down"]],["Última actualización: 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."]]
