AOSP fornisce diversi strumenti e suite di test per testare varie parti dell'implementazione. Prima di continuare con questa sezione, è necessario avere 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 Android SDK e NDK. I dispositivi compatibili con Android devono rispettare i requisiti del Compatibility Definition Document (CDD) e superare il Compatibility Test Suite (CTS) . I dispositivi compatibili con Android sono idonei a partecipare all'ecosistema Android, che include la potenziale licenza del Google Play Store, la potenziale licenza della suite di app e API Google Mobile Services (GMS) e l'uso del marchio Android. Chiunque è libero di utilizzare il codice sorgente Android, ma per essere considerato parte dell'ecosistema Android, un dispositivo deve essere compatibile con Android.
- artefatto
- Gli artefatti sono log relativi alla build che consentono la risoluzione dei problemi locali.
- Documento di definizione della compatibilità (CDD)
- Un documento che enumera i requisiti software e hardware per un dispositivo compatibile con Android.
- Suite di test di compatibilità (CTS)
Una suite di test gratuita di livello commerciale, disponibile per il download come binario o come sorgente in AOSP. Il CTS è un insieme di test unitari progettati per essere integrati nel flusso di lavoro quotidiano. L'intento di CTS è quello di rivelare 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 conferma la correttezza delle funzioni o dei comportamenti dell'API del framework e deve essere applicato a tutti i partner OEM, dovrebbe essere in CTS.
- Se un test ha lo scopo di rilevare regressioni durante lo sviluppo della piattaforma e potrebbe richiedere un'autorizzazione privilegiata per essere eseguito e potrebbe dipendere dai dettagli di implementazione (come rilasciati in AOSP), dovrebbe essere un test della piattaforma.
- Servizi mobili Google (GMS)
Una raccolta di app e API Google che possono essere preinstallate sui dispositivi.
- GoogleTest (GTest)
GTest è un framework di testing e mocking 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 è solitamente strettamente correlato al servizio da testare. CTS contiene il framework GTest.
- prova della strumentazione
Un test di strumentazione fornisce uno speciale ambiente di esecuzione del test avviato dal comando
am instrument
, in cui il processo dell'applicazione di destinazione viene riavviato e inizializzato con il contesto dell'applicazione di base e un thread di strumentazione viene avviato all'interno della macchina virtuale del processo dell'applicazione. CTS contiene test strumentali.- Logcat
Logcat è uno strumento da riga di comando che crea un registro dei messaggi di sistema, incluse le tracce dello stack di quando il dispositivo genera un errore e i messaggi che hai scritto dalla tua app con la classe
Log
.- registrazione
La registrazione si riferisce all'utilizzo di un registro per tenere traccia degli eventi del sistema informatico, come gli errori. L'accesso in Android è complesso a causa del mix di standard utilizzati combinati nello strumento Logcat.
- test post-invio
I test post-invio di Android vengono eseguiti quando una nuova patch viene inserita in un ramo comune del kernel. Inserendo
aosp_kernel
come nome parziale del ramo, puoi visualizzare un elenco di rami del kernel con i risultati disponibili. Ad esempio, i risultati perandroid-mainline
possono essere trovati su https://ci.android.com/builds/branches/aosp_kernel-common-android-mainline/grid .- test preliminare
I test di preinvio vengono utilizzati per impedire l'introduzione di errori nei kernel comuni.
- Federazione dei Mercanti
Trade Federation, chiamata anche Tradefed, è un framework di test continuo progettato per eseguire test su dispositivi Android. Ad esempio, Tradefed viene utilizzato per eseguire i test Compatibility Test Suite e Vendor Test Suite.
- Suite di test del fornitore (VTS)
Android Vendor Test Suite (VTS) offre funzionalità estese per i test Android, promuove un processo di sviluppo basato sui test e automatizza i test dell'HAL e del kernel del sistema operativo.
Tipi di test della piattaforma
Un test della piattaforma in genere interagisce con uno o più servizi del sistema Android o livelli HAL (Hardware Abstraction Layer), esercita le funzionalità del soggetto sottoposto a test e asserisce la correttezza del risultato del test. Un test della piattaforma potrebbe:
- (tipo 1) Esercitare le API del framework utilizzando il framework Android. Le API specifiche esercitate possono includere:
- API pubbliche destinate ad app di terze parti
- API nascoste destinate ad app privilegiate, ovvero API di sistema o API private (
@hide
, or
protected,
package private`)
- (tipo 2) Richiama i servizi del sistema Android utilizzando direttamente il raccoglitore raw o i 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 generalmente test di strumentazione, mentre i test di tipo 3 sono generalmente GTest.
Qual è il prossimo?
Di seguito è riportato un elenco dei prossimi documenti che potresti leggere:
Se non hai studiato l'architettura Android, vedi Panoramica dell'architettura .
Se stai creando un dispositivo compatibile con Android, consulta la panoramica del programma di compatibilità Android .
Per integrare test di strumentazione, funzionali, metrici e host JAR in un servizio di test continuo della piattaforma, vedere Flusso di lavoro di sviluppo dei test .
Per rilevare e proteggere i tuoi dispositivi dalle vulnerabilità, consulta Test di sicurezza .
Per informazioni su come testare le implementazioni HAL e kernel, consulta Vendor Test Suite (VTS) e infrastruttura .
Per testare le app, leggi Nozioni fondamentali per testare le app Android e conduci la sezione Android avanzata in Kotlin 05.1: Testing Basics utilizzando gli esempi forniti.
Scopri i test di preinvio di base disponibili tramite gli hook dei repository. Questi hook possono essere utilizzati per eseguire linter, controllare la formattazione e attivare test unitari prima di procedere, ad esempio caricando un commit. Questi hook sono disabilitati per impostazione predefinita. Per ulteriori informazioni, vedere Hook di preuplaod AOSP .
Per ulteriori informazioni sulla registrazione, vedere Informazioni sulla registrazione .
Per comprendere come eseguire il debug del codice Android, consulta Debug del codice della piattaforma nativa .