一个项目顶 Appium + mitmproxy + Frida + ADB?FIRERPA 到底是什么

先认识这个 Android 全栈设备控制平台，以及它为什么值得测试工程师关注。

做过 Android 自动化测试的人，电脑里通常不会只有一个工具。

写 UI 自动化，可能装着 Appium 或 uiautomator2；操作设备，ADB 基本离不开；接口行为不符合预期，要打开抓包工具；需要进一步观察 App 内部行为，又可能用到 Frida；测试机不在身边，还得解决远程控制；设备一多，又开始考虑设备管理、任务调度和执行环境。

每一个工具单独拿出来，都解决了一个明确的问题。真正麻烦的地方往往不是“我没有工具”，而是：完成一次测试，我为什么需要在这么多工具之间来回切换？

最近我开始系统研究一个已经持续演进多年的 Android 开源项目：FIRERPA。第一次看它的能力列表，很容易产生一种感觉：这项目是不是想把 Android 测试工程师常用的工具都塞进去？还真有点这个意思。

FIRERPA 的前身叫 Lamda。按照项目当前官方定义，它是一个面向 Android 的一体化设备控制平台，也可以理解为 Android Full-Stack Device Control Platform。

它不是单纯的 UI 自动化框架。远程桌面、UI 自动化、Watcher、OCR、图像匹配、MITM 抓包、Frida、ADB、终端、应用与文件操作、代理与 VPN、设备控制、Python API、多设备，以及 MCP / Agent，都在它的能力范围里。

截至 2026 年 9 月 22 日，官方 GitHub 仓库约 8.4k Stars；官方仍以 160+ Python API 描述其客户端能力，覆盖应用、文件、命令、设备状态、网络代理、系统控制和自动化等类别。

图 B｜FIRERPA 能力地图：从远程控制到 MCP / Agent

这个定位非常重要，因为它决定了 FIRERPA 和 Appium 并不是简单的“A 和 B 谁更强”。它讨论的是更完整的设备能力，而不仅是一条 UI 自动化执行链。

假设今天需要测试一个支付场景：打开 App，选择商品，提交订单，确认支付，最后进入支付成功页。只看 UI 步骤，似乎很简单。

但实际测试过程中，一旦点击“确认支付”以后页面持续 Loading，最终提示支付失败，问题马上复杂起来：UI 点击成功了吗？支付请求发出去了吗？请求参数正确吗？服务端返回了什么？App 收到响应了吗？Activity 有没有变化？页面状态为什么没有更新？设备本身是否异常？

图 A｜传统 Android 测试工具链：能力分散、上下文分散

于是 Appium 负责 UI，ADB 负责设备与命令，mitmproxy 负责网络，Frida 负责运行时观察。单独看每一部分都没问题，问题在于这些能力来自不同工具。

安装方式不同、配置不同、连接方式不同、API 不同、日志不同，权限模型也不同。对于个人调试可能还能接受；但设备越来越多、脚本越来越多、测试任务越来越复杂以后，维护成本就开始显现。

FIRERPA 的思路不是再增加一个孤立工具，而是把分散的 Android 设备能力重新放进同一套服务里。

图 C｜PC → FIRERPA Server → Android 的客户端 / 服务端架构

FIRERPA Server 直接运行在 Android 设备侧。PC 端可以通过浏览器，或者使用官方提供的 lamda Python Client 与设备交互。

如果以前写过 Selenium、Appium 一类自动化，这种客户端 / 服务端模型并不陌生。区别在于，FIRERPA 服务端暴露的不只是 UI 驱动，还包含设备、网络、文件、系统与运行时观察能力。

FIRERPA 启动后，可以直接通过浏览器进入设备控制台。官方文档给出的标准公开端口是 65000，例如：

http://192.168.0.2:65000

打开以后，可以在浏览器里查看并操作 Android 设备画面，也可以使用内置终端、上传和下载文件。官方文档还说明：远程桌面支持多用户同时访问；音频转发要求 Android 10+；浏览器与设备之间的剪贴板同步要求 HTTPS。

对于一台手机，这只是方便。但当设备从 1 台变成 10 台、50 台，远程访问、统一入口、设备发现、任务调度与权限控制就不再只是“顺手”，而开始成为 Device Farm 的基础。

远程控制很直观，但我们不是为了每天在浏览器里手工“遥控手机”。真正需要的是自动化。

FIRERPA 提供基于 Selector 的 UI 自动化能力，可以按 text、resourceId、description、scrollable 等属性寻找元素；对于重复元素与复杂层级，也支持 child / sibling 等链式定位。

d(text="Login").click()  Find Element → Wait → Click → Input → Swipe → Check → Screenshot

这套基本逻辑和常见移动端 UI 自动化很接近。FIRERPA 并没有为了“新”而彻底重造一套操作思维，它真正有意思的地方是：UI 自动化只是整个设备平台中的一个模块。

移动端自动化里经常遇到没有 resourceId、自定义控件、Canvas、游戏界面、特殊 WebView，或者 UI Tree 与实际视觉界面根本对不上的情况。传统 Selector 在这些页面上就会变得吃力。

图 D｜Selector、Watcher、OCR 与 Image Matching 的协同关系

FIRERPA 在 Selector 之外还提供 OCR 和 Image Matching，让文字识别与视觉匹配补上标准节点树的盲区。

另外一个对工程稳定性很实用的能力是 Watcher。Watcher 可以持续监听 UI 变化，在满足条件时执行点击、按键或计数。测试过程中突然出现通知权限、版本升级、用户协议或广告弹窗时，它可以先处理干扰，再让主流程继续。

如果 FIRERPA 只有远程桌面、Selector、OCR 和图像匹配，它可能只是一个功能比较丰富的 Android 自动化工具。继续往下看，区别就出现了：它把 Traffic Capture / MITM 也整合进来。

图 E｜UI Action → Network → Response → UI Result 的测试证据链

以前 UI 自动化失败，脚本可能只能告诉你：期望首页，实际仍停留在登录页。如果同时拿到网络行为，我们就可以看到登录请求是否发出、返回了什么状态码、业务错误码是什么。

测试结论于是可以从“登录失败”，进化成“登录操作已触发 /login 请求，服务端返回 401，因此页面没有进入首页”。

这是 FIRERPA 和很多常规 UI 自动化平台区别很大的地方。Frida 是一套动态插桩工具，可以在获得授权的测试、调试和安全研究场景中观察运行时行为。传统方式往往需要单独准备 frida-server、Android 设备和 PC 端 Frida Client。

FIRERPA 官方仓库明确把内置 Frida、脚本持久化、spawn 注入等列为平台能力。对测试工程师来说，重点不只是“逆向”，而是：当 UI 与 Network 仍不足以解释问题时，是否可以继续向 App 内部观察。

UI 点击提交     ↓ Java Method     ↓ Request Builder     ↓ Network Request

这会让测试可观察范围继续向下扩展。当然，这类能力只应该用于自己拥有或明确授权的应用与测试环境。后续的 FIRERPA + Frida 篇会从测试和调试视角单独展开。

不是。但这里必须说清楚边界。FIRERPA 支持 Root，也支持以 shell / Non-root 权限运行。官方 Quick Start 为无 Root 用户提供了通过 Shizuku 启动的路线。

图 F｜Root 与 Non-root + Shizuku：可用路径不同，权限边界不同

Shizuku 的官方定位，是让普通应用借助由 ADB 或 Root 启动的服务进程调用系统 API。它并不会让一台没有 Root 的设备凭空获得完整 Root 能力。

FIRERPA 官方文档同样明确：非 Root / shell 权限下，部分特权功能会受到限制，但主要功能仍然可以使用。所以后续搭环境时，需要分别实测 Root Device 与 Non-root + Shizuku，而不是简单说“装个 Shizuku 就等于 Root”。

如果只看 Remote Desktop、UI Automation、MITM、Frida 和 Python API，已经足够写一个很长的系列。但 FIRERPA 当前还提供 MCP / Agent。

官方文档描述的 MCP Server 路径是 /mcp/，支持 Tool Call、Resource、Prompt、进度通知和日志；同时提供内置 agent 命令，可连接兼容 OpenAI API 与 Tool Call 的模型服务，并支持视觉模式。

自然语言任务     ↓ 大模型 / MCP Client     ↓ FIRERPA MCP / Agent     ↓ Android Device

这部分非常值得单独研究，但第一篇只把它放进能力全景，不展开配置和实战。后面的系列会真正把 FIRERPA 接入大模型，观察它是否能在不预先写死每一步 UI 脚本的情况下操作 Android，更重要的是：到底稳定不稳定。

看到这里，很多测试同学会问：有 FIRERPA 以后，是不是就不用 Appium 了？我不建议这么理解，因为两者定位并不相同。

这里不是做“谁赢了”的比较。Appium 最大的优势之一仍然是成熟的跨平台自动化生态；FIRERPA 的特点则更像是围绕 Android 设备，把自动化、控制、网络、动态分析和工程化能力整合到一起。

如果只写一篇“发现一个很牛的开源项目”，价值其实不大。真正值得研究的是，它到底能不能解决测试工程中的实际问题。

所以接下来这个系列会从零开始，一步一步实测：先安装、远程控制与 UI 自动化，再进入 Selector、OCR、Watcher、MITM、Frida；随后研究 MCP、大模型、自然语言操作与稳定性；最后进入多设备和综合工程化。

图 G｜FIRERPA 14 篇系列路线：传统自动化、MCP、大模型与 Device Farm

不会只讲“这个 API 怎么调用”。每一步都会放进具体测试场景里：为什么需要它？解决什么问题？实际怎么做？哪里容易失败？Root 和非 Root 有什么区别？什么时候值得用？什么时候没必要用？

第一次看 FIRERPA，很容易被功能数量吸引：远程桌面、UI 自动化、OCR、图像识别、MITM、Frida、160+ API、MCP、AI Agent……

但研究下来，我认为它真正值得测试工程师关注的地方，不是“功能特别多”，而是它试图把原本散落在 Android 测试链路里的能力，重新整合到一个设备控制平台里。

以前我们可能是 Appium + ADB + mitmproxy + Frida + 各种自研脚本；现在 FIRERPA 尝试把 Automation、Network、Device、Frida、API 与 MCP 放进同一个 Android 能力入口。

它最终能不能成为成熟测试体系的一部分，现在还不能仅凭功能列表下结论。所以这个系列不准备吹它。我们直接装、直接用、直接写自动化、直接抓包、直接接 Frida，最后再把 MCP 和大模型接进来。好不好用，让实际结果说话。

如果你也在做 Android 自动化、移动端测试或测试工具建设，欢迎持续关注 AI Test 测试进化论。