Use this file to discover all available pages before exploring further.
Devin kann Android-Anwendungen direkt auf seiner eigenen Maschine erstellen und ausführen — und bietet damit das Android-Äquivalent zu Computer Use und Interaktionen im Browser. Devin kann die App öffnen, ihr Verhalten untersuchen, Probleme reproduzieren und Änderungen in der Umgebung überprüfen, in der die Anwendung tatsächlich läuft. In Kombination mit Videoaufzeichnungen kann Devin Ihnen eine Aufzeichnung als Nachweis senden.
Die Unterstützung für Android-Emulatoren ist derzeit nur eingeschränkt verfügbar. Wenn Sie daran interessiert sind, sie mit Devin zu nutzen, kontaktieren Sie uns, um mehr zu erfahren und Zugriff zu erhalten.
Mit aktivierter Unterstützung für Android-Emulatoren kann Devin den gesamten mobilen Entwicklungszyklus abdecken:
PRs bauen & Smoke-Tests ausführen
Devin baut und startet Ihre App im Emulator und klickt sich dann nach jedem Pull Request (PR) durch kritische Abläufe. Sie erhalten eine Videoaufnahme als Nachweis, dass die Funktion funktioniert — ansehen und anschließend mergen.
End-to-End-Mobile-Tests
Testen Sie vollständige Nutzerabläufe — Login, Navigation, Absenden von Formularen, Checkout — auf einem echten Android-Stack, nicht mit einem Mock. Devin folgt dem Ablauf Schritt für Schritt und kennzeichnet alles, was nicht funktioniert.
UI-Prüfung
Prüfen Sie Layouts, Themes und das Responsive-Verhalten über verschiedene Bildschirmgrößen und API-Levels hinweg. Devin erstellt an wichtigen Punkten Screenshots und kennzeichnet visuelle Probleme wie überlappende Elemente oder abgeschnittenen Text.
Abstürze & ANRs debuggen
Reproduzieren Sie Probleme im Emulator, erfassen Sie die logcat-Ausgabe, prüfen Sie das Verhalten, verfolgen Sie die Ursache und spielen Sie einen Fix ein — alles in einer Sitzung.
Plattformübergreifende Validierung
Sie entwickeln mit React Native, Flutter oder Kotlin Multiplatform? Devin kann die Android-Seite zusammen mit Ihren Web- oder Desktop-Builds in derselben Sitzung testen.
Ausführung instrumentierter Tests
Führen Sie Espresso- oder UI-Automator-Testsuiten auf dem Emulator aus und lassen Sie sich die Ergebnisse übermitteln, ohne eine separate CI-Device-Farm oder physische Geräte zu benötigen.
Tests mit mehreren Konfigurationen
Prüfen Sie Ihre App über verschiedene API-Levels oder Geräteprofile hinweg, indem Sie mehrere AVDs konfigurieren. So lassen sich Kompatibilitätsprobleme erkennen, bevor sie bei Nutzern ankommen.
Die Unterstützung für Android-Emulatoren basiert auf demselben System für deklarative Konfiguration wie der Rest von Devins Umgebung. Sie fügen das Android SDK und den Emulator zu Ihrem Blueprint hinzu, und Devins Snapshot-Build erstellt eine VM, in der alles vorinstalliert ist. Jede Sitzung startet von diesem Snapshot, wobei der Emulator sofort einsatzbereit ist.Während einer Sitzung interagiert Devin auf zwei Arten mit dem Emulator:
Das Emulatorfenster wird auf Devins Desktop ausgeführt, sodass Sie im Desktop-Tab der Webapp in Echtzeit verfolgen können, wie Devin mit Ihrer App interagiert.
Der einfachste Einstieg. Devin analysiert Ihr Android-Projekt, installiert die richtigen SDK-Komponenten und konfiguriert den Emulator für Sie.
1
Eine Devin-Sitzung starten
Öffnen Sie eine neue Sitzung und bitten Sie Devin, die Android-Emulation einzurichten. Zum Beispiel: “Richte einen Android-Emulator für dieses Repo ein.”
2
Prüfen und genehmigen
Devin schlägt einen Blueprint mit dem Android SDK, Build-Tools und der Emulator-Konfiguration vor. Prüfen Sie die Vorschlagskarten in Ihrer Timeline und klicken Sie auf Approve.
3
Überprüfen
Sobald der Build abgeschlossen ist, starten Sie eine neue Sitzung. Bitten Sie Devin, Ihre App zu bauen und im Emulator auszuführen, um zu bestätigen, dass alles funktioniert.
Wenn Sie genau wissen, welche SDK-Komponenten und welche Emulator-Konfiguration Sie benötigen, können Sie den Blueprint selbst schreiben.
1
Zur Umgebungskonfiguration navigieren
Gehen Sie zu Settings > Environment > Blueprints und wählen Sie Ihr Android-Repository aus.
2
Ihren Blueprint schreiben
Fügen Sie das Android SDK, die Platform-Tools, den Emulator und ein System-Image zu initialize hinzu. Fügen Sie die Installation Ihrer Abhängigkeiten zu maintenance hinzu. Unten finden Sie unter Blueprint-Beispiele Vorlagen zum Kopieren und Einfügen.
3
Speichern und Build starten
Klicken Sie auf Save. Ein Build startet automatisch (bei Android aufgrund von SDK-Downloads typischerweise 5–15 Minuten). Verfolgen Sie den Fortschritt unter Settings > Environment > Snapshots.
4
Überprüfen
Sobald der Build Success anzeigt, starten Sie eine neue Sitzung. Bitten Sie Devin, den Emulator zu starten und Ihre App zu bauen, um die Konfiguration zu überprüfen.
Ein typisches Blueprint für die Nutzung des Android-Emulators installiert:
Komponente
Zweck
Android SDK-Befehlszeilentools
Grundlegende SDK-Verwaltung (sdkmanager)
Plattform-Tools
adb, fastboot für die Kommunikation mit Geräten
Build-Tools
aapt2, d8, zipalign zum Erstellen von APKs
Android-Plattform (z. B. API 34)
Ziel-API-Level für Ihre App
Emulator + System-Image
Das virtuelle Gerät selbst
Verwenden Sie ein x86_64-System-Image, um in Devins Umgebung die beste Leistung zu erzielen. ARM-Images funktionieren ebenfalls, sind unter Emulation aber deutlich langsamer.
Bitte Devin jederzeit während einer Sitzung, deine App zu erstellen und auszuführen — keine spezielle Syntax erforderlich, nur natürliche Sprache:
“Erstelle und starte die App im Android-Emulator”
“Teste den Login-Ablauf im Emulator und sende mir eine Aufzeichnung”
“Öffne den Settings-Bildschirm im Emulator und prüfe, ob der neue Schalter angezeigt wird”
“Führe die Espresso-Tests im Emulator aus und zeige mir die Ergebnisse”
Devin startet den Emulator (falls er noch nicht läuft), erstellt und startet deine App und interagiert damit — mit adb für programmatische Aktionen und Computer Use für visuelle Interaktionen.
Die Unterstützung für Android-Emulatoren ist direkt in Devins Workflow für Testing & Recordings integriert. Nachdem Sie einen Pull Request (PR) erstellt haben:
Devin bietet an, die App zu testen — klicken Sie auf die Schaltfläche oder fragen Sie direkt danach
Devin erstellt und startet die App im Emulator und führt einen gezielten Testplan aus
Der Emulatorbildschirm wird als Videoaufzeichnung mit Anmerkungen erfasst
Die Aufzeichnung wird Ihnen gesendet, damit Sie den Test ansehen und den PR mit Zuversicht zusammenführen können
Das funktioniert genauso wie beim Testen von Web-Apps — der einzige Unterschied ist, dass Devin statt mit Chrome mit dem Emulatorfenster interagiert.
Erstellen Sie einen Skill, der Devin genau vorgibt, wie Ihre Android-App erstellt, gestartet und getestet werden soll. Das spart bei wiederholten Sitzungen Einrichtungszeit und sorgt für konsistente Tests. Geben Sie zum Beispiel den Gradle-Build-Befehl an, welche Activity gestartet werden soll und welche Abläufe überprüft werden sollen.
Nach dem Testen Ihrer Android-App hält Devin fest, was es gelernt hat — wie der Emulator gestartet wird, welche Gradle-Tasks ausgeführt werden müssen und wie man zu der getesteten Funktion gelangt — und schlägt vor, über einen Pull Request (PR) einen Skill zu erstellen oder zu aktualisieren. Sie können den PR unverändert mergen oder anpassen, um die Anweisungen zu verfeinern.Mit der Zeit wird Devin dadurch immer besser darin, Ihr Android-Projekt zu testen. Die Erkenntnisse aus jeder Sitzung bauen auf den vorherigen auf — wenn Devin Ihre App also ein zweites Mal testet, weiß es bereits, wie sie gebaut wird, welche Activity gestartet werden muss und welche Abläufe am wichtigsten sind.Sie können Devin auch jederzeit darum bitten (z. B. „Erstelle einen Skill dafür, wie diese Android-App gebaut und getestet wird“). Ausführliche Informationen finden Sie im Skills-Leitfaden.
Nutzereingaben simulieren — adb shell input tap 500 800 für skriptgesteuerte Interaktionen
Je nach Aufgabe wählt Devin zwischen adb und Computer Use — adb für Geschwindigkeit und Automatisierung, Computer Use für die visuelle Überprüfung und komplexe UI-Abläufe.
Kopierbare Blueprints für gängige Android-Setups. Jede Vorlage ist in sich abgeschlossen — fügen Sie sie in Ihren Blueprint-Editor ein und speichern Sie sie.
Häufige Ursachen: KVM ist in der VM nicht verfügbar, es steht nicht genügend Arbeitsspeicher zur Verfügung oder ein System-Image fehlt.Lösung: Devin kann versuchen, KVM automatisch zu konfigurieren, wenn erkannt wird, dass der Emulator Hardwarebeschleunigung benötigt — in den meisten Fällen wird das Problem so ohne manuelles Eingreifen behoben. Wenn KVM nach dem Versuch von Devin weiterhin nicht verfügbar ist, kann der Emulator auf den Software-Rendering-Modus zurückfallen — fügen Sie dazu dem Startbefehl des Emulators -no-accel hinzu; die Leistung ist dann jedoch geringer. Prüfen Sie außerdem, ob Ihr Blueprint den Emulator und ein kompatibles x86_64-System-Image installiert.
Häufige Ursachen: Fehlende SDK-Komponenten, ein falscher ANDROID_HOME-Pfad oder Gradle kann die richtige Version der Build-Tools nicht finden.Lösung: Vergewissern Sie sich, dass ANDROID_HOME in Ihrem Blueprint korrekt gesetzt ist und dass sdkmanager die Plattformversion und die Version der Build-Tools installiert, die Ihr Projekt benötigt. Prüfen Sie in der build.gradle Ihres Projekts die Werte für compileSdk, targetSdk und buildToolsVersion und gleichen Sie sie mit den Angaben im Blueprint ab.
Devin kann nicht mit dem Emulatorbildschirm interagieren
Häufige Ursachen: Der Desktop-Modus ist nicht aktiviert, das Emulatorfenster ist nicht sichtbar oder der Emulator läuft im Headless-Modus.Behebung: Stellen Sie sicher, dass der Desktop-Modus in den Settings Ihrer Organisation aktiviert ist. Wenn Devin visuell mit dem Emulator interagieren soll, starten Sie ihn ohne das Flag -no-window, damit die Emulator-GUI auf Devins Desktop angezeigt wird. Vergewissern Sie sich, dass der Emulator vollständig hochgefahren ist (adb shell getprop sys.boot_completed sollte 1 zurückgeben), bevor Sie Devin damit interagieren lassen.