FIRERPA (lamda): an on-device Android control server with remote desktop, MITM and Frida in one port

The problem FIRERPA targets: five tools, five configs, one device

The README frames the problem itself: teams stitch together Appium, mitmproxy, frida-server, adb, uiautomator2 and ad-hoc scripts and ops tools. Each of those has its own startup step, its own port, its own way of attaching to a device, and its own failure text when the device drops off the bus. FIRERPA's answer is to run a server on the device and expose everything through one service and one API, so the PC side is a Python client rather than a collection of daemons. The stated audience is anyone running multi-device clusters for long periods: device farms, reverse-engineering work, mobile security testing, and automation that has to survive overnight. The repository description adds MCP and agent support, which points at a second audience: people wiring an LLM agent to a real handset rather than to a simulator. If your work is a single script against a single phone, the consolidation buys you less than it costs.

Client/server split and what runs where

The architecture is client/server, and the README is explicit that the server runs on the device with no extra runtime dependencies. The Python client library lives on the PC and issues commands over a single port. That choice has consequences. Central scheduling, versioning and fleet control sit on the PC, which is where you want them if you manage many devices. The device carries only the service. The README contrasts this with on-device script runners such as AutoJS, and claims the split is lighter than Appium and more stable than uiautomator2 in multi-device scenarios. Those are the project's own comparisons, not measured results, and the README does not publish the conditions behind them. Treat the stability claim as a design intention to verify on your own hardware. The same single port carries remote desktop, terminal, file transfer and the API, which is convenient behind NAT and less convenient when you want to firewall capabilities separately.

Remote desktop: MJPEG, H.264 and WebRTC over one port

The browser-based remote desktop needs no dedicated PC client and works over LAN or across networks. Streaming supports MJPEG and H.264, with software and hardware encoding backends. Frame rate is documented as up to 60fps, and resolution scale, bitrate and quality are tunable, which matters on weak links. WebRTC is also supported with configurable STUN and TURN servers, aimed at NAT traversal and lower end-to-end latency in cross-region setups. Multi-user concurrent access is supported, so two people can look at the same screen during a debugging session. Bidirectional clipboard and live audio on Android 10+ are included. The WebUI also has a visual layout inspector that highlights elements, supports Tab traversal, shows coordinates and RGB values, and exports the XML layout tree. That last feature is the one I would weigh most: validating selectors in the same view where you watch the screen shortens the loop between seeing a broken tap and fixing the matcher. End-to-end TLS and service-certificate access control are documented, along with an optional WebUI login password. The embedding path uses WebSocket with an allow_origin setting, so you can put live video, touch and terminal into your own web app.

Selectors, watchers and virtual displays

Automation is selector-based: text, resourceId, description, scrollable and other matchers, with child and sibling chaining for duplicate elements or controls with no distinctive attributes. At the element level the API covers screenshots, wait for appear and disappear, corner and center coordinates, exists checks, Unicode input, stepped swipes, fling scrolling and scroll-to-end. The README states it can coexist with other accessibility services on Android 8.0+ and improves WebView node discovery for hybrid apps. Two features stand out. UI Watcher listens for UI changes and runs clicks, key events or counters when conditions match, which is how you auto-dismiss consent dialogs, update prompts and ads without polluting the main flow; multiple conditions and per-event enable flags are supported. Virtual Display creates isolated background displays where apps and automation run without touching the main screen. The virtual-display API mirrors the main device API, documented as d.xxx mapping to vd.xxx, and watchers can be scoped to a virtual display. For games and custom-drawn UI with no usable view tree, OCR (paddleocr, easyocr or a custom HTTP backend) and on-device image matching (template or SIFT) fill the gap. Running OCR centrally in a cluster instead of loading models on every PC is a sensible default that the README mentions without detailing the deployment.

Getting it running, and what the README does not spell out

This review is based on the repository and its documentation, not on an installation. The README documents a Python client library on the PC against an on-device server, and the badges state Python 3.6+ and Android 6.0+, with both root and non-root modes. A Windows startmitm.exe is offered for capture without a Python install. The README names specific interfaces rather than a full setup script: the virtual-display API is documented as d.xxx to vd.xxx, the WebSocket embedding uses allow_origin for cross-origin integration, and the WebUI can take a custom login password. Beyond those, the cleaned README does not give the exact package name, the install command, or the daemon start line, so I cannot state them here without inventing them. The linked documentation at device-farm.com/docs/en/ and the llms-full.txt file are where the concrete commands live. Anyone evaluating this should read those two pages before writing an install plan, and should confirm which of the 160+ APIs the README counts are available in non-root mode, because the badge advertises both modes but the README does not enumerate the difference.

One-click MITM, Frida and the limits of an on-device server

The capture story is the most opinionated part. One-click MITM handles system root CA installation, proxy setup, Android version differences and automatic network restore on exit, so you are not toggling certificates and proxy settings by hand. Global capture, per-package capture, live request and response editing, a shared mitmweb, and an upstream HTTP proxy for international traffic are listed. A built-in QUIC downgrade is there to reduce QUIC interference, which is the usual reason a capture session shows nothing for a modern app. The README notes capture still works when PC and device share only the FIRERPA port, for example over adb connect or frp forwarding. The API-driven path lets you install and uninstall system CAs compatible with mitmproxy, Fiddler and Charles, and embed capture in a pipeline next to UI steps and Frida hooks. The limitation is structural: the server runs on the device, so if the service stops, everything stops, including the remote desktop you might be using to diagnose the failure. Certificate installation and proxy changes touch system state, and while automatic restore on exit is documented, a hard kill or a reboot mid-session is the case to test. Non-root devices will not get the same reach for system CA installation, and the README does not promise otherwise.

Where Appium or uiautomator2 remains the better pick

The honest comparison is with the tools FIRERPA replaces. Appium is a WebDriver-protocol server with a large ecosystem of language clients and a long history of CI integrations; if your test suite is already written against the WebDriver API and your team knows it, moving to a Python client library with its own API surface is a rewrite, not a swap. uiautomator2 is a thinner Python layer over Android's own instrumentation with a much smaller footprint; for a handful of devices running short scripts, its simplicity is an advantage and FIRERPA's server is overhead. mitmproxy alone, without the automation layer, is the right tool when capture is the only job and you do not want a control server on the handset. FIRERPA's own claim is that it is a functional superset of these stacks and chains automation, capture, Hook and ops in one platform. That claim is only worth the consolidation if you actually use more than one of those capabilities in the same workflow. If you use one, you are paying for the other three.

Licence, maintenance and upgrade cost

The repository is MIT-licensed, which is permissive and compatible with commercial use and redistribution, though the bundled or separately downloaded components (mitmproxy-compatible CA tooling, Frida, Magisk and Xposed are named in the topics and README) carry their own licences and you should check each before shipping. This is a description of the licence field, not legal advice. Maintenance looks active: the supplied release list shows v10.8 on 2026-08-30, v10.6 on 2026-08-16 and v10.4 on 2026-08-09, a roughly two-week cadence across three releases, and the last push matches the v10.8 tag. The default branch is named 10, which is unusual and worth knowing before you clone. A fast cadence on a platform that patches Android internals is a positive signal for compatibility and a cost signal for you: a server that installs system certificates and hooks processes will need re-testing against new Android builds, and the release notes are where that work is announced. Budget for a re-validation pass each time you move Android versions, not just each time you upgrade FIRERPA.

Editorial conclusion

Adopt FIRERPA when you are running more than one Android device for long stretches and you want capture, hooks and UI steps in the same Python process, because that is the workflow its client/server split is built around. Do not adopt it for a single phone you automate occasionally, or if your team cannot maintain an on-device service, since the server is the part that has to keep running. Before committing, verify the root and non-root paths on your exact Android builds, confirm the H.264 and WebRTC paths behave on your network, and read the MIT licence text against how you plan to redistribute the bundled components.

Official sources

1. firerpa/lamda on GitHub
2. License: MIT
3. Project website
4. README
5. Releases