VS Code Extension · Android

Android dev,
at your own

Nano Drift collapses the build  deploy  observe loop from minutes to seconds. Save a source file; your device refreshes. No terminals. No manual installs. No context switching.

~3s
Save to running
300ms
Debounce window
0
Manual steps
MIT
License

Fire once. Drift forever.

Every file save triggers a fully automated cycle — from detection to a running app — zero interaction required.

Save File
Any .kt / .java source, build.gradle, or settings file
FileWatcher
chokidar detects the change with 300 ms debounce
Gradle Build
Gradle streams live progress to the output channel
ADB Push
APK pushed and app launched automatically via adb
Running
Status bar updates; errors surface in Problems panel

Everything you need. Nothing you don't.

Purpose-built for the Android build cycle inside VS Code — no bloat, no configuration overhead.

Instant Drift Loop
Save a file and watch Gradle build, push, and launch happen end-to-end — fully automated, under 5 seconds on incremental builds.
Live Device Screen
Mirror your Android device or emulator inside a VS Code Webview. Tap, swipe, and type without ever leaving your editor.
Inline Diagnostics
Kotlin and Java compiler errors are parsed and appear directly in the Problems panel with clickable links to the failing line.
Device Management
Connect via USB, Wi-Fi (Android 11+ pairing), or launch a headless AVD emulator — all from the Command Palette.
Build Variants
Switch between debug, release, staging, or any custom variant with one setting. The Gradle task is derived automatically.
Multi-Root Workspace
Work across multiple Android projects simultaneously. Each folder gets its own independent watcher and build cycle.

Common questions, answered.

Everything you were about to open a GitHub issue for.

Why a separate daemon process?

VS Code extensions run in the Extension Host (a Node.js process), which must stay responsive. Long-running Gradle builds would block it. The daemon runs independently, handles blocking I/O, streams progress back over WebSocket, and survives extension reloads.

Why JPEG snapshots before H.264?

Zero dependencies on external binaries (scrcpy). Every Android device supports adb screencap. Snapshots work immediately; H.264 streaming is a drop-in upgrade in Phase 5 without any API changes to the extension ↔ daemon protocol.

Why WebSocket RPC (not stdio)?

Easier to debug (messages are plain JSON), supports push notifications from daemon to extension (build progress, device connect/disconnect), and the same server doubles as the Webview's screen endpoint on /screen.

Why npm workspaces (not a single package)?

The daemon must be packaged separately (it's a long-running Node.js server). The extension only ships the compiled daemon as a binary artifact. Keeping them in separate packages enforces this boundary and avoids circular deps.

Ready to drift?

Install the extension, open your Android project, and save a file. That's the entire setup.

Loading documentation…