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.
Test della piattaforma Android
Mantieni tutto organizzato con le raccolte
Salva e classifica i contenuti in base alle tue preferenze.
Android Open Source Project (AOSP) fornisce diversi strumenti e suite di test per testare varie parti dell'implementazione. Prima di utilizzare le pagine di questa
sezione, devi conoscere i seguenti termini:
- Dispositivo compatibile con Android
- Un dispositivo in grado di eseguire qualsiasi app di terze parti scritta da sviluppatori di terze parti utilizzando l'SDK e l'NDK Android. I dispositivi compatibili con Android devono rispettare i requisiti del Compatibility Definition Document (CDD) e superare la Compatibility Test Suite (CTS). I dispositivi compatibili con Android sono idonei a partecipare all'ecosistema Android, che include la potenziale concessione in licenza di Google Play, la potenziale concessione in licenza della suite di app e API Google Mobile Services (GMS) e l'utilizzo del marchio Android. Chiunque può usare il codice sorgente di Android, ma per essere considerato parte dell'ecosistema Android, un dispositivo deve essere compatibile con Android.
- elemento
- Un log relativo alla compilazione che consente la risoluzione dei problemi locali.
- Compatibility Definition Document (CDD)
- Un documento che elenca i requisiti hardware e software per un
dispositivo compatibile con Android.
- Compatibility Test Suite (CTS)
Una suite di test senza costi di livello commerciale, disponibile per il download come file binario o come codice sorgente in AOSP. Il CTS è un insieme di test di unità progettati per essere integrati nel tuo flusso di lavoro quotidiano. Lo scopo della CTS è rilevare le incompatibilità e garantire che il software rimanga compatibile durante tutto il processo di sviluppo.
I test CTS e della piattaforma non si escludono a vicenda. Ecco alcune linee guida generali:
- Se un test verifica la correttezza dei comportamenti o delle funzioni dell'API del framework e deve essere applicato a tutti i partner OEM, deve essere in CTS.
- Se un test ha lo scopo di rilevare le regressioni durante lo sviluppo della piattaforma, potrebbe richiedere l'autorizzazione privilegiata per essere eseguito e potrebbe dipendere dai dettagli di implementazione (come rilasciato in AOSP), deve essere un test della piattaforma.
- Google Mobile Services (GMS)
Una raccolta di app e API Google che possono essere preinstallate sui dispositivi.
- GoogleTest (GTest)
Un framework di test e simulazione C++. In genere, i file binari GTest accedono a livelli di astrazione di livello inferiore o eseguono IPC non elaborati con vari servizi di sistema. L'approccio di test per GTest è in genere strettamente associato al servizio in fase di test. CTS contiene il framework GTest.
- test di instrumentazione
Un ambiente di esecuzione dei test speciale avviato dal comando am instrument
, in cui il processo dell'app di destinazione viene riavviato e inizializzato con il contesto dell'app di base e un thread di ispezione viene avviato all'interno della macchina virtuale del processo dell'app. CTS contiene test di strumentazione.
- Logcat
Uno strumento a riga di comando che crea un log dei messaggi di sistema, tra cui le tracce dello stack quando il dispositivo genera un errore e i messaggi che hai scritto dalla tua app con la classe Log
.
- logging
Utilizzo di un log per tenere traccia degli eventi del sistema informatico, ad esempio gli errori. Il logging in Android è complesso a causa del mix di standard utilizzati che vengono combinati nello strumento Logcat.
- postsubmit test
Un test Android che viene eseguito quando viene eseguito il commit di una nuova patch in un ramo del kernel comune. Se inserisci aosp_kernel
come nome del ramo parziale, puoi visualizzare un elenco dei rami del kernel con i risultati disponibili. Ad esempio, i risultati per android-mainline
sono disponibili all'indirizzo
https://ci.android.com/builds/branches/aosp_kernel-common-android-mainline/grid.
- presubmit test
Un test utilizzato per impedire l'introduzione di errori nei kernel comuni.
- Federazione commerciale
Chiamato anche Tradefed, è un framework di test continuo progettato per eseguire test su dispositivi Android. Ad esempio,
Tradefed viene utilizzato per eseguire i test della Compatibility Test Suite e della Vendor Test Suite.
- Vendor Test Suite (VTS)
Un insieme di funzionalità complete per
i test di Android, la promozione di un processo di sviluppo basato sui test e l'automazione
del test dell'HAL (Hardware Abstraction Layer) e del kernel del sistema operativo.
Tipi di test della piattaforma
Un test della piattaforma in genere interagisce con uno o più servizi di sistema Android o livelli HAL, esercita le funzionalità dell'oggetto in test e verifica la correttezza del risultato del test. Un test della piattaforma potrebbe:
- (Tipo 1) API del framework di esercizi che utilizzano il framework Android. Le API specifiche in uso possono includere:
- API pubbliche destinate ad app di terze parti
- API nascoste destinate ad app con privilegi, ovvero API di sistema o API private (
@hide
, protected
, package private
)
- (Tipo 2) Richiama direttamente i servizi di sistema Android utilizzando binder non elaborati o proxy IPC.
- (Tipo 3) Interagisci direttamente con gli HAL utilizzando API di basso livello o interfacce IPC.
I test di tipo 1 e 2 sono in genere test di strumentazione, mentre i test di tipo 3 sono solitamente GTest.
Passaggi successivi
Ecco un elenco di documenti che puoi leggere per informazioni più dettagliate:
Se non hai studiato l'architettura di Android, consulta
Panoramica dell'architettura.
Se stai creando un dispositivo compatibile con Android, consulta la panoramica del Programma di compatibilità Android.
Per integrare i test di misurazione, strumentazione, metrica e host JAR
in un servizio di test continuo della piattaforma, consulta
Flusso di lavoro di sviluppo dei test.
Per rilevare e rafforzare i tuoi dispositivi contro le vulnerabilità, consulta Test di sicurezza.
Per scoprire di più sul test delle implementazioni di HAL e kernel, consulta
Vendor Test Suite (VTS) e infrastruttura.
Per i test delle app, leggi
Nozioni di base sui test delle app Android
e svolgi il corso Android avanzato in Kotlin 05.1:Nozioni di base sui test
utilizzando i
samples forniti.
Scopri i test di pre-invio di base a tua disposizione tramite i hook del repository.
Questi hook possono essere utilizzati per eseguire linters, controllare la formattazione e attivare i test di unità prima di procedere, ad esempio il caricamento di un commit. Questi hook sono disattivati per impostazione predefinita. Per ulteriori informazioni, consulta AOSP Preupload
Hooks.
Per scoprire di più sul logging, consulta Informazioni sul logging.
Per scoprire come eseguire il debug del codice Android, consulta
Eseguire il debug del codice della piattaforma Android nativa.
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,["# 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)."]]