# firerpa/lamda: an on-device Android control platform for multi-device fleets

> firerpa/lamda runs a server on the Android device itself and a Python client on the PC, bundling remote desktop, UI automation, MITM capture, Frida and networking behind one API. It is built for clusters of devices, not for a single phone.

**firerpa/lamda** — Android Full-Stack Device Control Platform: WebRTC/H.264 remote desktop, UI/OCR/image-matching automation, one-click MITM, built-in Frida, proxy/VPN/frp/P2P networking, MCP/Agent, 160+ APIs, designed for multi-device clusters and engineered deployments.

- Repository: https://github.com/firerpa/lamda
- Website: https://device-farm.com/
- Stars: 8,493 · Forks: 1,147
- Language: Python
- License: MIT
- Published: 2026-09-10 · Updated: 2026-09-10 · Language: en
- Canonical page: https://hysenlabs.com/projects/firerpa-lamda

## The problem: six tools stitched together for one device

Android automation in practice means Appium for UI, mitmproxy for traffic, frida-server for hooking, adb for plumbing, uiautomator2 for selectors, plus shell scripts to hold it together. Each has its own install path, its own version pinning, and its own failure mode when a device drops off USB. The README frames firerpa/lamda as the answer to that: it describes the project as an all-in-one device control platform and compares itself against "stitching together Appium, mitmproxy, frida-server, adb, uiautomator2, and ad-hoc scripts and ops tools".

The audience is narrow and specific. This is for people running more than a handful of devices: device farms, QA labs, mobile security teams doing dynamic analysis, and anyone who needs automation and traffic capture in the same run. The README is explicit that the architecture is client/server, chosen for centralized scheduling, versioning and fleet control. If you have one phone on your desk, that architecture is overhead you will pay for and never use.

## Server on the device, Python client on the PC

The split is the whole design. A server process runs on the Android device with, per the README, no extra runtime dependencies. It supports multiple generations of Android and works with or without root. The Python client library on the PC talks to that server and exposes UI automation, remote operations, traffic capture, Frida hooks, proxying, distributed networking and MCP through one service and one API.

That means the device-side surface is fixed at install time and the PC side is where your code lives. It also means every capability you use has to cross the wire. The remote desktop is the clearest example: streaming is exposed to a browser, supporting MJPEG and H.264 with software and hardware encoding backends, with frame rate, resolution scale, bitrate and quality as tunables. WebRTC is offered as well, with configurable STUN/TURN servers for NAT traversal. Remote desktop and RPC support end-to-end TLS and service-certificate access control, and an optional WebUI login password. The README notes that remote desktop can be embedded in your own web app over WebSocket, with an allow_origin setting for cross-origin integration.

The interesting architectural claim is Virtual Display. The server can create isolated background displays and run apps and automation there without touching the main screen. The API mirrors the main device API, so d.xxx becomes vd.xxx, and Watchers can be scoped to a virtual display. That is a real difference from tools that assume one screen and one foreground app.

## Installing the client and running a first automation

The PC side is a Python package named lamda, installed from the repository. setup.py declares python_requires of ">=3.6,<=3.14" and lists grpcio, grpcio-tools, grpc-interceptor, cryptography, msgpack, asn1crypto and pem as install requirements. Frida is not installed by default; it sits behind an extra.

```bash
pip install lamda
pip install "lamda[full]"
```

The first command installs the client and its gRPC stack. The second adds the full extra, which setup.py defines as frida>=17.0.0,<18.0.0,!=17.16.*. On Windows the same file pulls in pyreadline==2.1. If you do not plan to use Frida, the first command is enough.

The repository ships an examples directory with runnable scripts, including search_in_taobao.py and activity_jump.py, plus an examples/README.md. The README's own automation description is selector-based: text, resourceId, description and scrollable matchers, with child and sibling chaining for duplicate elements or controls without distinctive attributes. Element-level operations listed include screenshots, wait for appear and disappear, corner and center coordinates, exists checks, Unicode input, stepped swipes, fling scrolling and scroll-to-end.

For screens without a standard view tree, two fallbacks are documented. OCR supports paddleocr, easyocr and custom HTTP backends, and in a cluster the README suggests running recognition centrally rather than loading models on every PC. Image matching runs on the device itself, using template or SIFT matching, so it does not consume PC resources; the README states SIFT is robust to rotation, scale and lighting.

A practical starting point is the visual layout inspector in the WebUI. It highlights elements, supports Tab traversal, shows coordinates and RGB values, and exports the XML layout tree. That is the fastest way to confirm a selector before writing it into a script.

## One-click MITM, and what it does to the device

Packet capture is the feature with the largest blast radius. The README describes one-click MITM as automatic system root CA install, proxy setup, handling of Android version differences, and automatic network restore on exit. It supports global capture, per-package capture, live request and response editing, shared mitmweb, and an upstream HTTP proxy for international traffic. A QUIC downgrade is built in to reduce QUIC interference.

Two details matter for real deployments. First, capture is claimed to work when PC and device share only a single firerpa port, for example over ADB connect or an frp forward, which removes the usual requirement that the PC sit on the same LAN as the device. Second, the CA handling is compatible with mitmproxy, Fiddler and Charles, and the whole thing is API-driven rather than script-only, so install and uninstall of system CAs can sit inside an automation pipeline next to UI steps and Frida hooks. A Windows startmitm.exe is offered for machines without a Python install.

The limitation is inherent to system CA installation: it changes trust state on the device. The README does not document rollback beyond the automatic network restore on exit, and the repository carries a DISCLAIMER.TXT and a SECURITY.md that you should read before pointing this at a device you care about. Treat certificate installation as a device-level change, not a session-level one, and verify the uninstall path yourself before you run it on hardware you cannot reflash.

## Where it is the wrong tool

The README makes three comparative claims that also define the boundaries. It says the client/server model is better for centralized scheduling, versioning and fleet control than on-device script runners like AutoJS. It says it is lighter than Appium. And it says it is more stable than uiautomator2 in multi-device scenarios. Read those together and the intended shape is clear: many devices, one control plane.

So the wrong-tool cases are the inverse. A single-device project gets a server process, a client library and a network hop where a local script would do. A team that cannot root and cannot accept an on-device server has to rely on whatever the non-root mode covers, and the README does not enumerate which features degrade without root. A workflow already built around Appium's ecosystem and language bindings would be trading a large community and existing test infrastructure for a single-vendor stack, and the README does not claim Appium compatibility.

There is also a version ceiling worth noting. setup.py caps Python at 3.14 and pins grpcio and grpcio-tools to ">=1.35.0,<=1.82.0". The Frida extra is frida>=17.0.0,<18.0.0,!=17.16.*, which excludes one specific 17.16 release line. Those pins are how the project keeps the client and the on-device server in step, but they also mean a Python 3.15 environment is out of scope until setup.py changes.

## Alternatives and the actual difference

The obvious alternative is the stack the README names: Appium for UI automation, mitmproxy for capture, frida-server for hooking, adb and uiautomator2 for device access. The difference is not feature coverage, it is where the code runs and who owns the protocol. Appium and uiautomator2 put a driver on the device and speak their own wire protocol from the test runner; mitmproxy and frida-server are separate processes with separate lifecycles. You assemble them, and you own the glue, the version matrix and the reconnect logic.

firerpa/lamda replaces the glue with one server and one client API. The README's claim is "one source of capabilities, unified configuration, connected workflows". The trade is that you inherit one project's release cadence and one project's bugs instead of five independent ones. When mitmproxy breaks, you pin an older mitmproxy. When the platform breaks, you pin lamda, and you may also have to match the on-device server version, which is not a pip install.

AutoJS is the other comparison the README draws, and the distinction is sharper: AutoJS runs the automation on the device, so it is immune to PC-side connectivity but poor at centralized scheduling and versioning across a fleet. If your problem is "one phone, one script", AutoJS is the smaller answer. If your problem is "forty phones, one dashboard", the client/server split is the point.

## Maintenance, licensing and upgrade cost

The repository is not archived, and the last push was on 2026-08-30. Releases v10.8, v10.6 and v10.4 landed on 2026-08-30, 2026-08-16 and 2026-08-09 respectively, so the project is shipping on a roughly two-week cadence across the three releases shown. The default branch is named 10, which lines up with the v10.x release line.

The upgrade cost sits on two sides. The PC side is a pip package with pinned gRPC ranges, so upgrading means re-resolving grpcio and grpcio-tools within the declared window, and re-checking the Frida extra if you use it. The device side is the server, and the README does not describe an in-place upgrade path for it. In a fleet, that is the expensive half: every device carries a server version, and a client/server protocol change means touching each one. The CHANGELOG.txt at the repository root is where you would check before rolling a fleet forward.

The licence is MIT, per the repository's LICENSE file. MIT is permissive, so it does not impose copyleft obligations on your own code. That said, this project installs system root CAs and intercepts traffic, and the repository ships a DISCLAIMER.TXT and a SECURITY.md alongside the licence. Those documents, not the MIT text, are what govern how you are expected to use the capture features. Read them; this is not legal advice, and the licence grant does not answer the question of whether you are authorised to intercept a given device's traffic.

## Conclusion

Adopt firerpa/lamda if you run several Android devices at once and want automation, capture and hooking behind one client API instead of four separate toolchains. Do not adopt it if you only need one phone driven by a script, or if you cannot root or cannot accept a server process on the device. Before committing, verify that your Android version is covered by the documentation, that the Frida extra resolves against your Python version, and that the licence and the project's DISCLAIMER.TXT fit how you intend to use packet capture.

## FAQ

### What is firerpa/lamda?

It is an Android device control platform made of a server that runs on the device and a Python client library on the PC. The README describes it as covering UI automation, remote desktop, traffic capture, Frida hooking, proxying and MCP through one service and API.

### Which Python versions does the firerpa/lamda client support?

setup.py declares python_requires as ">=3.6,<=3.14", so Python 3.15 and later are outside the declared range. It also pins grpcio and grpcio-tools to ">=1.35.0,<=1.82.0".

### Does firerpa/lamda need root on the Android device?

The README states it works with or without root, and lists root/non-root mode as a supported configuration. It does not enumerate which features degrade when the device is not rooted.

### Is Frida included when I install firerpa/lamda?

No. setup.py puts Frida behind an extra named full, defined as frida>=17.0.0,<18.0.0,!=17.16.*, so you install it with pip install "lamda[full]" rather than the base package.

## Sources

- [firerpa/lamda on GitHub](https://github.com/firerpa/lamda)
- [License: MIT](https://github.com/firerpa/lamda/blob/10/LICENSE)
- [Project website](https://device-farm.com/)
- [README](https://github.com/firerpa/lamda/blob/10/README.md)
- [Releases](https://github.com/firerpa/lamda/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/firerpa-lamda