# TTDeDroid puts four Android decompilers behind one showjar command > TTDeDroid is an Apache-2.0 licensed Python wrapper that decompiles apk, aar, dex and jar files by driving jadx, dex2jar, enjarify, the IntelliJ fernflower decompiler or apktool, with the toolchain binaries vendored and updated in the repository. It suits analysts and reverse engineers who want one command instead of four, and it does not replace reading the output critically. **tp7309/TTDeDroid** — 一键反编译工具 One key for quickly decompile apk/aar/dex/jar, support by jadx/dex2jar/enjarify. - Repository: https://github.com/tp7309/TTDeDroid - Stars: 948 · Forks: 182 - Language: Python - License: Apache-2.0 - Published: 2026-10-20 · Updated: 2026-10-20 · Language: en - Canonical page: https://hysenlabs.com/projects/tp7309-ttdedroid ## One entry point for four decompiler engines Decompiling an Android package is a menu, not a command. Depending on the file you are holding and the question you are asking, you reach for jadx, dex2jar, enjarify, the IntelliJ fernflower decompiler or apktool. TTDeDroid is a wrapper that puts that menu behind a single script. The repository description calls it a one key tool for quickly decompiling apk, aar, dex and jar, supported by jadx, dex2jar and enjarify, and the README states that it is the tool for quickly decompile apk/aar/dex/jar, updated depending on the update of libs. The word updated is doing quiet work there. The tool bundles the decompiler binaries rather than expecting you to install a toolchain, and the refresh happens in the repository itself. The bundled versions are listed in the README under a dated update entry. As of the 2026-09-01 update the set is jadx=1.5.6, Storyyeller/enjarify built by source, dex2jar built by source, fernflower=262.9437.185 described as the IntelliJ IDEA official decompiler, and apktool=3.0.3. The build-by-source notes for enjarify and dex2jar are the interesting ones, because those two are Python tools, and building them from source is what lets the wrapper keep them current without a separate install step. The audience is anyone doing Android reverse engineering: a security analyst triaging a sample, a developer trying to understand a third party library, a researcher walking through an obfuscated application. The primary language of the project is Python, and the licence is Apache-2.0. ## The command line is small: a file, an engine and a resource flag The whole interface is one argparse script, showjar.py, and the usage text is short enough to read in full: ``` usage: showjar.py [-h] [-o [OUTPUT]] [-r [RES]] [-e [ENGINE]] file android decompile tool positional arguments: file input file path, *.apk/*.aar/*.dex/*.jar optional arguments: -h, --help show this help message and exit -o [OUTPUT], --output [OUTPUT] output directory, optional (default: None) -r [RES], --res [RES] decode resources, 0:disable, 1:enable (default: 0) -e [ENGINE], --engine [ENGINE] decompiler engine, [jadx, dex2jar, fernflower, enjarify] (default: jadx) ``` Three things stand out. The engine is chosen explicitly with -e and the default is jadx, with the accepted values listed as jadx, dex2jar, fernflower and enjarify. The resource decoding is off by default, with -r taking 0 to disable and 1 to enable, so a quick look at code does not also pay the cost of rebuilding resources. And the output directory is optional, which means the tool applies its own default layout. Note what is not in the list. apktool appears in the update entry as a bundled binary, but it is not one of the four values the -e flag accepts, so the documented way to drive apktool is not through the engine flag. The README does not explain how apktool is invoked, which is a small gap in the documentation rather than in the code. ## Installing on Windows is a PATH entry and a download The requirements section says there is no need to install a Python environment, which is the headline feature of the Windows path. The tool ships its own runtime, so a Windows user does not have to set up Python, virtualenv or a dependency graph to decompile an APK. The steps are three. Go to the releases page to download the file, or download the source code. Add the TTDedroid\bin directory to your PATH system variable, using the absolute path. Then you can run the decompile command for apk, aar, dex or jar files anywhere, and the GUI opens automatically: ```bash showjar test.apk ``` The emphasis on the absolute path in the README is a real requirement rather than caution, since the wrapper scripts resolve the bundled libraries relative to their own location. The GUI opening automatically is also part of the design: the point is to get from a file on disk to readable output with a single command, so you are not left picking through a directory tree of generated files. One wrinkle for anyone packaging this: the absolute PATH entry is per machine, so an analyst who moves between machines repeats the setup, and the Windows guidance does not mention a relative or portable arrangement. ## Mac and Linux install from a shallow clone and a PATH export The Unix path is a git clone, a chmod and a shell profile edit: ```bash git clone --depth=1 https://github.com/tp7309/TTDeDroid.git ~/Documents/TTDeDroid chmod a+x ~/Documents/TTDeDroid/bin/showjar showjardir='export PATH=$PATH:'$HOME/Documents/TTDeDroid/bin # Mac echo $showjardir >> ~/.bash_profile && source ~/.bash_profile # Linux echo $showjardir >> ~/.bashrc && source ~/.bashrc ``` The depth=1 clone is a hint about the size of the repository, which makes sense when the binaries for five tools are committed to it. The chmod makes the showjar launcher executable, since a fresh clone does not carry that bit as working on some setups. The last two lines are the interesting part: the export is written into your shell profile, once, so the command is available in every new terminal. The consequence is that your shell profile now points at a directory in your home folder. If you later move or delete the clone, the profile still references it, and you get a command not found rather than a helpful message. That is a small operational cost of the approach, and it is the price of not installing a Python environment. After the profile is sourced, the same invocation works as on Windows: ```bash showjar test.apk ``` ## The repository is a wrapper, a vendored libs folder and an updater The top level of the repository shows how much of this project is plumbing. There is showjar.py, the command line entry point, and a bin/ directory holding the launcher scripts. There is a libs/ directory, which is where the bundled jadx, dex2jar, enjarify, fernflower and apktool material lives. There is updater.py, which is the piece that keeps those libraries in step with upstream, and repack.py, which sits alongside it for working with packaged output. A test.apk sits at the root, and a tests/ directory with pytest.ini and codecov.yml and a .coveragerc indicate the behaviour is covered by tests. The dependency tooling is Pipfile rather than requirements.txt or a pyproject, and the presence of .deepsource.toml shows static analysis is configured, with a DeepSource badge in the README. There is also a Chinese language README, README_zh_CN.md, linked from the i18n line at the top, and a _config.yml, which is the file GitHub Pages uses for a project page. The most useful structural fact for a user is that the tools are vendored. That is what removes the Python requirement and the version juggling, and it is also what makes the repository large and the updates manual. When a new jadx release appears, the vendored copy in libs/ has to be replaced, and the README update entry records that happening. ## What you still have to do after the decompile Two limitations are worth stating plainly. The first is that the tool does not decide for you whether the output is correct. Decompiled code is a best effort reconstruction, and the README does not claim otherwise. A wrapper that makes decompiling a one command operation makes it easier to skip the step where you confirm the decompiler was the right one for the file you hold. If you are chasing obfuscated control flow, the choice between jadx and fernflower can matter, and the -e flag gives you the choice without giving you the answer. The second is the resource flag. Resource decoding is disabled by default and enabled with -r 1, which is the right default for speed but means that a first look at an APK will show you code and no resources, and a reviewer expecting a full decode will think the tool failed. The cost of turning it on is paid in time on every run. There is also a question the README leaves open around updates. The tool is described as updated depending on the update of libs, and the last push was on 2026-09-01 with a matching dated entry in the README listing the bundled versions. Whether that tracking stays current is a matter of the maintainer's cadence rather than a published policy, and the tagged releases are older, with v1.8.0 from 2024-06-12, v1.7.0 from 2023-09-24 and v1.6.0 from 2023-03-20. So the tags and the working tree tell different stories: the tree is the current artefact, and the tags are historical markers. ## Conclusion Adopt TTDeDroid if you reverse engineer Android packages regularly and want a single command that picks a decompiler, decodes resources when you ask for it and opens the result in a viewer, and skip it if you need reproducible builds of the toolchain, since the binaries are vendored and refreshed in the repository rather than installed by a package manager. Before you rely on it, check the engine and version list in the README against what your cases need, run it on a sample you already understand, and remember the last push was on 2026-09-01 while the tagged releases stop at v1.8.0 from 2024-06-12. ## FAQ ### What file types can TTDeDroid decompile? The positional argument is documented as an input file path for apk, aar, dex or jar files. The decompiler engines selectable with the -e flag are jadx, dex2jar, fernflower and enjarify, with jadx as the default. ### Do I need Python installed to use TTDeDroid? No. The requirements section states that no Python environment needs to be installed, and the Windows path is a download plus adding the TTDedroid\bin directory to the PATH variable. On Mac and Linux the tool is installed by cloning the repository and editing your shell profile. ### How do I decode resources when decompiling an APK with TTDeDroid? Resource decoding is off by default. Pass -r 1 to enable it, where 0 disables and 1 enables, and use -o to choose the output directory. ### Which decompiler versions does TTDeDroid ship? The README update entry dated 2026-09-01 lists jadx=1.5.6, Storyyeller/enjarify built by source, dex2jar built by source, fernflower=262.9437.185 and apktool=3.0.3. ### What licence is TTDeDroid released under? Apache-2.0, with a LICENSE file in the repository root. ## Sources - [Issues](https://github.com/tp7309/TTDeDroid/issues) - [License: Apache-2.0](https://github.com/tp7309/TTDeDroid/blob/master/LICENSE) - [README](https://github.com/tp7309/TTDeDroid/blob/master/README.md) - [Releases](https://github.com/tp7309/TTDeDroid/releases) - [tp7309/TTDeDroid on GitHub](https://github.com/tp7309/TTDeDroid) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/tp7309-ttdedroid