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 SDK Android e NDK. 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 Android, ma per essere considerato parte dell'ecosistema Android, un dispositivo deve essere compatibile con Android.
- elemento
- Un log relativo alla build che consente la risoluzione dei problemi in locale.
- Compatibility Definition Document (CDD)
- Un documento che elenca i requisiti software e hardware per un dispositivo compatibile con Android.
- Compatibility Test Suite (CTS)
Una suite di test senza costi di livello commerciale, disponibile per il download come binario o come sorgente in AOSP. CTS è un insieme di unit test progettati per essere integrati nel tuo flusso di lavoro quotidiano. L'obiettivo di CTS è rivelare le incompatibilità e garantire che il software rimanga compatibile durante il processo di sviluppo.
I test CTS e della piattaforma non si escludono a vicenda. Ecco alcune linee guida generali:
- Se un test afferma la correttezza delle funzioni o dei comportamenti dell'API del framework e deve essere applicato a tutti i partner OEM, deve essere in CTS.
- Se un test è progettato per rilevare le regressioni durante lo sviluppo della piattaforma, potrebbe richiedere autorizzazioni con privilegi 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 strumentazione
Un ambiente di esecuzione di 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 un thread di strumentazione 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, inclusi gli stack trace 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. Il logging in Android è complesso a causa del mix di standard utilizzati combinati nello strumento Logcat.
- test post-commit
Un test Android eseguito quando viene eseguito il commit di una nuova patch in un ramo del kernel comune. Inserendo
aosp_kernelcome nome parziale del ramo, puoi visualizzare un elenco di rami del kernel con i risultati disponibili. Ad esempio, i risultati perandroid-mainlinesono disponibili all'indirizzo https://ci.android.com/builds/branches/aosp_kernel-common-android-mainline/grid.- test pre-commit
Un test utilizzato per impedire l'introduzione di errori nei kernel comuni.
- Trade Federation
Chiamato anche Tradefed, un framework di test continuo progettato per eseguire test sui dispositivi Android. Ad esempio, Tradefed viene utilizzato per eseguire i test 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 kernel del sistema operativo e del livello di astrazione hardware (HAL).
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à del soggetto in fase di test e afferma 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 con privilegi, ovvero API di sistema o API private (
@hideoprotected,package private)
- (Tipo 2) Richiamare direttamente i servizi di sistema Android utilizzando proxy binder o IPC non elaborati.
- (Tipo 3) Interagire 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 in genere GTest.
Passaggi successivi
Di seguito è riportato un elenco di documenti che puoi leggere per informazioni più dettagliate:
Se non hai studiato l'architettura 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 dispositivi dalle vulnerabilità, consulta Test di sicurezza.
Per scoprire di più sui test delle implementazioni HAL e del kernel, consulta Vendor Test Suite (VTS) e infrastruttura.
Per i test delle app, leggi Nozioni di base per i test delle app Android ed esegui Advanced Android in Kotlin 05.1:nozioni di base per i test utilizzando gli esempi forniti.
Scopri i test pre-commit di base a tua disposizione tramite gli hook del repository. Questi hook possono essere utilizzati per eseguire linter, controllare la formattazione e attivare gli unit test prima di procedere, ad esempio caricare un commit. Questi hook sono disattivati per impostazione predefinita. Per ulteriori informazioni, consulta Hook pre-upload AOSP.
Per saperne di più sul logging, consulta Comprendere il logging.
Per capire come eseguire il debug del codice Android, consulta Eseguire il debug del codice della piattaforma Android nativa.