REA 6.4 Adds Android Inspection to AI Coding Agents

REA 6.4.0, released on October 11, gives AI coding agents more ways to inspect software, including Android devices and applications. The update expands an existing reverse-engineering toolkit with Android support and changes that help agents work through large analysis results without loading everything at once.

For developers maintaining an application whose behaviour is poorly documented, that combination is worth understanding. An agent can investigate a specific feature, retrieve the underlying evidence and help explain it. The usefulness of that explanation still depends on what the tools actually observed and how carefully the result is checked.

What changed in REA 6.4?

The 6.4.0 release notes describe Android inspection through ADB, including device information, logs, screenshots and split-APK acquisition. Apktool integration adds decoding of manifests and localised strings. The release also connects to a user-started local JEB MCP server for browsing project units and decompiling selected items.

Another useful change concerns the amount of information an investigation produces. Agents can discover retained evidence through summaries and selected views. JavaScript analysis runs in a separate process with configurable memory and time limits, retaining completed findings and explicit unknowns when resources run out.

Those details matter when a question involves a large packaged application. Asking an agent to read every result can become expensive and difficult to review. A smaller, relevant slice gives the developer a better chance of checking the explanation against the software.

How REA works with Claude Code and Codex

The REA repository describes a local CLI and MCP server that coding agents can use to inspect applications. MCP supplies the connection between the agent and the tools. REA brings the analysis workflows together; the model interprets the results and decides what to investigate next.

For native binaries, that work relies on established engines such as Ghidra, Hopper or IDA. Static JavaScript inspection can operate on supplied application files without a native decompiler. The available evidence therefore changes with the target: native code may produce assembly and pseudocode, while a JavaScript application offers modules and source locations.

Consider a developer trying to understand an export function before migrating their own app. REA's introductory Notes example follows an export button through an Electron application to the CSV writer. It then checks how the formatter handles a title containing punctuation. That is a manageable investigation because the claim can be traced to code and tested with a concrete input.

The same approach makes sense for maintenance work: choose one behaviour, ask for the supporting locations, and check an observable consequence before relying on a proposed change.

Local analysis still needs a data policy

The project FAQ makes an important distinction about privacy. REA analyses the target on your machine, but the resulting information goes to your coding agent. The model provider's data policy applies to those results.

For a company application, that can matter as much as where the executable lives. Decompiled code or runtime observations may contain material the team cannot send to an external service. Review the agent's configuration and your organisation's requirements before choosing a target.

Keep investigations within software you own or are authorised to examine. The tool's availability does not establish permission to access someone else's systems, copy protected material or bypass a licence.

What to check before adopting it

Compatibility is specific. The setup documentation describes Windows Ghidra support as experimental and read-only for supported targets. It also identifies IDA configurations that have been verified and others that remain unverified. Check the combination of host, target and analysis engine you actually need.

Start with a small, non-sensitive application and a question whose answer you already know. That gives you a way to assess the evidence returned, the time spent reviewing it and the quality of the explanation. A successful demo of one function is useful evidence for that function; a wider migration needs its own tests.

I'm Paras Madan. I work across AI engineering and distribution, helping technical products reach the developers who can use them.

For teams building tools like this, I help with technical writing and developer storytelling that explains the workflow, shows the evidence and makes the limitations easy to understand.

Book a 30-minute call