Android Open Source Project (AOSP) offre diversi strumenti e suite di test per testare varie parti della tua implementazione. Prima di utilizzare le pagine in questo dovresti 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 usando l'SDK per Android e NDK. I dispositivi compatibili con Android devono rispettare le i requisiti del Il Compatibility Definition Document (CDD) e il documento Suite di test di compatibilità (CTS, Compatibility Test Suite). Compatibile con Android dispositivi sono idonei a far parte dell'ecosistema Android, che include potenziale licenza di Google Play, potenziale licenza dei Suite di Google Mobile Services (GMS) app e API e all'uso del marchio Android. Tutti sono invitati a usano il codice sorgente Android, ma per essere considerati parte dell'ecosistema Android, un dispositivo deve essere compatibile con Android.
- artefatto
- Un log relativo alla build che consente la risoluzione dei problemi locali.
- Compatibilità Definition Document (CDD)
- Un documento che elenca i requisiti software e hardware per una Dispositivo compatibile con Android.
- Suite di test di compatibilità (Compatibility Test Suite, CTS)
Una suite di test di livello commerciale, senza costi, disponibile per il download come binario o sorgente in AOSP. Il CTS è un insieme di test delle unità progettato per essere integrato nel tuo flusso di lavoro giornaliero. Lo scopo del CTS è rilevare le incompatibilità e assicurano che il software rimanga compatibile durante tutto il processo di sviluppo.
I test CTS e della piattaforma non si escludono a vicenda. Ecco alcune informazioni generali linee guida:
- Se un test dichiara la correttezza delle funzioni o dei comportamenti dell'API del framework, e il test deve essere applicato a tutti i partner OEM, in formato CTS.
- Se un test ha lo scopo di rilevare regressioni durante lo sviluppo della piattaforma, potrebbero richiedere autorizzazioni privilegiate e potrebbero dipendere sui dettagli dell'implementazione (come rilasciato in AOSP), deve essere una piattaforma test.
- 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 in C++. I file binari di GTest solitamente accedere a livelli di astrazione di livello inferiore o eseguire IPC non elaborati su vari sistemi i servizi di machine learning. L'approccio di test per GTest è in genere strettamente associato servizio in fase di test. CTS contiene il framework GTest.
- test di strumentazione
Uno speciale ambiente di esecuzione dei test avviato dal comando
am instrument
, in cui il processo dell'app target viene riavviato e inizializzato con il contesto di base dell'app e un il thread di strumentazione viene avviato all'interno del processo dell'app in una macchina virtuale. Il CTS contiene test di strumentazione.- Logcat
uno strumento a riga di comando che crea un log dei messaggi di sistema, analisi dello stack dei casi in cui il dispositivo genera un errore e i messaggi scritte dalla tua app con la classe
Log
.- registrazione
L'utilizzo di un log per tenere traccia degli eventi del sistema informatico, ad esempio come errori. L'accesso in Android è complesso a causa del mix di standard utilizzati vengono combinati nello strumento Logcat.
- test post-invio
Un test Android che viene eseguito quando viene eseguito il commit di una nuova patch in un ramo del kernel comune. Inserendo
aosp_kernel
come nome parziale della filiale, puoi vedere un elenco di rami del kernel con risultati disponibili. Ad esempio, i risultati perandroid-mainline
è disponibile all'indirizzo https://ci.android.com/builds/branches/aosp_kernel-common-android-mainline/grid.- test pre-invio
Un test utilizzato per impedire l'introduzione di errori nel con i kernel più comuni.
- Federazione commerciale
Chiamato anche Tradefed, un test continuo progettato per l'esecuzione di test su dispositivi Android. Ad esempio: Tradefed viene utilizzato per eseguire i test del Compatibility Test Suite e del Vendor Test Suite.
- Suite di prova del fornitore (VTS)
Una serie di ampie funzionalità Test di Android, promozione di un processo di sviluppo basato sui test e automazione livello di astrazione hardware (HAL) e test del kernel del sistema operativo.
Tipi di test della piattaforma
Un test della piattaforma in genere interagisce con uno o più sistemi Android o strati HAL, esercita la funzionalità del soggetto sottoposto a test e dichiarare la correttezza dei risultato del test. Un test della piattaforma potrebbe:
- (Tipo 1) API del framework di esercizi che utilizzano il framework Android. Le API specifiche vengono
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
oprotected
,package private
)
- (Tipo 2) Richiama servizi di sistema Android utilizzando binder non elaborati o proxy IPC .
- (Tipo 3) Interagire 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 di solito 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 crei un dispositivo compatibile con Android, vedi la panoramica del programma di compatibilità Android.
per integrare i test host di strumentazione, funzionalità, metriche e JAR in un servizio di test continuo della piattaforma, consulta Flusso di lavoro per lo sviluppo dei test.
Per rilevare e proteggere i dispositivi dalle vulnerabilità, consulta Test di sicurezza.
Per scoprire come testare le implementazioni dell'HAL e del kernel, vedi Suite di test (VTS) e infrastruttura del fornitore.
Per i test delle app, leggi Concetti fondamentali del test di Android app e condurre il corso Advanced Android in Kotlin 05.1:Testing Nozioni di base utilizzando esempi forniti.
Scopri i test pre-invio di base disponibili tramite gli hook dei repository. Questi ganci possono essere usati per eseguire linter, controllare la formattazione e attivare l'unità prima di procedere, ad esempio caricando un commit. Questi hook sono disattivati per impostazione predefinita. Per ulteriori informazioni, consulta Precaricamento AOSP Hook.
Per saperne di più sul logging, consulta Informazioni sul logging.
Per capire come eseguire il debug del codice Android, consulta: Eseguire il debug del codice della piattaforma Android nativa.