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.
Descripción general del conjunto de pruebas de compatibilidad (CTS)
Organiza tus páginas con colecciones
Guarda y categoriza el contenido según tus preferencias.
El conjunto de pruebas de compatibilidad (CTS) es un conjunto de pruebas gratuito y de calidad comercial, y las herramientas que se usan para garantizar que tus dispositivos sean compatibles con Android. El CTS se diseñó para integrarse en tu flujo de trabajo diario, por ejemplo, a través de un sistema de compilación continua. CTS se ejecuta en una computadora de escritorio y ejecuta pruebas directamente en dispositivos conectados o en un emulador. Para obtener una descripción general de la compatibilidad con Android, consulta la Descripción general del programa de compatibilidad de Android.
Figura 1: Pruebas automatizadas de CTS
En la Figura 1, se muestra el proceso de ejecución de pruebas automatizadas de CTS:
Descarga e instala CTS. Este paso también implica configurar el entorno de prueba, la estación de trabajo de prueba y el dispositivo que se está probando o dispositivo en prueba (DUT).
Ejecuta pruebas automatizadas de CTS.
Almacena y revisa los resultados.
Soluciona los problemas y vuelve a ejecutar las pruebas.
Usa CTS para revelar incompatibilidades de forma anticipada y garantizar que tus implementaciones de Android permanezcan compatibles durante todo el proceso de desarrollo.
Componentes de CTS
CTS contiene los siguientes componentes principales:
Federación comercial
Un framework y un entorno de pruebas permiten la ejecución automatizada de pruebas.
Pruebas automatizadas de CTS
Pruebas que usan el framework de Trade Federation y que se pueden ejecutar con el conjunto de pruebas de Trade Federation.
Pruebas del verificador del CTS (CTS-V)
Pruebas que se deben ejecutar de forma manual.
App de CTS Verifier (CTS-V)
Es una app que se usa para realizar pruebas de CTS-V y recopilar los resultados de estas.
Caso de prueba
Es una prueba individual que se ejecuta en el DUT. Los casos de prueba automatizados se escriben en Java como pruebas de JUnit y se empaquetan en archivos APK de Android para ejecutarse en el dispositivo de destino.
Los casos de prueba pueden ser pruebas de unidades o pruebas funcionales. Una prueba de unidades prueba unidades atómicas de código dentro de la plataforma de Android. Por ejemplo, una prueba de unidades podría probar una sola clase de Android.
Una prueba funcional ejercita una combinación de métodos y clases que se usan para un caso de uso específico.
Configuración de la prueba
Un conjunto específico de pruebas automatizadas que se ejecutan en el DUT. Las configuraciones de prueba son archivos en formato XML que se encuentran en WORKING_DIRECTORY/cts/tools/cts-tradefed/res/config.
Hay configuraciones de prueba que contienen todos los casos de prueba automatizados y configuraciones de prueba que contienen un subconjunto de casos de prueba.
Módulo de prueba
Es una configuración de prueba que consta de una colección de casos de prueba para la misma área de función.
Plan de pruebas
Es una configuración de prueba que consta de una colección de módulos de prueba.
Cobertura de pruebas
Los casos de prueba abarcan las siguientes áreas para garantizar la compatibilidad:
Área
Descripción
Pruebas de firma
Para cada versión de Android, hay archivos en formato XML que describen las firmas de todas las APIs públicas que contiene la versión. El CTS contiene una utilidad para verificar esas firmas de API en función de las APIs disponibles en el dispositivo. Los resultados de la verificación de firmas se registran en el archivo en formato XML de los resultados de la prueba.
Pruebas de la API de la plataforma
Prueba las APIs de la plataforma (bibliotecas principales y framework de aplicaciones de Android) como se documenta en el índice de clases del SDK para garantizar la exactitud de la API, incluidas las firmas correctas de clase, atributo y método, el comportamiento correcto del método y las pruebas negativas para garantizar el comportamiento esperado para el manejo incorrecto de parámetros.
Pruebas de Dalvik
Las pruebas se enfocan en probar el formato ejecutable de Dalvik.
Modelo de datos de la plataforma
El CTS prueba el modelo de datos de la plataforma principal tal como se expone a los desarrolladores de aplicaciones a través de proveedores de contenido, como se documenta en el paquete android.provider del SDK (incluidos los contactos, los navegadores y la configuración).
Intentos de la plataforma
El CTS prueba los intents principales de la plataforma, como se documenta en la sección
Intents comunes del SDK.
Permisos de la plataforma
El CTS prueba los permisos principales de la plataforma, como se documenta en el SDK Manifest.permission.
Recursos de la plataforma
El CTS prueba el manejo correcto de los tipos de recursos principales de la plataforma, como se documenta en la
descripción general de los tipos de recursos del SDK. Las pruebas de CTS incluyen pruebas de valores simples, elementos de diseño, nueve parches, animaciones, diseños, estilos y temas, y carga de recursos alternativos.
Próximos pasos
Después de leer este documento, continúa con Configurar 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,["# The Compatibility Test Suite (CTS) overview\n\n*Compatibility Test Suite (CTS)* is a free, commercial-grade test suite and\ntools used to help ensure that your devices are Android compatible. CTS is\nintended to be integrated into your daily workflow, such as through a\ncontinuous build system. CTS runs on a desktop machine and executes tests\ndirectly on attached devices or on an emulator. For an overview of Android compatibility, see [Android compatibility program overview](/docs/compatibility).\n\n**Figure 1.** CTS automated testing.\n\nFigure 1 shows the process of executing CTS automated tests:\n\n1. Download and install CTS. This step also involves setting up the test environment, the testing workstation, and the device you are testing or *device under test (DUT)*\n2. Run CTS automated tests.\n3. Store and review the results.\n4. Troubleshoot issues and rerun tests.\n\nUse CTS to reveal incompatibilities early, and to ensure that your Android\nimplementations remain compatible throughout the development process.\n\nCTS components\n--------------\n\nCTS contains the following major components:\n\n*Trade Federation*\n: A test harness and framework allow for the automated execution of tests.\n\n*CTS automated tests*\n: Tests that use the Trade Federation framework and can be run using the Trade\n Federation test harness.\n\n*CTS Verifier (CTS-V) tests*\n: Tests that must be run manually.\n\n*CTS Verifier (CTS-V) app*\n: An app used to conduct CTS-V tests and collect CTS-V test results.\n\n*Test case*\n\n: An individual test executed on the DUT. Automated test cases are\n written in Java as JUnit tests and packaged Android APK files to run on the\n device target.\n\n Test cases can be *unit tests* or *functional tests*. A unit test tests atomic\n units of code within the Android platform. For example, a unit test might test\n a single Android class.\n\n A functional test exercises a combination of methods and classes used for a\n specific use case.\n\n*Test configuration*\n\n: A specific set of automated tests that are run on the\n DUT. Test configurations are XML files located in\n \u003cvar translate=\"no\"\u003eWORKING_DIRECTORY\u003c/var\u003e`/cts/tools/cts-tradefed/res/config`.\n There are test configurations that contains all automated test cases and test\n configurations that contain a subset of test cases.\n\n*Test module*\n\n: A test configuration consisting of a collection of test cases for the same\n feature area.\n\n*Test plan*\n\n: A test configuration consisting of a collection of test modules.\n\n| **Note:** The Android Open Source Project accepts contributions to improve CTS just as for any other component. Improving the coverage and quality of CTS tests is one of the best ways to contribute to Android. To make contributions to CTS, follow the same process in [Submit code changes](/docs/setup/contribute/submit-patches).\n\nTest coverage\n-------------\n\nTest cases cover the following areas to ensure compatibility:\n\n| Area | Description |\n|----------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|\n| Signature tests | For each Android release, there are XML files describing the signatures of all public APIs contained in the release. The CTS contains a utility to check those API signatures against the APIs available on the device. The results from signature checking are recorded in the test result XML file. |\n| Platform API tests | Test the platform (core libraries and Android Application Framework) APIs as documented in the SDK [Class Index](https://developer.android.com/reference/classes) to ensure API correctness, including correct class, attribute and method signatures, correct method behavior, and negative tests to ensure expected behavior for incorrect parameter handling. |\n| Dalvik tests | The tests focus on testing the Dalvik executable format. |\n| Platform data model | The CTS tests the core platform data model as exposed to application developers through content providers, as documented in the SDK [`android.provider`](https://developer.android.com/reference/android/provider/package-summary) package (including contacts, browsers, and settings) |\n| Platform intents | The CTS tests the core platform intents, as documented in the SDK [Common intents](https://developer.android.com/guide/appendix/g-app-intents). |\n| Platform permissions | The CTS tests the core platform permissions, as documented in the SDK [`Manifest.permission`](https://developer.android.com/reference/android/Manifest.permission). |\n| Platform resources | The CTS tests for correct handling of the core platform resource types, as documented in the SDK [Resource types overview](https://developer.android.com/guide/topics/resources/available-resources). The CTS tests include tests for simple values, drawables, nine-patch, animations, layouts, styles and themes, and loading alternate resources. |\n\nWhat's next\n-----------\n\nAfter reading this document, continue to [Set up CTS](/docs/compatibility/cts/setup)."]]
