JADX v1.5.6 makes Android bytecode readable and searchable
JADX v1.5.6 converts Dalvik bytecode from APK and Dex files into Java-like source, then places that output beside decoded manifests and resources. The input list also covers AAB, AAR, class, JAR, smali, XAPK, and related archive formats. This is the practical first stop when you have an Android package but lack its source project, because code and packaged resources can be explored together.
The GUI adds 4 core navigation aids named in the README: syntax highlighting, jumps to declarations, usage lookup, and full-text search. It also includes a smali debugger and graph views. The command-line tool can select one class, write Java or JSON, produce control-flow and call graphs, skip resources, or change decompilation modes. Those options make JADX useful for both interactive investigation and repeatable extraction jobs.
The README says 100% source recovery is impossible
JADX's README explicitly warns that most inputs will not decompile with 100% success. Reconstructed Java is an interpretation of compiled bytecode after names, comments, types, and higher-level structure may have been altered or removed. The restructure, simple, and fallback modes trade readability for a closer view of the underlying instructions. When a clean-looking method affects a security or compatibility decision, inspect the lower-level form too.
Issue 2949 supplies a concrete v1.5.6 failure: with the dx/d8 option enabled, JADX generated an unexpected throw in a synchronized method. Issue 2951 shows a different method ending in UnsupportedOperationException after an internal null-pointer error during code generation. Neither report makes the tool useless. Both show why decompiled output must be checked instead of compiled or quoted as if it were the author's original source.
What happened when we ran it
Our sandbox installed the project in 149 seconds and built commit bde91ff in 96 seconds. The test step then succeeded in 224 seconds. The checkout contained 2,460 files, about 189,213 lines of source, and used 10.1 MB before setup. This measurement setup used an unprivileged Java 21 container with 3 CPUs and 10 GB of RAM.
The successful 224-second test result does not include a test count, dependency count, installed size, vulnerability scan, or decompilation benchmark, so we are not filling in those blanks. It establishes that the detected install, build, and test commands all finished successfully. Our run did not assess how much of a particular APK was recovered, compare Java output with original source, open the desktop GUI, or measure processing speed on a large application.
The repository had 3 CI workflow files and no Dockerfile or tests directory in the recorded scan. A successful 224-second test command can coexist with no top-level tests directory because a multi-module Gradle project may organize checks elsewhere. The useful buyer result is the completed test step. The structural signals describe the checkout and should not be mistaken for a count of test cases or a guarantee about every supported input format.
Java 11 runs the release, while JDK 17 builds the source
Downloaded releases require a 64-bit Java 11 or newer runtime. Source builders need JDK 17 or newer and run the Gradle wrapper's dist task. The resulting scripts land under build/jadx/bin, along with a packaged distribution. Windows users can choose a GUI archive containing its own JRE, while the ordinary cross-platform archive expects Java to be installed separately. No hosted account or API key sits in the local inspection path.
Homebrew, Arch Linux, and Flathub packages offer easier installation on supported systems. The GUI is best for following references and switching between code, resources, and graphs. The CLI is better for a headless pipeline, especially with single-class output, JSON, call graphs, explicit thread limits, and separate source or resource directories. Keep extracted files and caches in a disposable workspace when the input is untrusted or simply very large.
Version 1.5.6 hardens archives but cannot make inputs harmless
Release v1.5.6 was published on July 10, 2026 with fixes for unsafe archive paths, Gradle export string handling, XML parsing, and output escaping. The CLI also exposes zip and XML security controls, including entry-count limits. Disabling those checks through the documented environment variables removes protections that exist for a reason. Analysts should open unknown APKs with ordinary user privileges and controlled output directories.
Resource use still varies with the target. The CLI defaults to 16 processing threads, and configuration variables can redirect its cache and temporary directories. Issue 2938 reports an out-of-memory failure on v1.5.6 with a maximum Java heap of 11,472 MB. One report cannot set a universal requirement. It is enough reason to cap concurrency, monitor heap use, and trial the largest APKs before making JADX part of an unattended batch.
50,398 stars come with current decompiler fixes and GUI work
GitHub showed 50,398 stars, 446 combined issues and pull requests, and a last push on September 8, 2026. Release v1.5.6 arrived 2 months earlier. Open work updated in September included application-scoped GUI plugins, a searchable strings pane, resource cleanup, class-tree filtering, and current decompilation bug reports. The last push and issue activity reinforce each other: this is a maintained project with a large queue, not an old utility surviving on downloads.
Apktool is the better companion when resources must be changed and rebuilt. MobSF wraps mobile analysis in a report-oriented service, while Ghidra is the stronger route into native libraries. JADX occupies the readable middle: open the app, trace calls, search strings, inspect resources, and export what you need. Its successful 224-second test step earns trust in the project mechanics, while its own warning should govern trust in each reconstructed method.