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, 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 utilizzando l'SDK e il 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 far parte dell'ecosistema Android, che include potenziale licenza di Google Play, potenziale licenza per la suite Google Mobile Services (GMS) di app e API 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.
- elemento
- Un log relativo alla build 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 delle unità progettato per essere integrato nel tuo flusso di lavoro giornaliero. 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 in 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 strumentazione
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 analisi 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.
- test postsubmit
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 perandroid-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
Detto anche Tradefed, è un framework di test continua 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 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 host per 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 tuoi dispositivi dalle vulnerabilità, consulta Test di sicurezza.
Per scoprire come testare le implementazioni dell'HAL e del kernel, consulta Suite di test del fornitore (VTS) e infrastruttura.
Per i test delle app, leggi l'articolo Nozioni di base sui test delle app Android ed esegui il corso Advanced Android in Kotlin 05.1:Testing Nozioni di base utilizzando gli esempi 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, vedi Informazioni sul logging.
Per scoprire come eseguire il debug del codice Android, consulta Eseguire il debug del codice della piattaforma Android nativa.