Dieses Dokument beschreibt AVDs für Test Lab, einschließlich der Vorteile und bekannten Einschränkungen. Wir geben auch Empfehlungen zum Testen Ihrer App während des gesamten Entwicklungslebenszyklus.
Während Test Lab AVDs AVDs für Android Studio ähneln, gibt es einige Unterschiede zwischen den beiden. Zum Beispiel haben AVDs in Test Lab eher eine emulierte Datenverbindung als eine Wi-Fi-Verbindung.
Test Lab AVDs mit dem Suffix .arm oder (Arm) sind erweiterte Emulatoren, die die folgenden Vorteile bieten:
Schnellere Testausführungszeit
Bildschirmgrößen und -dichten sind aus Gründen der Konsistenz auf die AVDs von Android Studio abgestimmt
Die Verwendung von AVDs mit dem Suffix .arm oder (Arm) bietet die folgenden Vorteile gegenüber anderen Arten von physischen Geräten:
| Nutzen | Beschreibung | Anwendungsfälle) |
| Hohe Verfügbarkeit | Beim Testen mit virtuellen Geräten können Sie schneller Tests durchführen und Testergebnisse erhalten. Da virtuelle Geräte nach Bedarf erstellt werden, beginnen Ihre Tests fast sofort und ermöglichen eine schnelle Validierung Ihrer App. | Testen kleiner Updates für Ihre App oder für Regressionstests. |
| Längere Testzeiten | Tests auf physischen Geräten sind auf eine Testdauer von 45 Minuten auf jedem Gerät begrenzt. Virtuelle Geräte unterstützen eine Testdauer von bis zu 60 Minuten. | Längere Tests durchführen. |
| Geringere Kosten | Virtuelle Geräte kosten 1 $ pro Stunde für jedes virtuelle Gerät, das zum Testen Ihrer App verwendet wird. | Tägliches Testen mit Continuous-Integration-Systemen oder vor dem Einchecken von Code. Weitere Informationen finden Sie unter Nutzungsniveaus, Kontingente und Preise für Test Lab . |
Testen Sie Ihre App mit virtuellen Geräten
Sie können Ihre App mit virtuellen Geräten genauso testen wie mit physischen Geräten. Wählen Sie einfach virtuelle Geräte aus, wenn Sie Testdimensionen auswählen, um eine Testmatrix zu konfigurieren. Weitere Informationen zum Ausführen von Tests mit Test Lab finden Sie unter Erste Schritte beim Testen für Android mit Firebase Test Lab .
Zeigen Sie unterstützte Modelle und APIs an
Führen Sie den folgenden Befehl aus, um von Test Lab unterstützte AVD-Modelle und APIs anzuzeigen:
gcloud firebase test android models list --filter=virtual
Best Practices zum Testen Ihrer App
Virtuelle Geräte erweitern Ihre Möglichkeiten, wenn Sie Ihre App mit Test Lab testen. Wir empfehlen, die Best Practices in diesem Abschnitt zu verwenden, um Ihre App während des gesamten Lebenszyklus der App-Entwicklung zu testen.
Verwenden Sie den Android Studio-Emulator oder ein angeschlossenes physisches Gerät
Verwenden Sie beim Entwickeln Ihrer App den Android Studio-Emulator oder ein angeschlossenes physisches Gerät, um jeden Build für die anfängliche Validierung zu untersuchen. Wenn Sie über Instrumentierungstests verfügen, können Sie diese Tests auch in Android Studio auf physischen oder virtuellen Geräten ausführen, die von Test Lab bereitgestellt werden.
Verwenden Sie CI-Systeme bei jeder Codeänderung, wenn Sie an gemeinsamen Projekten arbeiten
Wenn Sie an einem großen Projekt arbeiten oder an Projekten mitwirken, die über GitHub oder einen ähnlichen Dienst geteilt werden, empfehlen wir die Verwendung von CI-Systemen (Continuous Integration).
Testen Sie Ihre Apps jedes Mal auf virtuellen Geräten, wenn das CI-System ausgeführt wird, oder vor jeder Pull-Anforderung. Weitere Informationen zur Verwendung von Test Lab mit CI-Systemen finden Sie unter Verwenden von Test Lab für Android mit Continuous-Integration-Systemen .
Testen Sie Ihre App auf physischen Geräten mit Test Lab, bevor Sie wichtige App-Updates veröffentlichen
Bevor Sie App-Updates mit erheblichen Änderungen der Benutzeroberfläche und Funktionalität veröffentlichen, empfehlen wir Ihnen, Test Lab zu verwenden, um Ihre App auf physischen Geräten zu testen. Dadurch wird sichergestellt, dass Ihre App auf einer Vielzahl gängiger physischer Geräte stabil und leistungsfähig ist. Das Testen auf physischen Geräten stellt auch die Testabdeckung für alle App-Funktionen sicher, die auf Funktionen physischer Geräte angewiesen sind, die nicht durch virtuelle Geräte simuliert werden. Weitere Informationen zu diesen Funktionen finden Sie unter Bekannte Einschränkungen .
Updates für virtuelle Geräte
Das Android-Team fügt regelmäßig neue virtuelle Geräteabbilder hinzu, verwirft alte und aktualisiert vorhandene. Wir wenden diese Updates auf unsere virtuellen Geräte-Images an, um sicherzustellen, dass Sie mit aktuellen Android-Versionen testen, die die Erfahrungen Ihrer Benutzer widerspiegeln.
In seltenen Fällen können diese Updates dazu führen, dass Tests unerwartet fehlschlagen. Wenn es ein bekanntermaßen möglicherweise fehlerhaftes Update gibt, fügt Test Lab Informationen in die Versionshinweise ein . Als Best Practice empfehlen wir Ihnen, Test-Frameworks – zum Beispiel Espresso – zu verwenden, die robust gegenüber diesen Änderungen sind, wann immer dies möglich ist. Wenn dies nicht möglich ist, empfehlen wir Ihnen, auf virtuelle Arm-Geräte abzuzielen, die voraussichtlich weniger häufig aktualisiert werden.
Bekannte Einschränkungen
Einige physische Gerätefunktionen werden derzeit nicht durch virtuelle Geräte simuliert oder werden mit einigen Einschränkungen simuliert. Die folgende Tabelle fasst Funktionen zusammen, die derzeit auf virtuellen Geräten nicht oder mit bestimmten Einschränkungen verfügbar sind.
| Besonderheit | Einzelheiten |
| Anwendungsbinäre Schnittstellen (ABI) | Nicht alle Geräte unterstützen alle ABIs. Wenn Sie mit dem Android NDK entwickeln, stellen Sie sicher, dass Sie Code für die ABIs generieren, die von den Zielgeräten unterstützt werden. Weitere Informationen finden Sie unter Verfügbare Geräte im Testlabor . Weitere Informationen zur ABI-Verwaltung finden Sie unter Android ABIs . Um zu erfahren, welche ABIs von einem Gerät unterstützt werden, siehe Verfügbare Testgeräte prüfen . Hinweis: Wenn ein Test in Ihrer Testmatrix als ungültig gekennzeichnet ist, kann dies daran liegen, dass Ihre App von nativem Code abhängig ist, der von der Geräte-ABI nicht unterstützt wird. |
| Grafikleistung | Virtuelle Nexus- und Pixel-Geräte verwenden Softwaregrafik-Rendering. Bei grafikintensiven Anwendungen wird die Leistung geringer. Wenn Ihre App grafikintensiv ist, verwenden Sie stattdessen die Modelle SmallPhone.arm und MediumPhone.arm oder physische Geräte. |
| Bildschirmaufnahme | Die Bildschirmaufzeichnung auf den Nexus- und Pixel-Geräten beträgt 1 Bild pro Sekunde. |
| Grafik-APIs | OpenGL ES 3.x wird auf Geräten unter API-Level 29 nicht unterstützt. Neuere Geräte sind nicht 100 % kompatibel mit OpenGL/Vulkan-APIs. Möglicherweise bemerken Sie kleine Unterschiede in der Grafik. |