À 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.
Tests de la plate-forme Android
Restez organisé à l'aide des collections
Enregistrez et classez les contenus selon vos préférences.
Le projet Android Open Source (AOSP) fournit plusieurs outils et suites de tests pour tester différentes parties de votre implémentation. Avant d'utiliser les pages de cette section, vous devez connaître les termes suivants:
- Un appareil compatible avec Android
- Appareil pouvant exécuter n'importe quelle application tierce écrite par des développeurs tiers à l'aide du SDK et du NDK Android. Les appareils compatibles avec Android doivent respecter les exigences du document de définition de la compatibilité (CDD) et réussir les tests de la suite de tests de compatibilité (CTS). Les appareils compatibles avec Android peuvent participer à l'écosystème Android, ce qui inclut la licence potentielle de Google Play, la licence potentielle de la suite d'applications et d'API Google Mobile Services (GMS), et l'utilisation de la marque Android. Tout le monde peut utiliser le code source Android, mais pour être considéré comme faisant partie de l'écosystème Android, un appareil doit être compatible avec Android.
- artefact
- Journal lié à la compilation qui permet de résoudre les problèmes localement.
- Document de définition de la compatibilité (CDD)
- Document qui énumère les exigences logicielles et matérielles d'un appareil compatible avec Android.
- La suite de tests de compatibilité
Suite de test sans frais de qualité professionnelle, disponible en téléchargement au format binaire ou source dans AOSP. Le CTS est un ensemble de tests unitaires conçus pour être intégrés à votre workflow quotidien. L'objectif du CTS est de révéler les incompatibilités et de s'assurer que le logiciel reste compatible tout au long du processus de développement.
Les tests CTS et les tests de plate-forme ne s'excluent pas mutuellement. Voici quelques consignes générales:
- Si un test affirme l'exactitude des fonctions ou des comportements de l'API du framework, et que le test doit être appliqué aux partenaires OEM, il doit être dans CTS.
- Si un test vise à détecter des régressions lors du développement de la plate-forme, et qu'il peut nécessiter une autorisation privilégiée pour être effectué, et qu'il peut dépendre des détails d'implémentation (tels que publiés dans AOSP), il doit s'agir d'un test de plate-forme.
- Services Google Mobile (GMS)
Ensemble d'applications et d'API Google pouvant être préinstallées sur des appareils.
- GoogleTest (GTest)
Framework de test et de simulation C++. Les binaires GTest accèdent généralement à des couches d'abstraction de niveau inférieur ou effectuent une IPC brute sur différents services système. L'approche de test pour GTest est généralement étroitement liée au service testé. CTS contient le framework GTest.
- test d'instrumentation
Environnement d'exécution de test spécial lancé par la commande am instrument
, dans lequel le processus d'application ciblé est redémarré et initialisé avec un contexte d'application de base, et un thread d'instrumentation est lancé dans la machine virtuelle du processus d'application. CTS contient des tests d'instrumentation.
- Logcat
Outil de ligne de commande qui crée un journal des messages système, y compris les traces de la pile enregistrées lorsque l'appareil génère une erreur et les messages que vous avez écrits à partir de votre application avec la classe Log
.
- journalisation
Utilisation d'un journal pour suivre les événements du système informatique, tels que les erreurs. La journalisation dans Android est complexe en raison du mélange de normes utilisées qui sont combinées dans l'outil Logcat.
- test postsubmit
Test Android effectué lorsqu'un nouveau correctif est validé dans une branche de kernel commune. En saisissant aosp_kernel
comme nom de branche partiel, vous pouvez afficher une liste de branches du kernel avec des résultats disponibles. Par exemple, les résultats pour android-mainline
sont disponibles sur https://ci.android.com/builds/branches/aosp_kernel-common-android-mainline/grid.
- test avant envoi
Test utilisé pour éviter l'introduction de défaillances dans les noyaux communs.
- Fédération du commerce
Également appelé Tradefed, il s'agit d'un framework de test continu conçu pour exécuter des tests sur des appareils Android. Par exemple, Tradefed permet d'exécuter des tests Compatibility Test Suite et Vendor Test Suite.
- Suite de tests du fournisseur (VTS)
Ensemble de fonctionnalités étendues pour les tests Android, la promotion d'un processus de développement basé sur les tests et l'automatisation des tests de la couche d'abstraction matérielle (HAL) et du noyau de l'OS.
Types de tests de plate-forme
Un test de plate-forme interagit généralement avec un ou plusieurs des services système Android ou des couches HAL, exécute les fonctionnalités de l'objet testé et vérifie la validité du résultat du test. Un test de plate-forme peut:
- (Type 1) Exercice sur les API du framework à l'aide du framework Android. Les API spécifiques utilisées peuvent inclure les suivantes :
- API publiques destinées aux applications tierces
- API masquées destinées aux applications privilégiées, à savoir les API système ou les API privées (
@hide
, protected
ou package private
)
- (Type 2) Appelez directement les services système Android à l'aide de liaisons brutes ou de proxys IPC.
- (Type 3) Interagir directement avec les HAL à l'aide d'API de bas niveau ou d'interfaces IPC.
Les tests de type 1 et 2 sont généralement des tests d'instrumentation, tandis que les tests de type 3 sont généralement des GTests.
Et maintenant ?
Voici une liste de documents que vous pouvez consulter pour en savoir plus:
Si vous n'avez pas étudié l'architecture Android, consultez la section Présentation de l'architecture.
Si vous créez un appareil compatible avec Android, consultez la présentation du programme de compatibilité Android.
Pour intégrer des tests d'instrumentation, fonctionnels, métriques et d'hôte JAR à un service de test continu de plate-forme, consultez le workflow de développement de test.
Pour détecter les failles de vos appareils et les renforcer, consultez Tests de sécurité.
Pour en savoir plus sur le test de vos implémentations de HAL et de kernel, consultez la section Suite de tests du fournisseur (VTS) et infrastructure.
Pour tester des applications, consultez Principes de base des tests d'applications Android et suivez le cours Développement Android avancé en Kotlin 05.1:Principes de base des tests à l'aide des exemples fournis.
Découvrez les tests de présoumission de base disponibles via les hooks de dépôt.
Ces hooks peuvent être utilisés pour exécuter des linters, vérifier la mise en forme et déclencher des tests unitaires avant de continuer, par exemple en important un commit. Ces hooks sont désactivés par défaut. Pour en savoir plus, consultez la section Hooks de préchargement AOSP.
Pour en savoir plus sur la journalisation, consultez Comprendre la journalisation.
Pour savoir comment déboguer du code Android, consultez Déboguer le code natif de la plate-forme Android.
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,["# Android platform testing\n\nAndroid Open Source Project (AOSP) provides several tools and test suites\nfor testing various parts of your implementation. Before using the pages in this\nsection, you should be familiar with the following terms:\n\n*Android-compatible device*\n: A device that can run any third-party app written by third-party developers\n using the Android SDK and NDK. Android-compatible devices must adhere to the\n requirements of the\n [Compatibility Definition Document (CDD)](#CDD) and pass the\n [Compatibility Test Suite (CTS)](#cts). Android-compatible\n devices are eligible to participate in the Android ecosystem, which includes\n potential licensure of Google Play, potential licensure of the\n [Google Mobile Services (GMS)](#gms) suite of\n app and APIs, and use of the Android trademark. Anyone is welcome to\n use the Android source code, but to be considered part of the Android ecosystem,\n a device must be Android compatible.\n\n*artifact*\n: A build-related log that enables local troubleshooting.\n\n*Compatibility Definition Document (CDD)*\n: A document that enumerates the software and hardware requirements for an\n Android-compatible device.\n\n*Compatibility Test Suite (CTS)*\n\n: A free, commercial-grade test suite, available for download as a binary or as\n source in AOSP. The CTS is a set of unit tests designed to be integrated into\n your daily workflow. The intent of CTS is to reveal incompatibilities, and\n ensure that the software remains compatible throughout the development process.\n\n CTS and platform tests aren't mutually exclusive. Here are some general\n guidelines:\n\n - If a test is asserting correctness of framework API functions or behaviors, and the test should be enforced across OEM partners, it should be in CTS.\n - If a test is intended to catch regressions during platform development, and might require privileged permission to carry out, and might be dependent on implementation details (as released in AOSP), it should be a platform test.\n\n*Google Mobile Services (GMS)*\n\n: A collection of Google apps and APIs that can be preinstalled on devices.\n\n*GoogleTest (GTest)*\n\n: A C++ testing and mocking framework. GTest binaries typically\n access lower-level abstraction layers or perform raw IPC against various system\n services. The testing approach for GTest is usually tightly coupled with the\n service being tested. CTS contains the GTest framework.\n\n*instrumentation test*\n\n: A special test execution environment\n launched by the `am instrument` command, where the targeted app process\n is restarted and initialized with basic app context, and an\n instrumentation thread is started inside the app process virtual\n machine. CTS contains instrumentation tests.\n\n*Logcat*\n\n: A command-line tool that creates a log of system messages, including\n stack traces of when the device throws an error and messages that you have\n written from your app with the `Log` class.\n\n*logging*\n\n: Using a log to keep track of computer system events, such\n as errors. Logging in Android is complex due to the mix of standards used that\n are combined in the Logcat tool.\n\n*postsubmit test*\n\n: An Android test that is performed when a new patch is committed to a\n common kernel branch. By entering `aosp_kernel` as a partial branch name, you\n can see a list of kernel branches with results available. For example, results\n for `android-mainline` can be found at\n \u003chttps://ci.android.com/builds/branches/aosp_kernel-common-android-mainline/grid\u003e.\n\n*presubmit test*\n\n: A test used to prevent failures from being introduced into the\n common kernels.\n\n*Trade Federation*\n\n: Also called Tradefed, a continuous test\n framework designed for running tests on Android devices. For example,\n Tradefed is used to run Compatibility Test Suite and Vendor Test Suite tests.\n\n*Vendor Test Suite (VTS)*\n\n: A set of extensive capabilities for\n Android testing, promoting a test-driven development process, and automating\n hardware abstraction layer (HAL) and OS kernel testing.\n\nPlatform test types\n-------------------\n\nA platform test typically interacts with one or more of the Android system\nservices or HAL layers, exercises the\nfunctionalities of the subject under test, and asserts correctness of the\ntesting outcome. A platform test might:\n\n- (Type 1) Exercise framework APIs using Android framework. Specific APIs being exercised can include:\n - Public APIs intended for third-party apps\n - Hidden APIs intended for privileged apps, namely system APIs or private APIs (`@hide`, or `protected`, `package private`)\n- (Type 2) Invoke Android system services using raw binder or IPC proxies directly.\n- (Type 3) Interact directly with HALs using low-level APIs or IPC interfaces.\n\nType 1 and 2 tests are typically instrumentation tests, while type 3 tests are\nusually GTests.\n\nWhat's next?\n------------\n\nHere is a list of documents that you can read for more detailed information:\n\n- If you haven't studied Android architecture, see\n [Architecture overview](/docs/core/architecture).\n\n- If you're creating an Android-compatible device, see\n the [Android compatibility program overview](/docs/compatibility/overview).\n\n- To integrate instrumentation, functional, metric, and JAR host tests\n into a platform continuous testing service, see\n [Test development workflow](/docs/core/tests/development).\n\n- To detect and harden your devices against vulnerabilities,\n see [Security testing](/docs/security/test/fuzz-sanitize).\n\n- To learn about testing your HAL and kernel implementations, see\n [Vendor Test Suite (VTS) and infrastructure](/docs/core/tests/vts).\n\n- For app testing, read\n [Fundamentals of testing Android\n apps](https://developer.android.com/training/testing/fundamentals)\n and conduct the [Advanced Android in Kotlin 05.1:Testing\n Basics](https://codelabs.developers.google.com/codelabs/advanced-android-kotlin-training-testing-basics/index.html)\n using the\n [samples](https://github.com/android/testing-samples) provided.\n\n- Learn about the basic presubmit testing available to you through repo hooks.\n These hooks can be used to run linters, check formatting, and trigger unit\n tests before proceeding, such as uploading a commit. These hooks are disabled\n by default. For further information, see [AOSP Preupload\n Hooks](https://android.googlesource.com/platform/tools/repohooks/+/refs/heads/android16-release/README.md).\n\n- To read more about logging, see [Understand logging](/docs/core/tests/debug/understanding-logging).\n\n- To understand how to debug Android code, see\n [Debug native Android platform code](/docs/core/tests/debug)."]]