REA Android analysis: where does this APK send requests?

01. Pick a single screen or action

“List every API” is usually too broad. Start with a visible operation such as loading a public catalog. Note the APK version and the screen name. You want the code that builds that request, not every URL-shaped string in the package.

This is static inspection. The APK is not launched. Embedded strings can include abandoned hosts, test environments or paths that are combined with runtime configuration.

Inspect /absolute/path/app.apk with REA. Locate the code for loading the public catalog. Trace from a likely screen or repository class to its networking method. Report host, path, HTTP method and parameter candidates with class and method evidence. Separate static declarations from confirmed runtime traffic.

02. Connect the Android provider

Use a full JDK, including its compiler module. Point REA at the provider JAR you already installed. If REA runs through your agent, configure the same environment for that server and restart it; setting a variable in a different terminal does not update an existing process.

export REA_JADX_MCP_JAR="/absolute/path/jadx-headless-mcp-0.7.1-all.jar"
npx -y [email protected] inspect-android-package "/absolute/path/app.apk" --json
npx -y [email protected] search-android-classes "/absolute/path/app.apk" Catalog --json

03. Inspect the class, then select the method

Class search matches class names, not arbitrary strings inside method bodies. Try feature names and common networking names such as Api, Service or Repository. Obfuscated packages may need a different entry point, such as a manifest activity followed into its dependencies.

Replace the class below with an exact name returned by search. Inspect its members before choosing a method. When overloaded methods share a name, use the overload index returned by the class inventory.

npx -y [email protected] inspect-android-class "/absolute/path/app.apk" com.example.CatalogRepository --json
npx -y [email protected] inspect-android-method "/absolute/path/app.apk" com.example.CatalogRepository loadCatalog --json

04. Follow construction and callers separately

Read where the request is built and where the method is called. A constant base URL is only one piece: a builder can replace it, an interceptor can add parameters, and a native library can hide part of the process. Record each boundary.

Incoming references show static relationships known to the analysis engine. Reflection and dynamically loaded code can escape that set. If the result returns smali instead of Java, treat it as a different representation of the same method and inspect it explicitly.

npx -y [email protected] trace-android-references "/absolute/path/app.apk" com.example.CatalogRepository --method-name loadCatalog --json

• Which caller connects this method to the chosen feature?
• Is the base URL a literal, resource, configuration value or runtime result?
• Which fields are actually added to the request?
• Where does the static trace stop?

05. Turn findings into a small specification

Write a table containing the candidate method, URL construction, parameter names and supporting method references. Leave runtime-only values unknown. Use a local mock server to prototype your own client against this specification.

Do not count a static endpoint list as a successful request capture. To make that claim, you need a separately recorded run of the matching app version in an appropriate test environment. This tutorial supplies the inspection workflow; it does not claim a tested APK or a captured API response.