jadx: what a failed decompilation means for your analysis

The README opens with a warning that errors are the normal case

Before any feature list, jadx tells you that in most cases it cannot decompile all 100% of the code, so errors will occur, and points at a Troubleshooting Q&A wiki page for workarounds. That sentence should shape your expectations. A file that throws during decompilation is not a broken tool, it is the documented behaviour, and the difference between a wrong conclusion and a useful one is whether you treat the output as a draft. The input list is broad, which is the other half of the scope: `.apk`, `.dex`, `.jar`, `.class`, `.smali`, `.zip`, `.aar`, `.arsc`, `.aab`, `.xapk`, `.apkm` and `.jadx.kts`, and `.smali` being an accepted input is what makes the smali debugger in the GUI coherent. Alongside the Java output, jadx decodes `AndroidManifest.xml` and the other resources held in `resources.arsc`, and a deobfuscator is included.

One binary is both the CLI and the GUI, and the command line wins

`jadx[-gui]` is the whole invocation, and the option list is short enough to read in one screen:

jadx[-gui] [command] [options] <input files> (.apk, .dex, .jar, .class, .smali, .zip, .aar, .arsc, .aab, .xapk, .apkm, .jadx.kts)
commands (use '<command> --help' for command options):
  plugins	  - manage jadx plugins

options:
  -d, --output-dir                              - output directory
  -ds, --output-dir-src                         - output directory for sources
  -dr, --output-dir-res                         - output directory for resources
  -r, --no-res                                  - do not decode resources
  -s, --no-src                                  - do not decompile

Those options also work in `jadx-gui` when it is started from a command line, and the README states they override options set in the preferences dialog. Two consequences for scripts. A flag that looks harmless in a shell is a preference override in the GUI, so a saved session and a scripted run can quietly disagree. And `-s` with `--no-src` produces a resource decode with no Java at all, which is easy to mistake for a decompilation that found nothing.

plugins installs code from a remote list into the same JVM

There is one subcommand, `plugins`, and its options deserve a careful read before you run any of them.

usage: plugins [options]
options:
  -i, --install <locationId>      - install plugin with locationId
  -j, --install-jar <path-to.jar> - install plugin from jar file
  -l, --list                      - list installed plugins
  -a, --available                 - list available plugins from jadx-plugins-list (aka marketplace)
  -u, --update                    - update installed plugins

`-a` reads a remote index called jadx-plugins-list, `-i` installs by location id from it, and `-j` installs a jar from any path on disk. A plugin is code loaded into the same process that is parsing the sample, so a decompilation workstation with a browser session or credentials on it is the wrong place to experiment. That is not an argument against plugins, several of them are the reason people use jadx at all, it is an argument for installing them deliberately on a separate machine and recording which ones are present in a sample you intend to publish. `--disable` and `--uninstall` exist for taking one back out.

Running needs Java 11, building needs JDK 17, and the gap bites in CI

Two different JDK requirements sit in this project, and they are not interchangeable. To run the downloaded distribution you need Java 11 or later in a 64-bit version, which is what the note under Download asks for, and on Windows the README points at the Oracle JDK download page with the x64 installer. To build from source, JDK 17 or higher must be installed, and the sequence is three commands:

git clone https://github.com/skylot/jadx.git
cd jadx
./gradlew dist

On Windows you run `gradlew.bat` instead of `./gradlew`. The result lands in `build/jadx/bin` as the run scripts and is also packed to `build/jadx-<version>.zip`, which is the same shape as a release download. So a runtime image pinned to Java 11 can execute jadx but cannot rebuild it, and a CI job that clones and runs `./gradlew dist` needs 17 on the runner. Sorting that out before the pipeline fails is cheaper than after.

Three package managers, so three different versions of the same tool

The install section offers Arch, macOS and Flathub, and each one resolves to whatever that channel last packaged:

brew install jadx

sudo pacman -S jadx

flatpak install flathub com.github.skylot.jadx

Alongside those there are two direct paths: the release linked from the GitHub releases page, and a latest unstable build produced by the `master` branch workflow and linked through nightly.link. Five sources in total, and they do not move together. A Homebrew or Flathub install can be several releases behind the GitHub tag, and the nightly build is not a release at all, so it is the one to avoid when your output has to be reproducible or defensible. If a finding matters, record which of these five you ran and the version string it printed, because the word jadx on its own identifies nothing.

jadx-core is the library, and jadx-gui-api is a separate artifact

The build is split into modules whose names tell you how to embed it: `jadx-core`, `jadx-cli`, `jadx-commons`, `jadx-gui`, `jadx-gui-api`, `jadx-plugins` and `jadx-plugins-tools`, described in the tree alongside `build.gradle.kts`, `settings.gradle.kts`, `buildSrc/` and `config/`. The README points to a wiki page for using jadx as a library in Java projects, and the coordinates are published to Maven Central under the group `io.github.skylot`. The separation is the useful part: automation should depend on `jadx-core`, and a tool that wants jadx's own UI primitives depends on `jadx-gui-api` rather than dragging in the application. Artifacts also ship through JitPack, since the repository carries a `.jitpack.yml`. If you are building a pipeline around decompilation, the module boundary is what keeps your integration from having to launch a process.

v1.5.6 shipped in July, and the branch has moved since

Release cadence here is uneven, and that is worth planning around rather than assuming. v1.5.4 was published on 2026-02-13, v1.5.5 on 2026-02-25, and v1.5.6 on 2026-07-10, so two of the three recent releases landed inside twelve days while the third took five months. The last push to the default branch `master` was on 2026-09-25, more than two months after the newest tag, so anything built from the branch is ahead of what a package manager will hand you. The repository is not archived and carries a `SECURITY.md`, a `CODE_OF_CONDUCT.md` and a `.gitlab-ci.yml` alongside the GitHub workflows. For an analyst the practical rule is simple: work from a tagged release when a result matters, expect to wait rather than poll for the next patch, and keep the version in your notes.

Editorial conclusion

Use jadx when you need readable Java from an APK for authorised review, and you accept a result you have to check, because the project itself says most files will not decompile cleanly. Do not treat its output as ground truth, and do not install marketplace plugins on a machine that holds samples or credentials you care about, since `plugins --install` fetches and runs third-party code. Before you start, check three things: which build you have, because `brew`, `pacman` and Flathub all lag the GitHub release and the nightly build tracks `master`; that the classpath JVM is Java 11 or newer 64-bit, while building needs JDK 17; and that a deobfuscated, partially decompiled file still needs a smali view before you conclude a method is missing.

Frequently asked questions

Official sources

1. Official README
2. Project repository
3. Release notes