serve-avd Streams Android Emulators to Browsers

serve-avd is an open-source TypeScript project by hsandhu that serves a running Android Emulator into a browser window. It deals with a very plain problem: coding agents can edit mobile apps, but they often cannot easily see and touch the Android screen they are supposed to fix. The useful takeaway is to treat the emulator as a reviewable browser surface, not as a magic autonomous tester. For developers learning how to use cursor agent on mobile UI work, serve-avd is interesting because it gives Cursor, Anysphere’s AI code editor, a cleaner object to reason around: a visible app screen, a repo, and a human who can verify the result.

See what serve-avd actually does

serve-avd is a small bridge between Android Debug Bridge and the browser. It captures the emulator screen through adb screenrecord, serves video as an H.264 WebCodecs stream with an MJPEG fallback, and sends input back over a WebSocket control channel.

That design is why the project felt immediately legible on Hacker News. It is not asking you to add a test SDK, root a device, or instrument the app under test. It works with a running Android Emulator, and the README says it can also work with most physical devices over adb.

The trap is to mistake “browser window” for “browser automation.” serve-avd is closer to a remote screen and input layer. Your agent can inspect code, receive screenshots or instructions, and help drive fixes, but the browser preview does not turn Android into a DOM that an agent can query like Playwright.

A concrete workflow looks like this: you start your local emulator, run serve-avd, open the preview URL, then ask a Cursor agent in agent mode to fix the UI bug you are seeing. The browser becomes the shared artifact. You can say, “The settings toggle clips on Pixel 7, landscape, dark mode,” and the agent can work against code while you keep the screen honest.

Notice the trick developers cared about

The clever part is that serve-avd uses boring, available Android plumbing. adb screenrecord already knows how to get frames from the emulator. WebCodecs already gives modern browsers a good way to decode video. WebSockets are enough for taps, drags, keys, navigation buttons, screenshots, and theme toggles.

That makes the project feel like the Android port of a familiar pattern: make a local simulator or emulator reachable through a browser, then hand that URL to a person or an agent tool. The README explicitly credits Evan Bacon’s serve-sim design as the inspiration, rebuilt around what Android and adb provide.

The trap is latency and fidelity. A streamed emulator is good for visual inspection, smoke testing, and agent-guided debugging. It is not a replacement for device labs, accessibility audits, native performance profiling, or deterministic end-to-end tests.

This is also why the “agent tools” angle matters without swallowing the whole story. Cursor agents, custom agents, and cursor skills are most useful when they get a tight loop: repo context, a clear task, a visible failure, and fast review. serve-avd gives mobile work one more visible failure surface.

Try it when the screen is the missing artifact

The best reason to try serve-avd is simple: the bug is visible, but hard to describe from code alone. Layout clipping, keyboard overlap, dark-mode regressions, gesture behavior, and navigation weirdness are all better when the agent can be pointed at a real screen state.

A good “how to use cursor agent” exercise here is to give the agent a narrow Android task and keep the emulator preview open while it edits. Do not ask for “fix the app.” Ask for “fix the clipped account row on the profile screen at 360dp width; preserve the existing design tokens; show me the changed files before I run it.”

Use Cursor rules to keep that request bounded. A repo-level .cursor/rules/android-ui.mdc file can say what the agent may change and what it must not invent.

---
description: Android UI fixes for the mobile app
---

- Prefer existing Compose components and theme tokens before adding new styles.
- Do not change navigation routes without asking.
- When fixing a visual bug, include the screen, device size, and theme in the final note.
- Before finishing, list the files changed and the manual emulator check to repeat.

That small rule is not ceremony. It gives Cursor agent mode a local boundary. If you use the related training topic, this is the same idea behind cursor subagents and cursor skills: keep reusable behavior close to the work, and make the activation surface obvious.

The trap is remote control without review. A browser-hosted emulator can make cursor background agents more tempting for mobile work, but the final pass still needs a human eye. The artifact should be “here is the screen state I checked,” not only “tests passed.”

Fit it before you wire it into your day

serve-avd fits best when Android UI is a bottleneck and the cost of sharing an emulator screen is higher than the cost of running one more small tool. It is especially handy for local development, LAN demos, remote machines tunneled back to you, or agent-assisted bug fixing where the emulator is already running.

It is probably overkill when your problem is pure business logic, API shape, generated code, or a unit-test failure that never needs the screen. It is also the wrong first tool if your repo has no stable emulator setup. Fix that first.

A useful mental model: serve-avd is a window, not an oracle. Pair it with Cursor rules, an AGENTS.md boundary, and a review checklist if you want the agent’s work to be repeatable.

For example, an Android repo might add this tiny AGENTS.md note near the app module:

# Android app agent boundary

- Work inside `app/` unless the task explicitly names shared modules.
- Use the running emulator preview only for visual verification notes.
- Do not add dependencies for one-screen UI fixes without approval.
- Final response must include: changed files, emulator state checked, and remaining risk.

That note keeps the browser stream in its proper place. It helps the agent report what it saw, while leaving ownership of the actual product behavior with the developer.

Try it safely checklist

Copy this before your first serve-avd experiment. Keep it boring on purpose.

• Start with a disposable branch, not an open release branch.
• Confirm adb devices shows exactly the emulator or device you intend to expose.
• Run serve-avd from the project source or current README instructions.
• Keep the preview local first; only tunnel it after you understand what is exposed.
• Use one narrow task: one screen, one bug, one expected behavior.
• Add a Cursor rule or AGENTS.md note that limits files, dependencies, and final reporting.
• Ask the Cursor agent to explain the intended change before it edits.
• After edits, manually repeat the emulator state: device size, screen, theme, and gesture.
• Save a screenshot or short note in the PR if the change is visual.
• Stop the server when you are done, especially if you opened it beyond localhost.

The trap to avoid is treating the streamed emulator as harmless because it is “just a preview.” It can send input to a real emulator or adb-connected device. Treat it like a remote-control surface.

Common questions

• How to use cursor agent with serve-avd?

  Use Cursor agent mode for the code changes and serve-avd for the visible Android surface. Start the emulator, open the serve-avd browser preview, then give the agent one narrow UI task with the screen state, expected behavior, and files it should avoid. Review the diff and manually re-check the emulator before accepting the result.

• Does serve-avd require app instrumentation or root access?

  No, the README describes serve-avd as working through Android Emulator and adb, with no root, plugin, or app instrumentation required. That is the core appeal: it sits outside your app. The caveat is that it still depends on adb access, so your emulator or device setup must already be healthy.

• Is this a replacement for Android UI tests?

  No, serve-avd is not a replacement for deterministic Android UI tests. It is better understood as a live visual and control surface for inspection, demos, and agent-assisted debugging. Keep Espresso, Compose UI tests, snapshots, or manual QA where they already catch repeatable regressions.

• Can Cursor background agents use this kind of setup?

  Maybe, but the safest first use is supervised. A browser-hosted emulator can make remote or background work easier to inspect, yet mobile UI changes still need a human review loop. If you try it with cursor background agents, require a final receipt: changed files, emulator state checked, and known uncertainty.

• When is serve-avd not worth adding?

  Skip it when the task does not need a screen. Backend fixes, refactors, schema changes, and failing unit tests usually do not benefit from a streamed emulator. The tool earns its keep when the hard part is seeing and reproducing an Android behavior quickly.

Best ways to use this research

• Best for: Android developers using Cursor agents on visual bugs where the emulator screen is the missing shared artifact.
• Best first artifact: Add a small .mdc rule or AGENTS.md boundary that tells the agent which files it may touch and what emulator state to report.
• Best comparison angle: Compare serve-avd against your current screen-sharing or manual QA loop, not against full test automation.
• Best safety habit: Keep the first run local, narrow, and disposable; remote tunneling should come after you know exactly what the preview can control.

Further reading

• Cursor — Agent
• Cursor — Rules
• serve-avd — source

Next step

Try serve-avd on one visible Android bug, then decide whether the browser preview made the Cursor review loop clearer. If it did, keep the smallest rule file that made the agent’s work safer.

One methodology lens

One useful way to read this through our methodology is the Plan step: delegate first-pass decomposition and dependency mapping, review the sequencing and assumptions, and keep ownership of scope and priorities. If that split is still fuzzy, the workflow usually is too.