APK Reverse Engineering with REA

An APK is three different questions, and REA does not answer them with one tool. Java and Kotlin source go through JADX. Engine-level decompilation goes through JEB, which REA does not bundle. Resources go through Apktool, which you supply. This page is those three tiers, the clocks and byte budgets around them, and the claims the Evidence will not make.

The same "read the file, do not run it" idea for a managed assembly is reverse engineer a .NET assembly.

The three-tier static division

The official resource guide opens with the split. Per docs/apktool-resource-analysis.md:

This completes the static triad for Android targets: Java/Kotlin sources through the JADX family, engine-grade decompilation through JEB, and resources through this family. REA never installs Apktool or a Java runtime.

JEB stays a separate target: a caller-started client selected with REA_JEB_MCP_URL. This page does not turn it into a JADX feature.

Prerequisites

The version people misread is the JDK, not JADX. JADX here is jadx-headless-mcp 0.7.1. The 17+ requirement is the JDK that runs it, and that JDK has to include the jdk.compiler module. A runnable JRE cannot compile the bridge. Confirm with java --list-modules. Per docs/android-analysis.md:

Use a full JDK 17 or newer (including its compiler module) and jadx-headless-mcp 0.7.1.

A runnable JRE alone cannot compile the bridge.

JAVA_HOME must point at that JDK when you do not want java from PATH. Set REA_JADX_MCP_JAR to the JAR after you check its SHA-256 against REA's pinned release metadata in src/android/JadxRelease.ts. The digest published in the guide is 6e5eacf500b64292bfb73c49797c1958f6ee44646e43e868039ae7feb573ff75. Per the official docs.

On Linux, JADX launches an REA-owned process and needs a procps-compatible ps on PATH. Windows x64 needs a REA package whose bundled native controls include owned protocol stdin. Windows arm64 is outside this provider's boundary. Readiness limits each ZIP metadata read of the JAR to 8 MiB. It does not load an APK. Per the official docs.

Five query paths

CLI and MCP are the same five operations. Every request includes path. Per the official docs:

rea inspect-android-package /path/Example.apk
rea search-android-classes /path/Example.apk MainActivity
rea inspect-android-class /path/Example.apk example.MainActivity
rea inspect-android-method /path/Example.apk example.MainActivity onCreate
rea inspect-android-method /path/Example.apk example.MainActivity select --overload-index 1
rea trace-android-references /path/Example.apk example.MainActivity

(The commands above are per the official docs/android-analysis.md. This site has not run them.)

The MCP names are inspect_android_package, search_android_classes, inspect_android_class, inspect_android_method, and trace_android_references.

Overloads use overload_index. REA rejects an ambiguous method instead of picking the first match. Those indices belong to the current artifact and the current engine. They are not stable across builds. Per the official docs.

detail: "summary" is a delivery switch, not a lighter analysis. A retaining session keeps the complete Evidence and returns a linked inspect_analysis_view summary. Servers that do not support retention reject summary before JADX starts. Per the official docs.

Resource decoding (Apktool tier)

Apktool is the resource tier only. Smali is skipped on purpose (apktool d --no-src); Java source stays with JADX. Per the official docs.

REA_APKTOOL_COMMAND is optional. Set it to an absolute path of the launcher, upstream wrapper, or a java -jar script. Without it, apktool resolves from PATH. Readiness is rea inspect-apktool-client, which runs apktool --version and reports the launcher, the selection source, and the version. A missing launcher is capability_unavailable. REA does not try to install it. Per the official docs.

Decode flags in the guide: --locale for the primary table, repeatable --locales to project more tables from one pass, and --no-strings. The default table is bounded to 2,000 entries. When several tables are requested, the aggregate budget is 10,000 strings and 32 MiB of XML. A locale suffix allows up to 23 ASCII characters. pt-BR selects values-pt-rBR. Combined qualifier directories such as values-en-rUS-v21 are named in limitations. They are not selectable locales. Per the official docs.

Three advisories are disclosed from the reported launcher version. They do not refuse an otherwise compatible launcher. Per the official docs:

Official instruction, verbatim:

Verify the selected decoder's patches before decoding untrusted APKs; the compatibility floor above is not a security recommendation.

On Windows, a .bat or .cmd launcher goes through cmd.exe /d /s /c. A launcher path that contains a quote, percent, caret, exclamation mark, ampersand, pipe, or angle bracket is reported as not_configured instead of being passed to cmd.exe. Per the official docs.

Timeout and memory

The default operation deadline is 120 seconds, and it starts when the operation reaches the front of the queue. REA_JADX_OPERATION_TIMEOUT_MS accepts a decimal millisecond count from 1 to 2147483647. Anything else is refused before Java starts. Per the official docs.

Raising that deadline does not extend:

• the bridge's 30-second startup handshake
• the upstream 90-second decompilation limit
• the MCP client's own tool-call timeout, which you raise separately

Optional JVM settings, with no default heap from REA: REA_JADX_HEAP_MIB (the guide's example is 8192) and REA_JADX_ACTIVE_PROCESSOR_COUNT (the guide's example is 4). The provider still uses one JADX worker. Per the official docs.

Sessions are cleaned after 60 seconds of inactivity. If process cleanup cannot be confirmed, REA retains the workspace and that provider instance blocks later engine launches until you deal with the reported resources. Per the official docs.

Decoded manifest and method text have a 1 MiB upstream byte budget and report truncation. A protocol frame above 8 MiB, or combined stdout and stderr above 32 MiB per operation, fails with a diagnostic. Those three numbers are independent. Per the official docs:

These are memory-safety boundaries, not undocumented result caps.

Where the evidence stops

Signature verification is explicitly not_performed. Decompiled source is a derived representation: a complete text result does not establish complete semantics, or a byte-identical reconstruction. Reference results are static relationships between provider nodes. They are not observed runtime calls. Per the official docs.

The same section draws the rest of the line:

These operations do not execute the APK or provide split APK/AAB handling, signature validation, full resource-table semantics, native-library analysis or Android runtime capture. An .aab suffix is a ZIP archive, not an APK.

Native and abstract methods report body_status: "not_available", an empty source, and the native_method or abstract_method marker. Static initializers (<clinit>) return smali with the static_initializer_disassembly marker, because Java decompilation can move those instructions into field declarations. Per the official docs.

Verification scope

Per docs/android-analysis.md, the filtered class-page bridge is verified on Linux x86-64 with Temurin 21, public Appium ApiDemos 6.0.18, and NewPipe 0.29.1. Earlier metadata-bridge records covered macOS arm64 with OpenJDK 21 and Windows x64 with JDK 21. That protocol revision has not been rerun on those hosts.

Per docs/apktool-resource-analysis.md, use Apktool 2.7.0 or newer (verified with 2.7.0). The recorded real-verification lane is apktool 2.7.0-dirty (Debian packaging) on Linux with OpenJDK 25.

The Windows lane checks forced termination and a two-owner cleanup case. It does not claim power-loss recovery. Per the official docs. This site has not run these verifiers.

Related

The other static, no-engine read of a managed file is reverse engineer a .NET assembly.

Last verified: 2026-10-18 · REA 6.6.0 (tag rea-agents-6.6.0) · docs unchanged at 6.7.0 (tag rea-agents-6.7.0) · fields quoted per the official docs/android-analysis.md.