AOSP bietet mehrere Tools und Testsuiten zum Testen verschiedener Teile Ihrer Implementierung. Bevor Sie mit diesem Abschnitt fortfahren, sollten Sie mit den folgenden Begriffen vertraut sein:
- Android-kompatibles Gerät
- Ein Gerät, das jede Drittanbieter-App ausführen kann, die von Drittentwicklern unter Verwendung des Android SDK und NDK geschrieben wurde. Android-kompatible Geräte müssen die Anforderungen des Compatibility Definition Document (CDD) erfüllen und die Compatibility Test Suite (CTS) bestehen. Android-kompatible Geräte sind zur Teilnahme am Android-Ökosystem berechtigt. Dazu gehört die potenzielle Lizenzierung des Google Play Store, die potenzielle Lizenzierung der App- und API-Suite Google Mobile Services (GMS) sowie die Nutzung der Marke Android. Jeder kann gerne den Android-Quellcode verwenden, aber um als Teil des Android-Ökosystems betrachtet zu werden, muss ein Gerät Android-kompatibel sein.
- Artefakt
- Artefakte sind Build-bezogene Protokolle, die eine lokale Fehlerbehebung ermöglichen.
- Kompatibilitätsdefinitionsdokument (CDD)
- Ein Dokument, das die Software- und Hardwareanforderungen für ein Android-kompatibles Gerät auflistet.
- Kompatibilitätstest-Suite (CTS)
Eine kostenlose, kommerzielle Testsuite, die als Binärdatei oder als Quelle in AOSP heruntergeladen werden kann. Das CTS ist eine Reihe von Unit-Tests, die in Ihren täglichen Arbeitsablauf integriert werden können. Ziel von CTS ist es, Inkompatibilitäten aufzudecken und sicherzustellen, dass die Software während des gesamten Entwicklungsprozesses kompatibel bleibt.
CTS- und Plattformtests schließen sich nicht gegenseitig aus. Hier sind einige allgemeine Richtlinien:
- Wenn ein Test die Korrektheit von Framework-API-Funktionen oder -Verhalten bestätigt und er bei allen OEM-Partnern durchgesetzt werden soll, sollte er im CTS erfolgen.
- Wenn ein Test darauf abzielt, Regressionen während der Plattformentwicklung abzufangen, und für die Ausführung möglicherweise eine privilegierte Erlaubnis erforderlich ist und er möglicherweise von Implementierungsdetails (wie in AOSP veröffentlicht) abhängig ist, sollte es sich um einen Plattformtest handeln.
- Google Mobile Services (GMS)
Eine Sammlung von Google-Apps und APIs, die auf Geräten vorinstalliert werden können.
- GoogleTest (GTest)
GTest ist ein C++-Test- und Mocking-Framework. GTest-Binärdateien greifen normalerweise auf Abstraktionsschichten auf niedrigerer Ebene zu oder führen Roh-IPC für verschiedene Systemdienste durch. Der Testansatz für GTest ist normalerweise eng mit dem zu testenden Dienst verknüpft. CTS enthält das GTest-Framework.
- Instrumentierungstest
Ein Instrumentierungstest stellt eine spezielle Testausführungsumgebung bereit, die durch den Befehl
am instrument
gestartet wird, in der der Zielanwendungsprozess neu gestartet und mit dem grundlegenden Anwendungskontext initialisiert wird und ein Instrumentierungsthread innerhalb der virtuellen Maschine des Anwendungsprozesses gestartet wird. CTS enthält Instrumentierungstests.- Logcat
Logcat ist ein Befehlszeilentool, das ein Protokoll von Systemmeldungen erstellt, einschließlich Stack-Traces darüber, wann das Gerät einen Fehler auslöst, und Meldungen, die Sie aus Ihrer App mit der
Log
Klasse geschrieben haben.- Protokollierung
Unter Protokollierung versteht man die Verwendung eines Protokolls, um Computersystemereignisse, wie z. B. Fehler, zu verfolgen. Die Anmeldung unter Android ist aufgrund der Mischung der verwendeten Standards, die im Logcat-Tool kombiniert werden, komplex.
- Postsubmit-Test
Android-Postsubmit-Tests werden durchgeführt, wenn ein neuer Patch in einen gemeinsamen Kernel-Zweig übernommen wird. Wenn Sie
aosp_kernel
als Teilzweignamen eingeben, können Sie eine Liste der Kernelzweige mit verfügbaren Ergebnissen anzeigen. Ergebnisse fürandroid-mainline
finden Sie beispielsweise unter https://ci.android.com/builds/branches/aosp_kernel-common-android-mainline/grid .- Test vorab einreichen
Presubmit-Tests werden verwendet, um zu verhindern, dass Fehler in die allgemeinen Kernel eingeführt werden.
- Handelsverband
Trade Federation, auch Tradefed genannt, ist ein kontinuierliches Test-Framework, das für die Durchführung von Tests auf Android-Geräten entwickelt wurde. Tradefed wird beispielsweise zum Ausführen von Compatibility Test Suite- und Vendor Test Suite-Tests verwendet.
- Vendor Test Suite (VTS)
Die Android Vendor Test Suite (VTS) bietet umfassende Funktionen für Android-Tests, fördert einen testgesteuerten Entwicklungsprozess und automatisiert HAL- und Betriebssystem-Kernel-Tests.
Plattformtesttypen
Ein Plattformtest interagiert typischerweise mit einem oder mehreren Android-Systemdiensten oder HAL-Schichten (Hardware Abstraction Layer), übt die Funktionalitäten des Testsubjekts aus und stellt die Korrektheit des Testergebnisses sicher. Ein Plattformtest könnte:
- (Typ 1) Üben Sie Framework-APIs mithilfe des Android-Frameworks aus. Spezifische APIs, die ausgeübt werden, können Folgendes umfassen:
- Öffentliche APIs für Apps von Drittanbietern
- Versteckte APIs, die für privilegierte Apps gedacht sind, nämlich System-APIs oder private APIs (
@hide
, or
protected,
package private`)
- (Typ 2) Rufen Sie Android-Systemdienste direkt über Raw Binder oder IPC-Proxys auf.
- (Typ 3) Interagieren Sie direkt mit HALs über Low-Level-APIs oder IPC-Schnittstellen.
Tests vom Typ 1 und 2 sind typischerweise Instrumentierungstests, während Tests vom Typ 3 normalerweise GTests sind.
Was kommt als nächstes?
Im Folgenden finden Sie eine Liste der nächsten Dokumente, die Sie lesen könnten:
Wenn Sie sich noch nicht mit der Android-Architektur befasst haben, lesen Sie die Übersicht über die Architektur .
Wenn Sie ein Android-kompatibles Gerät erstellen, sehen Sie sich die Übersicht über das Android-Kompatibilitätsprogramm an.
Informationen zur Integration von Instrumentierungs-, Funktions-, Metrik- und JAR-Hosttests in einen Plattform-Continuous-Testing-Service finden Sie unter Testentwicklungs-Workflow .
Informationen zum Erkennen und Absichern Ihrer Geräte gegen Schwachstellen finden Sie unter Sicherheitstests .
Weitere Informationen zum Testen Ihrer HAL- und Kernel-Implementierungen finden Sie unter Vendor Test Suite (VTS) und Infrastruktur .
Lesen Sie zum Testen von Apps den Artikel „Grundlagen zum Testen von Android-Apps“ und führen Sie „Advanced Android in Kotlin 05.1: Testing Basics“ mit den bereitgestellten Beispielen durch.
Erfahren Sie mehr über die grundlegenden Presubmit-Tests, die Ihnen über Repo-Hooks zur Verfügung stehen. Diese Hooks können verwendet werden, um Linters auszuführen, die Formatierung zu überprüfen und Unit-Tests auszulösen, bevor Sie fortfahren, beispielsweise einen Commit hochladen. Diese Hooks sind standardmäßig deaktiviert. Weitere Informationen finden Sie unter AOSP Preuplaod Hooks .
Weitere Informationen zur Protokollierung finden Sie unter Grundlegendes zur Protokollierung .
Informationen zum Debuggen von Android-Code finden Sie unter Debuggen von nativem Plattformcode .