jadx-gui-ai: AI-assisted APK analysis built into the jadx desktop GUI

This is a jadx fork, not a plugin bolted onto stock jadx

The repository layout settles the architecture question immediately. The top level contains jadx-cli, jadx-commons, jadx-core, jadx-gui, jadx-plugins and jadx-plugins-tools, alongside a Gradle multi-module build with build.gradle.kts, settings.gradle.kts, gradle.properties, a gradle wrapper and a buildSrc directory. Those are the module names of the jadx decompiler itself, so this project is a maintained fork of the whole tool rather than an add-on. That has consequences for how you evaluate it. You are not choosing between your decompiler and a separate AI utility; you are choosing a modified decompiler whose GUI, plugins and core are one tree, built with .jitpack.yml and .gitlab-ci.yml also present. The project describes itself as a secondary development of the jadx-gui decompiler with AI added, and the README presents the goal in plain terms: open the app, tell the AI what you want to understand, and have every conclusion traceable. The licence is Apache-2.0, with LICENSE and NOTICE files in the tree, so you can use it commercially and in modified form provided you carry the licence and notice obligations. The last push was on 2026-10-13, and that same day carried both v2.0.0 and the v2.1.0 release, which is a release-heavy period rather than a settled cadence.

Three panes replace the single decompiler view: overview, interfaces, key code

The main entry point of v2.1.0 is organised as three workbench pages rather than one free-form assistant panel. An app overview identifies protection characteristics and the technology stack, then a communication page strings together call sites, parameters, encryption hints, network egress and observed traffic, and a key code page lets you follow the source by route. The README is explicit that the technology routes coexist rather than replace each other: uni-app, React Native, Cordova and WebView, Flutter, Android and Unity artifacts each get their own route, and each route states what has been read and what coverage gaps remain. That last part is the design detail worth noticing. A coverage gap indicator tells you the analysis did not read everything, which is the difference between a tool that reports findings and one that reports its own blind spots. The README also states that the interface page pulls in uni.request, fetch and axios call sites, inventories ELF binaries, and can call the MCP tool get_apk_profile. Local discovery, the API inventory and the route guide all work with no model connected. Only when you choose an investigation target does the tool request AI analysis, and a local report is generated automatically on load.

Download a bundled package and you do not install Java

Installation is a download rather than a build. The README points to the GitHub Latest Release page for the platform package matching v2.1.0, and states that the first five packages bundle Eclipse Temurin 21 so no separate Java installation is required, with the AI model connection left to the user. On Windows the package is a zip you extract and start from the executable inside it:

jadx-gui-ai-2.1.0-windows-x64.zip
jadx-gui-ai.exe

The v2.1.0 Windows build also fixed a real-world failure: a Chinese-named install directory on an English system region used to prevent startup. The new launcher targets Windows 10 1903 and later and Windows 11, and the README says you can open the EXE directly without changing the system region or editing the Java configuration. macOS and Linux packages exist as well, with the release page listing a macOS Apple Silicon build among them. The documentation also says the base features need no Python, Node, Frida or Ghidra installed. If you would rather build from source, the repository carries the full Gradle project, but the README documents the download route rather than a build procedure, so expect to read the Gradle files yourself before expecting a one-command build.

The API inventory separates declarations, address hints and request builders

The API inventory is the part of the tool with the most concrete engineering behind it, and its structure is deliberate. Rather than dumping every string that looks like a URL into one list, it keeps three categories apart: interface declarations, address hints, and request construction entry points. You can search by domain, path, HTTP method, parameter or source location, and each entry keeps a jump target into the source. Retrofit declarations are parsed for Path, Query, Header and Body annotations along with form and upload fields, and OkHttp and HttpURLConnection are handled as request builders to be traced rather than as finished endpoints. Two deliberate refusals are documented. A relative path that has not been linked to a base address is flagged as such instead of being presented as a resolved endpoint, and the absence of an authentication header is never read as proof that an endpoint is anonymous. That restraint is the interesting part, because the usual failure mode of this class of tool is presenting guesses as findings. Exports to JSON and Markdown keep the original values without redaction, and entries can be saved with the project or handed to the AI for continued tracing.

Every model answer is filed as observation, hypothesis or open question

The workflow design centres on not letting a model answer become an unexamined conclusion. The investigation desk splits what the model produced into three categories: source observations, hypotheses still to be proven, and open questions. Each item carries the basis for the analysis, the missing conditions, possible counter-evidence, and suggested verification steps, and your own review status and notes are stored separately from the model's output. Source citations are checked against the snapshot taken during the analysis and the exact matching location is highlighted, and when a citation number does not exist or the fragment does not match, the tool says so rather than showing a confident-looking link. The README states the limit in one line: text matching only proves the citation exists, whether the conclusion holds still needs human judgement. There is also a context window that shows the source snapshot, related callers, truncation markers and recent conversation before anything is sent, and the send action uses that same previewed message. When a request fails, the error is displayed and the code is not forwarded to another service automatically, which is a meaningful boundary for a tool that handles proprietary binaries.

MCP works in both directions, and the Burp panel is still a protocol sample

The MCP story is the least conventional part of the design. The README describes bidirectional MCP: external AI tools can query the classes, source and references of the current jadx project, and the built-in AI can connect to stdio or HTTP MCP tools with per-call confirmation, entered from the MCP connection centre under the tools menu. That means the tool can act as a server for your own agent tooling and as a client for tools you trust, which is how the APK workbench reaches `get_apk_profile`. The Burp integration is the case to be careful with. The communication page offers actual traffic through the official Burp MCP Server: you install and enable it in Burp, click the connect action, and the default local address is used with the configuration remembered once connected, so there is no proxy JAR to export and no Java selection or startup arguments to fill in. It also supports reading history by host, linking source candidates, saving evidence summaries and handing traffic to Repeater. But the README states that this was verified through protocol samples and Windows interface regression, and that complete live Burp integration is still pending. Treat that panel as unproven until you run it yourself against a live proxy.

Automatic unpacking and native decompilation are not implemented

The project is honest about its gaps, and the gap list matters more than the feature list. Automatic unpacking is not wired in, and neither is decoding for Hermes, Dart AOT or IL2CPP, nor native decompilation. Those three cover the exact application families where a static decompiler most often fails, so an APK built with Flutter or Unity may look thin in the workbench even though the tool is working exactly as documented. The second limitation is on the AI side. The README states that analysis is based on limited static evidence and does not represent confirmed vulnerabilities or attack success rates, and it repeats that a static relationship does not equal something already executed or exploitable. The screenshots are described as rendered from real Swing components using locally synthesised samples and a simulated local model connection, which is an honest way to present the interface while making clear the screenshots do not demonstrate real model accuracy. Practically, this tool accelerates triage and orientation. It does not replace reading the decompiled source, and it will not tell you that an endpoint is vulnerable.

Editorial conclusion

Adopt jadx-gui-ai if you already use jadx for static APK analysis and want the evidence, the plan and the model conversation in one window, or if you need an AI-assisted triage pass before you read code by hand. Do not adopt it if your task needs automatic unpacking, Hermes, Dart AOT or IL2CPP decoding, or native decompilation, because the project states those are not wired up yet, and treat the Burp traffic panel as unproven because full live integration is still pending. Before committing to a workflow, read docs/APK_WORKBENCH.md for the supported scope, confirm the model connection you plan to use, and verify a returned source reference against the code yourself before acting on it.

Frequently asked questions

Official sources

1. cncsnet1/jadx-gui-ai on GitHub
2. Issues
3. License: Apache-2.0
4. README
5. Releases