skylot/jadx

The problem

You have an APK, an AAB, or a pile of .dex files, and what you need is Java you can actually read. Getting there means unpacking the archive, decoding the binary manifest, translating Dalvik bytecode, and dealing with resource tables and obfuscated names — each step a separate tool with its own quirks. jadx bundles the whole chain into one command or window: decompile, decode resources, and produce something close to recoverable source in a single pass.

What's different

Classic Android reverse engineering is a pipeline: apktool for unpacking and resources, dex2jar to convert bytecode to a JAR, then a Java decompiler such as CFR or Procyon for source. jadx skips the intermediate JAR and decompiles Dalvik directly, which means it can keep more context intact — resource decoding, resource-name resolution, and built-in deobfuscation land in the same output instead of being stitched together by hand. The GUI's jump-to-declaration, find-usage and full-text search make it a browsing environment rather than a one-shot converter, and a smali debugger goes beyond what a plain decompiler offers. The trade-off is the same one every decompiler faces: the README warns plainly that 100% decompilation is not achievable, so expect broken or fallback output on unusual bytecode.

Who it's for

Security researchers, malware analysts, and Android developers auditing third-party SDKs or recovering logic from an app they no longer have source for. Anyone doing bulk or scripted analysis will get more out of the CLI, which exposes output directories, thread counts and decompilation modes; interactive exploration is better served by jadx-gui, which is also easier to hand to a colleague. It is not a tool for rebuilding a fully compilable Android project — for that, Gradle export exists but is a starting point, not a guarantee, and apktool-based workflows still fit better when you mainly need resource patching and repackaging.

Cost of adoption

Requires a 64-bit Java 11+ runtime, or the bundled with-jre release; packages exist for Arch, Homebrew and Flathub, and a Maven Central artifact lets you embed the decompiler. The README is unusually complete for a project this old — options, install paths and troubleshooting wiki are all documented. Apache-2.0 licensing keeps commercial and internal use unproblematic. The main cost is expectation management: obfuscated code will be partial, and the tool's own README says so.

Verdict

This is about as established as Android tooling gets: created in 2013, still shipping releases, and gaining 720 stars in a month on the Java board at #15. The project's age shows in its option surface and wiki rather than in staleness; jadx is the default name people reach for when they say "decompile this APK". If you do Android reverse engineering at all, the question is not whether to adopt it but which mode and flags your target needs. Treat the aging GUI as functional rather than polished, and lean on the CLI for anything repeatable.