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 can build and run Android applications directly on its own machine — giving it the Android equivalent of Computer Use and browser interaction. Devin can open the app, inspect behavior, reproduce issues, and verify changes in the environment where the application actually runs. Combined with video recordings, Devin can send you a recording as proof.
With Android emulator support enabled, Devin can handle the full mobile development loop:
Android emulator support is built on the same declarative configuration system as the rest of Devin’s environment. You add the Android SDK and emulator to your blueprint, and Devin’s snapshot builds a VM with everything pre-installed. Every session boots from that snapshot with the emulator ready to go. During a session, Devin interacts with the emulator in two ways:
| Method | What it does | When to use it |
|---|---|---|
adb (command line) | Install APKs, run tests, capture logs, take screenshots | Automated builds, instrumented tests, logcat debugging |
| Computer Use (desktop) | Tap, swipe, type, and navigate the emulator’s screen visually | End-to-end UI testing, visual verification, video recordings |
The emulator window runs on Devin’s desktop, so you can watch Devin interact with your app in real time via the Desktop tab in the webapp.
Let Devin do it (recommended)
Manual blueprint setup
The easiest way to get started. Devin analyzes your Android project, installs the right SDK components, and configures the emulator for you.
1
2
3
If you know exactly what SDK components and emulator configuration you need, you can write the blueprint yourself.
1
2
3
4
A typical Android emulator support blueprint installs:
| Component | Purpose |
|---|---|
| Android SDK command-line tools | Core SDK management (sdkmanager) |
| Platform tools | adb, fastboot for device communication |
| Build tools | aapt2, d8, zipalign for building APKs |
| Android platform (e.g., API 34) | Target API level for your app |
| Emulator + system image | The virtual device itself |
Ask Devin to build and run your app at any point during a session — no special syntax needed, just natural language:
Devin will launch the emulator (if it isn’t already running), build and run your app, and interact with it — using adb for programmatic actions and Computer Use for visual interactions.
Android emulator support plugs directly into Devin’s Testing & Recordings workflow. After creating a PR:
This works the same way as web app testing — the only difference is that Devin interacts with the emulator window instead of Chrome.
After testing your Android app, Devin writes down what it learned — how to start the emulator, which Gradle tasks to run, how to navigate to the feature under test — and proposes creating or updating a Skill via PR. You can merge the PR as-is or tweak it to refine the instructions. Over time, this means Devin gets better at testing your Android project. Each session’s learnings build on the last — so the second time Devin tests your app, it already knows how to build it, which activity to launch, and which flows matter most. You can also prompt Devin to do this at any time (e.g., “create a skill for how to build and test this Android app”). See the Skills guide for full details.
The Android emulator runs as a window on Devin’s Linux desktop. This means:
For details on how desktop interaction works, see Computer Use.
adbDevin can also interact with the emulator programmatically via adb, which is useful for:
adb install app-debug.apkadb shell am instrument -w com.example.test/androidx.test.runner.AndroidJUnitRunneradb logcat to debug crashes or unexpected behavioradb exec-out screencap -p > screenshot.pngadb shell input tap 500 800 for scripted interactionsDevin chooses between adb and Computer Use depending on the task — adb for speed and automation, Computer Use for visual verification and complex UI flows.
Copy-paste blueprints for common Android setups. Each template is self-contained — paste it into your blueprint editor and save.
Common causes: KVM not available in the VM, insufficient memory, or a missing system image.
Fix: Devin can attempt to configure KVM automatically when it detects the emulator needs hardware acceleration — in most cases, this resolves the issue without manual intervention. If KVM still isn’t available after Devin’s attempt, the emulator can fall back to software rendering mode — add -no-accel to the emulator launch command, though performance will be reduced. Also check that your blueprint installs the emulator and a compatible x86_64 system image.
Common causes: Missing SDK components, incorrect ANDROID_HOME path, or Gradle can’t find the right build tools version.
Fix: Verify that ANDROID_HOME is set correctly in your blueprint and that sdkmanager installs the platform version and build tools version your project requires. Check your project’s build.gradle for compileSdk, targetSdk, and buildToolsVersion and match them in the blueprint.
The Android emulator runs inside Devin’s VM, so performance depends on the system image and rendering mode. Tips:
x86_64 system images (not ARM) for hardware-accelerated emulation-gpu swiftshader_indirect for software rendering that doesn’t require GPU passthrough-no-window -no-audio when Devin doesn’t need the visual display (e.g., running instrumented tests via adb)Common causes: Desktop mode is not enabled, the emulator window is not visible, or the emulator is running in headless mode.
Fix: Ensure Desktop mode is enabled in your organization’s settings. If you need Devin to visually interact with the emulator, launch it without the -no-window flag so the emulator GUI appears on Devin’s desktop. Check that the emulator has fully booted (adb shell getprop sys.boot_completed should return 1) before asking Devin to interact with it.
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。