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 acquisire familiarità con 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 gli SDK e 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 possono partecipare all'ecosistema Android, che include la potenziale licenza di Google Play, la potenziale licenza della suite di app e API Google Mobile Services (GMS) e l'utilizzo del marchio Android. Chiunque può utilizzare il codice sorgente di Android, ma per essere considerato parte dell'ecosistema Android, un dispositivo deve essere compatibile con Android.
- artifact
- Un log correlato alla build che consente la risoluzione dei problemi locali.
- Compatibility Definition Document (CDD)
- Un documento che elenca i requisiti software e hardware per un dispositivo compatibile con Android.
- Suite di test di compatibilità (CTS)
- Una suite di test senza costi di livello commerciale, disponibile per il download come binario o come origine in AOSP. Il CTS è un insieme di test delle unità progettati per essere integrati nel tuo flusso di lavoro quotidiano. Lo scopo del CTS è quello di rivelare 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 delle funzioni o dei comportamenti dell'API framework e deve essere applicato a tutti i partner OEM, deve trovarsi in CTS.
- Se un test ha lo scopo di rilevare regressioni durante lo sviluppo della piattaforma, potrebbe richiedere un'autorizzazione privilegiata per essere eseguito e potrebbe dipendere dai dettagli di implementazione (come rilasciati 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++. I file binari GTest in genere accedono a livelli di astrazione di livello inferiore o eseguono IPC non elaborati su vari servizi di sistema. L'approccio di test per GTest è in genere strettamente accoppiato 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 di base dell'app e viene avviato un thread di strumentazione 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 analisi dello stack di 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. La registrazione in Android è complessa a causa del mix di standard utilizzati che sono combinati nello strumento Logcat. 
- postsubmit test
- Un test Android eseguito quando viene eseguito il commit di una nuova patch in un ramo del kernel comune. Se inserisci - aosp_kernelcome nome parziale del ramo, puoi visualizzare un elenco dei rami del kernel con i risultati disponibili. Ad esempio, i risultati per- android-mainlinesono 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 del Commercio
- Chiamato anche Tradefed, un framework di test continuo progettato per eseguire test su dispositivi Android. Ad esempio, Tradefed viene utilizzato per eseguire i test di Compatibility Test Suite e Vendor Test Suite. 
- Vendor Test Suite (VTS)
- Un insieme di funzionalità complete per i test Android, che promuovono un processo di sviluppo basato sui test e automatizzano i test del livello di astrazione hardware (HAL) 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 o livelli HAL di Android, esercita le funzionalità del soggetto in esame e verifica la correttezza del risultato del test. Un test della piattaforma potrebbe:
- (Tipo 1) API del framework di allenamento che utilizzano il framework Android. Le API specifiche utilizzate possono includere:
- API pubbliche destinate ad app di terze parti
- API nascoste destinate ad app con privilegi, ovvero API di sistema o
API private (@hideoprotected,package private)
 
- (Tipo 2) Richiama direttamente i servizi di sistema Android utilizzando binder o proxy IPC non elaborati.
- (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 di solito GTest.
Passaggi successivi
Ecco un elenco di documenti che puoi consultare per informazioni più dettagliate:
- Se non hai studiato l'architettura di Android, consulta la Panoramica dell'architettura. 
- Se stai creando un dispositivo compatibile con Android, consulta la panoramica del programma di compatibilità Android. 
- Per integrare i test di strumentazione, funzionali, delle metriche e dell'host JAR in un servizio di test continuo della piattaforma, consulta Flusso di lavoro di sviluppo dei test. 
- Per rilevare e proteggere i tuoi dispositivi dalle vulnerabilità, vedi Test di sicurezza. 
- Per informazioni su come testare le implementazioni HAL e del kernel, vedi Vendor Test Suite (VTS) e infrastruttura. 
- Per il test delle app, leggi Nozioni di base sui test delle app per Android e svolgi l'esercizio Advanced Android in Kotlin 05.1:Testing Basics utilizzando gli esempi forniti. 
- Scopri di più sui test di pre-invio di base a tua disposizione tramite gli hook del repository. Questi hook possono essere utilizzati per eseguire linters, controllare la formattazione e attivare test unitari prima di procedere, ad esempio con il caricamento di un commit. Questi hook sono disattivati per impostazione predefinita. Per ulteriori informazioni, consulta Hook di pre-caricamento AOSP. 
- Per saperne di più sul logging, vedi Informazioni sul logging. 
- Per capire come eseguire il debug del codice Android, consulta Eseguire il debug del codice della piattaforma Android nativa.