REA Android 分析：这个 APK 把请求发到了哪里？

01. 选择一个界面或操作

“列出所有 API”通常范围过大。先从可见操作开始，例如加载公开目录。记录 APK 版本和界面名称。目标是构建该请求的代码，而不是软件包中所有看起来像 URL 的字符串。

这是静态分析，不会启动 APK。内嵌字符串可能包含废弃主机、测试环境，或需要与运行时配置拼接的路径。

使用 REA 分析 /absolute/path/app.apk。定位加载公开目录的代码。从可能的界面类或 Repository 类追踪到网络方法。报告候选主机、路径、HTTP 方法和参数，并提供类与方法证据。区分静态声明和已确认的运行时流量。

02. 连接 Android 分析后端

使用包含编译器模块的完整 JDK。将 REA 指向已经安装的分析后端 JAR。如果 REA 通过智能体运行，为该服务器配置相同环境并重启；在另一个终端设置变量，不会更新现有进程。

export REA_JADX_MCP_JAR="/absolute/path/jadx-headless-mcp-0.7.1-all.jar"
npx -y rea-agents@6.4.0 inspect-android-package "/absolute/path/app.apk" --json
npx -y rea-agents@6.4.0 search-android-classes "/absolute/path/app.apk" Catalog --json

03. 先查看类，再选择方法

类搜索匹配类名，并不搜索方法体内的任意字符串。试试功能名和常见网络名称，例如 Api、Service 或 Repository。混淆后的软件包可能需要其他入口，例如从 manifest 中的 activity 追踪依赖。

将下方类名替换成搜索返回的完整名称。选择方法前先查看成员。同名方法存在重载时，使用类成员清单返回的重载索引。

npx -y rea-agents@6.4.0 inspect-android-class "/absolute/path/app.apk" com.example.CatalogRepository --json
npx -y rea-agents@6.4.0 inspect-android-method "/absolute/path/app.apk" com.example.CatalogRepository loadCatalog --json

04. 分别追踪请求构造和调用方

分别阅读请求的构建位置和方法调用位置。固定的基础 URL 只是其中一环：构建器可能替换它，拦截器可能添加参数，原生库也可能隐藏部分流程。记录每个边界。

入向引用显示分析引擎已知的静态关系。反射和动态加载代码可能不在其中。如果结果返回 smali 而非 Java，应把它视为同一方法的另一种表示，并明确分析它。

npx -y rea-agents@6.4.0 trace-android-references "/absolute/path/app.apk" com.example.CatalogRepository --method-name loadCatalog --json

• 哪个调用方将这个方法与选定功能关联？
• 基础 URL 是字面量、资源、配置值，还是运行时结果？
• 哪些字段确实加入了请求？
• 静态追踪在哪里停止？

05. 把发现写成小型规格说明

编写表格，包含候选方法、URL 构造、参数名和支持结论的方法引用。只能在运行时确定的值保留为未知。用本地模拟服务器，按这份规格制作你自己的客户端原型。

静态端点列表不等于成功捕获请求。要得出这样的结论，需要在合适的测试环境中，对匹配版本的应用另行运行并记录。本教程提供分析流程，不声称已测试某个 APK 或捕获 API 响应。