Android REA
<div align="center">
# Android REA
### Android reverse engineering for AI agents.
Inspect APKs, trace runtime behavior, and connect screen actions to code through one MCP server.
[Quick start](#quick-start) · [Documentation](#documentation) · [Skill](skills/android-rea/SKILL.md)
</div>
Android REA combines static analysis, Frida instrumentation, and ADB in a standalone **Skill + MCP** toolkit. The Skill guides your agent; the MCP server runs the tools. Static providers are derived from [REA](https://github.com/morluto/rea).
## What you can analyze
| Target | Tools and results |
| --- | --- |
| APKs and resources | JADX and Apktool: classes, methods, references, manifests, and strings |
| Native libraries | Ghidra: ELF/SO disassembly, decompilation, and cross-references |
| Runtime behavior | Frida: selected Java, JNI, and native calls, arguments, and return values |
| App screens | ADB: screenshots, UI inspection, taps, and evidence linked to runtime events |
## Quick start
Requires Python 3.11+, Node.js 22.19+ with npm, JDK 21+ with `JAVA_HOME` set, and ADB on PATH. For native static analysis, install Ghidra and set `GHIDRA_HOME`.
From the repository checkout:
```sh
node bin/android-rea.mjs setup
```
Choose Codex, Claude Code, Cursor or Gemini CLI, review the plan and confirm. Setup installs dependencies, checks the host, backs up and updates the selected agents' MCP settings and Skill, then verifies a real MCP connection. Restart or reload the selected agent afterward.
For unattended setup, use `setup --agent codex --yes`; use `setup --agent codex --dry-run` to preview without changes. See [agent setup](docs/agents.md) for multiple agents, configuration paths and manual setup.
Runtime tracing needs a rooted Android device or root-capable emulator with a matching Frida server. See [device setup](docs/emulator.md).
## Ask your agent
```text
Use Android REA to analyze this APK. Find the code behind this button,
then trace its Java, JNI, and native calls on my test device.
Show the evidence and identify any gaps.
```
## Documentation
[Installation](docs/installation.md) · [Agent setup](docs/agents.md) · [Devices and emulators](docs/emulator.md) · [Workflows](docs/workflows.md) · [Tool catalog](docs/tool-catalog.json)
## License
[MIT](LICENSE). Includes code from [REA](https://github.com/morluto/rea); see [upstream attribution](licenses/REA-MIT.txt).
TDQS
Scored across 89 tools
The 89-tool surface has several overlapping clusters: ADB package inspection vs. Android package inspection vs. APK pulling, screen capture vs. UI capture, static native procedure/address tools vs. analysis tools, and trace/run/storage tools that are related but easy to confuse. Individual descriptions are detailed, but at set level an agent faces many similarly named read/inspect/list operations with subtle boundary differences.
Names mix several conventions: verb_noun (list_adb_packages, inspect_adb_device), noun_verb-like (procedure_callees, address_name), bare nouns (binary_session, xrefs), and inconsistent prefixes such as read_, inspect_, list_, get_, start_, create_, collect_, snapshot_, map_. The pattern is readable in places but not predictable across the whole set.
Eighty-nine tools is far beyond a well-scoped set for an MCP server, even for a complex Android reverse-engineering domain. Many capabilities are split into very granular operations, making discovery and selection burdensome rather than cohesive.
The surface covers an unusually complete Android RE lifecycle: projects and evidence, APK/resource inspection, ELF/native analysis, ADB device operations, Frida tracing, UI snapshots/actions, storage acquisition/diffing, and workspace export/import. Minor gaps exist around mutating settings or deleting projects, but the major workflows are covered.