Zum Hauptinhalt springen

Documentation Index

Fetch the complete documentation index at: https://docs.devin.ai/llms.txt

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.

Was Sie tun können

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.

So funktioniert es

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:
MethodeBeschreibungWann sie verwendet werden sollte
adb (Befehlszeile)APKs installieren, Tests ausführen, Logs erfassen, Screenshots aufnehmenAutomatisierte Builds, instrumentierte Tests, Logcat-Debugging
Computer Use (Desktop)Tippen, wischen, Text eingeben und den Bildschirm des Emulators visuell bedienenEnd-to-End-UI-Tests, visuelle Überprüfung, Videoaufzeichnungen
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.

Einrichten des Emulators

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.

Was installiert wird

Ein typisches Blueprint für die Nutzung des Android-Emulators installiert:
KomponenteZweck
Android SDK-BefehlszeilentoolsGrundlegende SDK-Verwaltung (sdkmanager)
Plattform-Toolsadb, fastboot für die Kommunikation mit Geräten
Build-Toolsaapt2, d8, zipalign zum Erstellen von APKs
Android-Plattform (z. B. API 34)Ziel-API-Level für Ihre App
Emulator + System-ImageDas 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.

Den Emulator verwenden

Tests bei Bedarf

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.

Integration in Testing & Recordings

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:
  1. Devin bietet an, die App zu testen — klicken Sie auf die Schaltfläche oder fragen Sie direkt danach
  2. Devin erstellt und startet die App im Emulator und führt einen gezielten Testplan aus
  3. Der Emulatorbildschirm wird als Videoaufzeichnung mit Anmerkungen erfasst
  4. 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.

Skill-Vorschläge

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.

Interaktion über den Desktop

Der Android-Emulator wird als Fenster auf Devins Linux-Desktop ausgeführt. Das bedeutet:
  • Devin kann über Computer Use damit interagieren — Schaltflächen antippen, wischen, Text eingeben und zwischen Bildschirmen navigieren
  • Sie können live zusehen im Desktop-Tab der Devin-Webapp
  • Aufzeichnungen erfassen den Emulatorbildschirm zusammen mit allem anderen, was auf Devins Desktop sichtbar ist
Weitere Informationen dazu, wie die Desktop-Interaktion funktioniert, finden Sie unter Computer Use.

Arbeiten mit adb

Devin kann auch programmgesteuert über adb mit dem Emulator interagieren. Das ist nützlich für:
  • APKs installierenadb install app-debug.apk
  • Instrumentierte Tests ausführenadb shell am instrument -w com.example.test/androidx.test.runner.AndroidJUnitRunner
  • Logs erfassenadb logcat zum Debuggen von Abstürzen oder unerwartetem Verhalten
  • Screenshots erstellenadb exec-out screencap -p > screenshot.png
  • Nutzereingaben simulierenadb 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.

Blueprint-Beispiele

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.
initialize:
  - name: "Install Android SDK"
    run: |
      export ANDROID_HOME="$HOME/android-sdk"
      mkdir -p "$ANDROID_HOME/cmdline-tools"
      cd "$ANDROID_HOME/cmdline-tools"
      curl -fsSL https://dl.google.com/android/repository/commandlinetools-linux-11076708_latest.zip -o tools.zip
      unzip -q tools.zip -d latest-tmp
      mv latest-tmp/cmdline-tools "$ANDROID_HOME/cmdline-tools/latest"
      rm -rf tools.zip latest-tmp
      echo "export ANDROID_HOME=$ANDROID_HOME" >> ~/.bashrc
      echo 'export PATH=$ANDROID_HOME/cmdline-tools/latest/bin:$ANDROID_HOME/platform-tools:$ANDROID_HOME/emulator:$PATH' >> ~/.bashrc
      export PATH="$ANDROID_HOME/cmdline-tools/latest/bin:$ANDROID_HOME/platform-tools:$ANDROID_HOME/emulator:$PATH"
      yes | sdkmanager --licenses > /dev/null 2>&1
      sdkmanager "platform-tools" "build-tools;34.0.0" "platforms;android-34" "emulator" "system-images;android-34;google_apis;x86_64"
      echo "no" | avdmanager create avd -n devin -k "system-images;android-34;google_apis;x86_64" --device "pixel_6"

maintenance: |
  ./gradlew assembleDebug

knowledge:
  - name: build
    contents: ./gradlew assembleDebug
  - name: test
    contents: ./gradlew test
  - name: lint
    contents: ./gradlew lint
  - name: emulator
    contents: |
      Start the emulator: emulator -avd devin -no-window -no-audio -gpu swiftshader_indirect &
      Wait for boot: adb wait-for-device && adb shell getprop sys.boot_completed
      Install APK: adb install app/build/outputs/apk/debug/app-debug.apk
initialize:
  - name: "Install Node.js"
    run: |
      nvm install 20
      nvm use 20

  - name: "Install Android SDK"
    run: |
      export ANDROID_HOME="$HOME/android-sdk"
      mkdir -p "$ANDROID_HOME/cmdline-tools"
      cd "$ANDROID_HOME/cmdline-tools"
      curl -fsSL https://dl.google.com/android/repository/commandlinetools-linux-11076708_latest.zip -o tools.zip
      unzip -q tools.zip -d latest-tmp
      mv latest-tmp/cmdline-tools "$ANDROID_HOME/cmdline-tools/latest"
      rm -rf tools.zip latest-tmp
      echo "export ANDROID_HOME=$ANDROID_HOME" >> ~/.bashrc
      echo 'export PATH=$ANDROID_HOME/cmdline-tools/latest/bin:$ANDROID_HOME/platform-tools:$ANDROID_HOME/emulator:$PATH' >> ~/.bashrc
      export PATH="$ANDROID_HOME/cmdline-tools/latest/bin:$ANDROID_HOME/platform-tools:$ANDROID_HOME/emulator:$PATH"
      yes | sdkmanager --licenses > /dev/null 2>&1
      sdkmanager "platform-tools" "build-tools;34.0.0" "platforms;android-34" "emulator" "system-images;android-34;google_apis;x86_64"
      echo "no" | avdmanager create avd -n devin -k "system-images;android-34;google_apis;x86_64" --device "pixel_6"

maintenance: |
  npm install
  cd android && ./gradlew assembleDebug

knowledge:
  - name: build
    contents: cd android && ./gradlew assembleDebug
  - name: test
    contents: npm test
  - name: lint
    contents: npm run lint
  - name: emulator
    contents: |
      Start the emulator: emulator -avd devin -no-window -no-audio -gpu swiftshader_indirect &
      Wait for boot: adb wait-for-device && adb shell getprop sys.boot_completed
      Run on device: npx react-native run-android
initialize:
  - name: "Install Flutter"
    run: |
      cd "$HOME"
      git clone https://github.com/flutter/flutter.git -b stable --depth 1
      echo 'export PATH=$HOME/flutter/bin:$PATH' >> ~/.bashrc
      export PATH="$HOME/flutter/bin:$PATH"
      flutter precache --android
      yes | flutter doctor --android-licenses > /dev/null 2>&1

  - name: "Install Android SDK"
    run: |
      export ANDROID_HOME="$HOME/android-sdk"
      mkdir -p "$ANDROID_HOME/cmdline-tools"
      cd "$ANDROID_HOME/cmdline-tools"
      curl -fsSL https://dl.google.com/android/repository/commandlinetools-linux-11076708_latest.zip -o tools.zip
      unzip -q tools.zip -d latest-tmp
      mv latest-tmp/cmdline-tools "$ANDROID_HOME/cmdline-tools/latest"
      rm -rf tools.zip latest-tmp
      echo "export ANDROID_HOME=$ANDROID_HOME" >> ~/.bashrc
      echo 'export PATH=$ANDROID_HOME/cmdline-tools/latest/bin:$ANDROID_HOME/platform-tools:$ANDROID_HOME/emulator:$PATH' >> ~/.bashrc
      export PATH="$ANDROID_HOME/cmdline-tools/latest/bin:$ANDROID_HOME/platform-tools:$ANDROID_HOME/emulator:$PATH"
      yes | sdkmanager --licenses > /dev/null 2>&1
      sdkmanager "platform-tools" "build-tools;34.0.0" "platforms;android-34" "emulator" "system-images;android-34;google_apis;x86_64"
      echo "no" | avdmanager create avd -n devin -k "system-images;android-34;google_apis;x86_64" --device "pixel_6"

maintenance: |
  flutter pub get

knowledge:
  - name: build
    contents: flutter build apk --debug
  - name: test
    contents: flutter test
  - name: lint
    contents: flutter analyze
  - name: emulator
    contents: |
      Start the emulator: emulator -avd devin -no-window -no-audio -gpu swiftshader_indirect &
      Wait for boot: adb wait-for-device && adb shell getprop sys.boot_completed
      Run on device: flutter run -d emulator-5554
initialize:
  - name: "Install Android SDK"
    run: |
      export ANDROID_HOME="$HOME/android-sdk"
      mkdir -p "$ANDROID_HOME/cmdline-tools"
      cd "$ANDROID_HOME/cmdline-tools"
      curl -fsSL https://dl.google.com/android/repository/commandlinetools-linux-11076708_latest.zip -o tools.zip
      unzip -q tools.zip -d latest-tmp
      mv latest-tmp/cmdline-tools "$ANDROID_HOME/cmdline-tools/latest"
      rm -rf tools.zip latest-tmp
      echo "export ANDROID_HOME=$ANDROID_HOME" >> ~/.bashrc
      echo 'export PATH=$ANDROID_HOME/cmdline-tools/latest/bin:$ANDROID_HOME/platform-tools:$ANDROID_HOME/emulator:$PATH' >> ~/.bashrc
      export PATH="$ANDROID_HOME/cmdline-tools/latest/bin:$ANDROID_HOME/platform-tools:$ANDROID_HOME/emulator:$PATH"
      yes | sdkmanager --licenses > /dev/null 2>&1
      sdkmanager "platform-tools" "build-tools;34.0.0" "platforms;android-34" "emulator" "system-images;android-34;google_apis;x86_64"
      echo "no" | avdmanager create avd -n devin -k "system-images;android-34;google_apis;x86_64" --device "pixel_6"

maintenance: |
  ./gradlew :androidApp:assembleDebug

knowledge:
  - name: build
    contents: ./gradlew :androidApp:assembleDebug
  - name: test
    contents: ./gradlew allTests
  - name: lint
    contents: ./gradlew detekt
  - name: emulator
    contents: |
      Start the emulator: emulator -avd devin -no-window -no-audio -gpu swiftshader_indirect &
      Wait for boot: adb wait-for-device && adb shell getprop sys.boot_completed
      Install APK: adb install androidApp/build/outputs/apk/debug/androidApp-debug.apk

Fehlerbehebung

Emulator startet nicht

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.

Build schlägt wegen SDK-Fehlern fehl

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.

Emulator ist langsam

Der Android-Emulator läuft in Devins VM, daher hängt die Leistung vom System-Image und vom Rendering-Modus ab. Tipps:
  • Verwenden Sie x86_64-System-Images (nicht ARM) für hardwarebeschleunigte Emulation
  • Verwenden Sie -gpu swiftshader_indirect für Software-Rendering, das kein GPU-Passthrough erfordert
  • Verwenden Sie -no-window -no-audio, wenn Devin keine Bildschirmausgabe benötigt (z. B. beim Ausführen instrumentierter Tests über adb)
  • Erwägen Sie ein Geräteprofil mit geringerer Auflösung, wenn die visuelle Qualität nicht entscheidend ist

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.