How to install Androguard 5 and analyze an APK from Python

A bare pip install pulls the wrong Androguard

Androguard 5 lives in the repository, not on PyPI. The package published as androguard is 4.1.4, and the README warns that a plain pip install androguard or pip install 'androguard[full]' downloads 4.1.4 and uninstalls 5.0.0 when both are present. Until 5.0.0 is published, you install from a checkout:

# from this repo (Rust toolchain required for the optional extras)
# Python 3.14+ needs the PyO3 forward-compat flag (bindings use PyO3 0.23, max 3.13)
export PYO3_USE_ABI3_FORWARD_COMPATIBILITY=1
pip install -e .
pip install -e '.[full]'

The editable install matters here, because two core dependencies are pinned to git URLs rather than PyPI releases, and a checkout is the only place those pins resolve cleanly. A Rust toolchain is required for the optional extras. Supported Python versions run from 3.10 to 3.13 according to the classifiers in pyproject.toml; on 3.14 you must export PYO3_USE_ABI3_FORWARD_COMPATIBILITY=1 first, because the bindings use PyO3 0.23, which stops at 3.13.

androguard -i: the one command that summarizes an APK

Running androguard -i my.apk prints a summary of the package name, the main activity, the dex count, the class count and the method count. From there the CLI fans out into listing and disassembly:

androguard -i my.apk --list-classes
androguard -i my.apk --list-methods
androguard -i my.apk --disasm --class 'TestActivity' --method 'onCreate'
androguard -i my.apk --disasm --class 'Ltests/androguard/.*' --method '<init>'
androguard -i my.apk --disasm --method 'onCreate' --limit 10
androguard -i my.apk --disasm --class TestActivity --method onCreate --cfg

Both --class and --method accept regular expressions, so 'Ltests/androguard/.*' matches every class under that package prefix and '<init>' narrows a scan to constructors. Use --limit 10 when a pattern such as 'onCreate' would otherwise match every class in the app. Adding --cfg renders a control-flow graph of each match. One constraint to remember: every --disasm invocation requires the disasm extra, because disassembly lives in a separate library rather than the base install.

Application is the API most scripts should start from

Under the CLI sits a high-level Python entry point. Construct it with a path and call summary(), and it returns the same facts as the command line banner plus a few the banner leaves out:

from androguard import Application

app = Application("my.apk")

print(app.summary())

The dictionary holds app_name, main_activity, package, dex_files, a classes count, a strings count, a methods count and a signed flag, so a script can check whether an APK carries a signature before any deeper work. Class names arrive as a list you can slice, and the README example walks the first ten with app.class_names[:10]. Every method object exposes get_code(), which makes it cheap to filter down to methods that actually have bytecode:

for method in app.methods:
    if method.get_code():
        print(method.class_name, method.name, method.get_code().insns_size)

insns_size is the instruction count of a method, a useful size signal when you are deciding which classes deserve decompilation first.

Why pyproject.toml pins two libraries to git

Version 5 is split across dedicated libraries instead of one package. apkparser-ag, the apk-parser repository, handles the ZIP structure, signatures and manifest hooks. dexparser-ag is a Rust core with Python bindings for classes, methods, fields and bytecode. axml together with a Rust axml-parser decodes AndroidManifest.xml and resources.arsc. Four more layers are optional: dex-bytecode for Dalvik disassembly and CFG work, dex-decompiler for DEX to Java plus getclass, findrefs and the vulnerability scanners, arm_disassembler and arm_decompiler for native .so code, and apk-patch for decoding and rebuilding APK project trees in memory.

That split explains the install friction. pyproject.toml pulls apkparser-ag and dexparser-ag from git URLs on purpose: the PyPI apkparser-ag 0.0.2 depends on a package name, dex-parser, that was never published, and the PyPI dexparser-ag 0.0.1 is the old hachoir parser without DEX_from_source. Until apkparser-ag reaches 0.0.3 with the corrected name and a wheel of the Rust bindings ships, a checkout install also reaches GitHub for those two dependencies.

An MCP server puts APK analysis inside the LLM host

Androguard ships support for agent-driven analysis. A .claude/skills directory defines four commands, /analyze-apk, /decompile-apk, /find-refs and /scan-vulns, and .claude/agents/androguard-analyst.md defines an analyst agent for the Claude Code integration:

claude /agent androguard-analyst
claude /analyze-apk path/to/app.apk
claude /decompile-apk path/to/app.apk com.example.app

The same capability is exposed over MCP for any client that speaks the protocol, Claude Code and Cursor among them:

pip install -e '.[mcp,decompile]'   # add [disasm] for disassembly tools
androguard-mcp                     # or: python -m androguard.mcp

A client config points at the command and sets ANDROGUARD_MCP_ROOTS to constrain where APKs are read from:

{
  "mcpServers": {
    "androguard": {
      "command": "androguard-mcp",
      "env": {
        "ANDROGUARD_MCP_ROOTS": "/path/to/androguard"
      }
    }
  }
}

The intended flow is open_apk to obtain a session_id, then list_classes, find_refs, decompile_method and scan_vulns against that session. On launch the server prints a banner to stderr with versions, tools, path roots and extras; --log-tools logs every tool call and --log-level DEBUG widens the output. The full tool list, environment variables and security notes sit in docs/mcp-server.md.

Where jadx opens a GUI, Androguard opens an import

For reading one unfamiliar app by hand, jadx is the familiar answer: a Java-based decompiler built around a desktop interface for browsing the sources of a single APK. Androguard takes the other route. Its analysis surface is a Python module, so the questions you ask of an app become loops, filters and regular expressions that live next to the rest of a test suite, and the MCP front end packages those same steps for an agent to call. Browsing is where the scripted route costs you: clicking through a tree of decompiled classes is faster than printing class lists and re-running patterns, and Java decompilation here is an optional extra layered over a separate decompiler library rather than the center of the project. If the work is one app read once, jadx's shape fits. If it is a queue of APKs, or a question you will re-ask on every build, the import statement is the point.

Scripts written for 3.3.5 will not survive 4.0.0 unchanged

Versions 4.0.0 and later are, in the README's words, new releases after a long time, with substantial differences from 3.3.5, the previous stable version, from 2019, and certain functionalities were removed. Code written against the 3.x API needs rework, and where something you depend on is gone the project asks for an issue on GitHub. Development is current: the last push was on 2026-09-22, and the tagged releases are v4.1.4 on 2026-06-05, v4.1.3 on 2025-02-24 and v4.1.2 on 2024-05-31. Upgrading also has a licence angle, a mild one: the project is Apache-2.0, and the LICENCE file in the repository is the text to check before shipping Androguard inside a commercial tool. Runnable demos live under examples/ and the test suite executes them through tests/test_examples.py:

python -m examples.application_summary
python -m examples.disassemble      # androguard[disasm]
python -m examples.decompile       # androguard[decompile]

Each demo maps to one layer of the toolkit, summary, disassembly or decompilation, which makes them the shortest way to see how each layer is invoked after a fresh checkout.

Editorial conclusion

Adopt Androguard 5 if you analyze Android apps from Python, or if you want typed APK analysis tools callable inside an MCP host such as Claude Code or Cursor. Skip it when the job is one APK read once by hand and no scripting is involved; a GUI decompiler serves that with less setup. Verify first what pip would hand you on your machine, because PyPI still serves 4.1.4 and version 5 only installs from a checkout, and check your Python version against the supported 3.10 to 3.13 range before adding the optional extras.

Frequently asked questions

Official sources

1. androguard/androguard on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases