One Android service replaces several separate control tools
FIRERPA puts a server on an Android device and drives it from Python, a browser, HTTP calls, or an MCP client. Its README covers screen viewing, touch and keyboard control, selectors, OCR, image matching, packet capture, Frida, shell access, proxies, VPNs, and remote fleet connections. A test farm can keep one address and certificate per device instead of operating unrelated control services.
The README names more than 160 Python APIs and support for Android 6.0 onward, both rooted and non-rooted. A team only trying to tap a login button will inherit configuration for capabilities it may never authorize. FIRERPA makes more sense when UI actions must be chained with device state, traffic observation, file transfer, or long-running fleet tasks. For a normal regression suite, Appium or uiautomator2 is easier to reason about.
Remote control includes browser video, terminals, and file access
The browser interface can stream MJPEG or H.264, accept touch input, share a clipboard, browse files, and expose a terminal. WebRTC accepts configurable STUN and TURN services. Layout inspection shows coordinates, colors, and the XML tree, which helps turn a manual interaction into a selector. Android 10 or newer is required for the documented live-audio path.
Those functions put a great deal behind one service port. The README documents TLS, service-certificate access, and an optional Web UI password. Use all of them on any routed network. An endpoint combining screen contents, input, files, and terminal commands needs access logs, certificate rotation, network policy, and a clear device-owner boundary.
What happened when we ran it
Our Debian sandbox installed the Python side in 17 seconds. The operation added 44 packages and used 82 MB on disk. Building the package succeeded in 9 seconds, and pip-audit found 0 known vulnerabilities in the installed set. Those results say nothing about the Android service binary, optional OCR systems, model endpoints, or fleet infrastructure.
There was no tests script or target, so we skipped tests. Our scan also found 0 CI workflow files, no Dockerfile, and no tests directory in the 107-file checkout. The repository contained about 6,132 source lines and occupied 1.4 MB before installation. A successful package build confirms packaging mechanics in our environment. It does not confirm selector behavior, device compatibility, streaming, or privileged operations.
Device preparation is the larger part of setup
The Python client needs a running Android service and its certificate before Device calls become useful. Deployment choices include a one-click app using root or Shizuku, a Magisk module, manual extraction, and ROM integration. Architecture, Android version, root method, vendor changes, and emulator behavior can affect the available path. The client/server split moves installation work onto every controlled device.
Version v10.6 was released on August 16, 2026, the day of the repository's latest recorded push. GitHub showed 8,239 stars and 40 combined open issues and pull requests. Issue 121 describes missing Frida tooling on an armeabi-v7a device, issue 115 reports a LAN connection failure, and issue 100 describes incorrect browser touch mapping on one Android 14 phone. Test every model and ROM you plan to keep online.
Selectors, virtual displays, and OCR cover different screen types
Standard apps can be driven through text, resource ID, description, hierarchy, child, and sibling selectors. A UI Watcher reacts to transient screens. Virtual displays let automation use an isolated background display while the physical screen remains available. When no useful view tree exists, the client can call OCR services or perform device-side template and SIFT matching.
Issue 112 reports that sibling() returned child-level elements in the reporter's hierarchy, while issue 118 asks for examples of the multi-touch recording classes. Keep screen captures and dumped XML with failed runs, and avoid assuming that a selector proven on one app build will survive a redesigned hierarchy. Image matching also brings scale and theme sensitivity.
MCP can operate a device, which makes permission design mandatory
The service exposes MCP over streamable HTTP with tools, resources, prompts, progress notifications, and logs. Its built-in agent can use an OpenAI-compatible API, including vision, to act on a device. That works for an agent lab with dedicated test phones. It is a poor reason to connect a personal handset full of accounts and messages. Store model credentials and the device certificate separately.
FIRERPA can install a system root CA, change proxies, downgrade QUIC for capture, and bundle Frida helpers. Issue 135 reports an HTTP/2 TLS handshake failure in one capture setup. Use these features only on devices and applications you are authorized to test, with disposable test identities and a documented cleanup procedure.
Active releases support a trial, while validation remains your job
FIRERPA earns a trial for an experienced Android lab that already operates rooted devices, certificates, and restricted networks. The 26-second install-plus-build result makes the PC client easy to inspect, but the missing test target leaves device behavior outside our Debian evidence. Start with one representative handset and only enable the capabilities the workflow requires. A focused test driver or remote screen remains the better choice for a narrow job.