Infrastruktur für automatisierte Tests

Android 9 enthält eine VTS-Infrastruktur (Vendor Test Suite) für automatisierte Tests von VTS, CTS oder anderen Tests auf Partnergeräten, auf denen das generische AOSP-Systemimage (GSI) ausgeführt wird. Bisher war die Durchführung dieser Tests ein sehr manueller Vorgang. Die neue VTS-Testinfrastruktur ist so konzipiert, dass automatisierte Tests mehrmals täglich auf mehreren Geräten durchgeführt werden können.

Architektur

Die automatisierte VTS-Testinfrastruktur verwendet die folgende Architektur:

Wenn ein Test ausgelöst wird, führt die automatisierte VTS-Testinfrastruktur die folgenden Aufgaben aus:

1. Ruft Build-Artefakte und Testressourcen von verschiedenen Orten ab:
   • Partner Android Build (PAB) Für das GSI, das VTS-Framework und einige andere Builds.
   • Lokales Dateisystem, Google Cloud Storage oder ein anderes anbieterspezifisches Build-System. Für Partner, die keine Builds in der Google-Cloud speichern.
2. Flasht Build-Artefakte (vom Gerät) und das GSI (von AOSP) auf die verbundenen Geräte.
3. Führt VTS-Tests mit lokalem TradeFed oder einem TradeFed in der Cloud aus.
4. Testergebnisse an das VTS-Dashboard melden

Der Prozess wird vom VTS-Hostcontroller (HC) koordiniert, einem Computer im Labor, der das Verhalten aller angeschlossenen Geräte unter Test steuert. Der HC ist dafür verantwortlich, die neuesten Builds abzurufen, sie auf Geräte zu flashen und Tests aufzurufen (entweder lokal oder über den Commander). Außerdem kommuniziert er mit einem Cloud-Scheduler und leitet Traffic zwischen dem Scheduler und der TradeFed-Instanz (oder einem anderen Harness) weiter, die auf dem Host-Controller ausgeführt wird. Weitere Informationen zum Hostcontroller finden Sie unter Host Controller Architecture.

Ressourcenanbieter

Für automatisierte Tests sind Ressourcen wie System-Builds, Testdateien und VTS-Artefakte erforderlich. Es ist zwar möglich, diese aus dem Quellcode zu erstellen, aber es ist einfacher, sie regelmäßig aus dem aktuellen Quellcode zu erstellen und die Artefakte dann zum Download bereitzustellen.

Partner können über die folgenden Orte auf Automatisierungsressourcen zugreifen:

• Partner-Android-Build. Der programmatische Zugriff wird pro Konto gewährt.
• Lokales Dateisystem (oder ähnlich) Für Partner, die den Partner-Android-Build nicht verwenden.

Für das spätere Flashen der Geräte sind in den Ressourcen Build-Anbieter für beide Optionen enthalten, die von einem einzelnen build_provider.py abgeleitet werden, in dem die Builds in lokalen temporären Verzeichnissen gespeichert werden.

Partner-Android-Build

In Android 8.1 und niedrigeren Versionen mussten Android-Partner die Website „Partner Android Build“ (https://partner.android.com/build) aufrufen, zu ihrem Konto navigieren und die neuesten Systemabbilder über die Benutzeroberfläche abrufen. Um Partnern diesen langsamen und arbeitsintensiven Prozess zu ersparen, unterstützt Android 9 das automatische Herunterladen dieser Ressourcen aus PAB, wenn die entsprechenden Anmeldedaten angegeben werden.

Zugriff einrichten

Für den programmatischen Zugriff wird OAuth2 für Google APIs verwendet, um auf die erforderlichen RPCs zuzugreifen. Beim Standardverfahren zum Generieren von OAuth2-Anmeldedaten muss der Partner ein Client-ID/Secret-Paar bei Google einrichten. Wenn der PartnerAndroidBuildClient zum ersten Mal auf dieses Secret verweist, wird ein Browserfenster geöffnet, in dem sich der Nutzer in seinem Google-Konto anmelden kann. Dadurch werden die für den weiteren Ablauf erforderlichen OAuth2-Anmeldedaten generiert. Die Anmeldedaten (Zugriffstoken und Aktualisierungstoken) werden lokal gespeichert. Partner müssen sich also nur einmal anmelden.

POST-Anfrage für URL

Wenn Sie in PAB auf einen Ressourcenlink klicken, wird eine POST-Anfrage gesendet, die die erforderlichen Daten für diese Ressource enthält, darunter:

• Build-ID, Build-Ziel
• Ressourcenname
• Zweig
• Name des Releasekandidaten und ob es sich um einen internen Build handelt

Die POST-Anfrage wird von der Methode downloadBuildArtifact des buildsvc-RPC empfangen, die eine URL zurückgibt, mit der auf die Ressource zugegriffen werden kann.

• Bei Clockwork Companion-APK-Ressourcen ist die URL eine lesbare URL, die auf PAB gehostet wird. Sie ist durch die Authentifizierung geschützt und mit den entsprechenden OAuth2-Anmeldedaten zugänglich.
• Bei anderen Ressourcen ist die URL eine lange, ungeschützte URL aus der internen Android Build API, die nach fünf Minuten abläuft.

URL abrufen

Um Cross-Site-Request-Forgery zu vermeiden, ist für den buildsvc-RPC ein XSRF-Token erforderlich, das mit den anderen Parametern gepostet wird. Dieses Token macht den Prozess zwar sicherer, erschwert aber auch den programmatischen Zugriff erheblich, da das Token (das nur im JavaScript der PAB-Seite verfügbar ist) jetzt auch für den Zugriff erforderlich ist.

Um dieses Problem zu vermeiden, wurde das URL-Benennungsschema für alle Dateien (nicht nur APKs) in Android 9 überarbeitet. Es werden jetzt vorhersehbare URL-Namen für den Zugriff auf Artefaktlisten und Artefakt-URLs verwendet. Das PAB verwendet jetzt ein praktisches URL-Format, mit dem Partner Ressourcen herunterladen können. HC-Scripts können diese APKs problemlos herunterladen, da das URL-Format bekannt ist und HC die XSRF-/Cookie-Probleme umgehen kann, da der buildsvc-RPC nicht erforderlich ist.

Lokales Dateisystem

Wenn ein Verzeichnis mit einer Liste (oder ZIP-Datei) von Artefakten angegeben wird, legt der Build-Anbieter die relevanten Bilder basierend auf dem Inhalt des Verzeichnisses fest. Mit dem Tool gsutil können Sie Dateien aus Google Cloud Storage in ein lokales Verzeichnis kopieren.

Flash-Builds

Nachdem die neuesten Geräte-Images auf den Host heruntergeladen wurden, müssen sie auf die Geräte geflasht werden. Dies erfolgt über die Standardbefehle adb und fastboot sowie Python-Unterprozesse, basierend auf den temporären Dateipfaden, die von den Build-Anbietern gespeichert werden.

Unterstützte Aktionen:

• Nur GSI flashen
• Einzelne Images aus dem Hauptsystem flashen (z.B. fastboot flash boot boot.img)
• Alle Images aus dem Hauptsystem flashen. Beispiel:
  • fastboot flashall (mit dem integrierten Dienstprogramm flashall)
  • fastboot flash (einzeln)

Tests ausführen

In Android 9 unterstützt die Infrastruktur für automatisierte VTS-Tests nur den TradeFed-Testharness. Sie könnte jedoch in Zukunft erweitert werden, um andere Harnesses zu unterstützen.

Nachdem die Geräte vorbereitet wurden, können Sie Tests mit einer der folgenden Optionen aufrufen:

• Wenn Sie TradeFed lokal verwenden, verwenden Sie den Befehl test im Hostcontroller. Dieser Befehl verwendet den Namen eines VTS-Testplans (z. B. vts-selftest) und führt den Test aus.
• Wenn Sie einen TradeFed-Cluster verwenden (optional mit MTT verbunden), verwenden Sie den Befehl lease in der Hostcontroller-Konsole, um nach nicht ausgeführten Testläufen zu suchen.

Wenn Sie TradeFedCluster verwenden, wird TradeFed lokal als Remote-Manager ausgeführt. Andernfalls werden die Tests mit Python-Unterprozessen aufgerufen.

Berichtsergebnisse

Testergebnisse werden automatisch von VtsMultiDeviceTest an einige VTS-Dashboardprojekte gemeldet.