Apktool turns an Android app back into something you can read and change: the manifest as plain XML, the layouts and strings as resource files, and the code as smali, the assembly language of Android’s runtime. Change what you need and it packs the folder back into an APK. It has been doing that round trip since 2010, and most of the tutorials you will find for it were written for version 2. Since version 3, several of their commands no longer work.

What is Apktool?

Apktool is an open-source command-line tool for reverse engineering Android apps, written in Java and released under the Apache 2.0 licence. An APK is a zip file, but unzipping one gets you compiled code in classes.dex, a binary resources.arsc and an AndroidManifest.xml you cannot read. Apktool decodes all three into source form you can edit, then packs the edited folder back into an APK, which you sign before it will install.

Advertisement

That makes it the tool for jobs that change an app rather than just read it: making a build debuggable, adding a network security configuration for proxy testing, patching a check in smali, or translating the strings. It does not give you Java source. For reading the logic of an app, jadx is the better tool, and the two are often used side by side (more on that below).

The current release is 3.0.3, from 20 July 2026, and the project was still committing in October. One name clash to clear up: “Apktool M”, which fills Google’s suggestions for this search, is a separate Android app, not a version of this project.

How to install Apktool on Windows, Linux and macOS

Apktool is a single jar, so the only prerequisite is Java. The install guide still gives Java 8 as the minimum, but version 3 dropped 32-bit platforms, and the aapt2 program it carries inside the jar for Windows and Linux is a 64-bit x86 build (I read the binaries’ headers). Install a current 64-bit JDK and you avoid the question. The 3.0.3 jar does start on a 32-bit Java 8 – mine printed its version on one – but decoding and building are where aapt2 does its work. Everything below I ran on Temurin 21, a free 64-bit build of the JDK.

Then get the jar from the project’s GitHub release or its Bitbucket downloads page, and check it before you use it. The 3.0.3 jar is 15,478,013 bytes, and its published SHA-256 is:

In PowerShell:

Stay on 3.0.2 or later if you open APKs you did not build. Apktool has a history of path-traversal bugs, where a crafted app makes the decoder write files outside the output folder, and 3.0.2 fixed the latest one, CVE-2026-39973, by validating resource type names against Android’s own rules.

Advertisement

You can run the jar directly with java -jar apktool_3.0.3.jar, but the install guide’s wrapper scripts are worth the extra minute. On Windows, put apktool.bat and the jar in the same folder on your PATH; on Linux and macOS the shell wrapper and jar go in /usr/local/bin, made executable, and on a Mac brew install apktool does it for you. The guide says to rename the jar to apktool.jar, though the current Windows script will also find the highest-numbered apktool_X.Y.Z.jar beside it.

The guide calls the wrappers optional, a way to avoid typing java -jar. Read the Windows one and it does more than that: it starts Java with a 1 GB heap, UTF-8 file encoding and a switch that relaxes Java’s checks on zip64 fields, and run bare, the jar gets none of those. Those options come after -jar in the script, which looks like a mistake, but Java accepts them there: the script’s exact Java line printed 3.0.3 on Temurin 21. If a large app fails to decode with the bare jar, try it through the wrapper before anything else.

Windows users have one more step. Windows treats Layout.xml and layout.xml as the same file, and the install guide asks you to turn on case sensitivity for correct operation. Microsoft’s way is per folder, from PowerShell run as Administrator, on an empty folder you will decode into:

How to decompile an APK with Apktool

Decoding is d (or decode), and I would name the output folder every time:

The reason is that the project disagrees with itself about the default. The 3.0.3 help says apk.out, while the documentation’s decoding page shows bar.apk going to a folder called bar. With -o you never have to find out. Add -f to overwrite a folder from an earlier run.

To see it on a real app, I took Binary Eye 1.75.5, an open-source barcode scanner, straight from F-Droid and checked the download against F-Droid’s index. Decoding it took 44 seconds:

Inside the folder you get the decoded AndroidManifest.xml, the layouts, strings and other resources as editable files, the code as smali, and apktool.yml, the file Apktool reads to rebuild the app. Leave that file alone unless you know why you are changing it. Binary Eye came out as 2,936 smali files, and 2,606 of them sit loose at the top with names like a.smali and a0.smali rather than in package folders. Expect to search rather than browse.

The command in the screenshot adds -p work\framework, which sets where Apktool keeps its framework files. You will not normally need it; I ran it in a sandbox with no user profile, where the default folder could not be created and the decode stopped with “Could not create framework directory”.

Three options save time on big apps. --only-manifest decodes just the manifest, which is often all a first look needs: permissions, exported components, whether the app is debuggable. Don’t expect it to be quicker, though. On Binary Eye it still disassembled the code and took 40 seconds, and because it skips the app’s own resources, every label, icon and theme in the manifest came out empty, with a warning for each. The permissions were all there.

-s (--no-src) leaves the code as dex files and -r (--no-res) leaves the resources compiled, so you can skip the half you are not changing. By default version 3 disassembles only the classes*.dex files at the root of the APK; -a (--all-src) takes the others too, which the project says is at your own risk: some apps keep encrypted or malformed dex files there.

Each release carries the current Android framework, which covers most apps. Apps from a phone maker’s own system image may need that maker’s framework as well: pull it from the device (it usually has “resources”, “res” or “framework” in its name) and install it with apktool if. Apktool keeps frameworks in AppData\Local\apktool on Windows, ~/.local/share/apktool on Linux and ~/Library/apktool on a Mac, and it does not check whether a saved framework is out of date, so clear the old ones with apktool cf after an upgrade. A few APKs built with an OEM’s modified build tools, which the FAQ calls “Magic APKs”, will not decode or build at all.

How to rebuild and sign an APK

Building is b (or build), pointed at the folder, never at an APK:

Without -o the APK goes to dist inside the folder. Rebuilding Binary Eye took 32 seconds. Two build options cover a lot of testing work on their own: --debuggable sets android:debuggable="true" in the manifest, and --net-sec-conf adds a generic network security configuration file to the app, a common starting point when you want its traffic through an intercepting proxy.

There is a catch with both. Apktool skips work it thinks is already done, so if you have built the folder once and then run apktool b --debuggable app, it reports that the manifest and smali “have not changed”, builds the APK from what it made last time, and the flag does nothing. My second build came back in two seconds without the attribute. Add -f to force a full build and it does what it says:

What comes out is unsigned, and the documentation is plain that a rebuilt app has to be signed again before it will run. The FAQ explains that the missing META-INF folder was where the signatures lived, and that the app is no longer signed once you have changed it. My rebuilt Binary Eye had no signature of either kind, where the F-Droid original carried both the old META-INF files and the newer signing block. Don’t judge the result by its size either: the FAQ says to expect a smaller file, and mine came out 140 KB larger than the original.

Signing is a job for Android’s own tools rather than Apktool. You need a key, which keytool from any JDK will make, and zipalign and apksigner from the Android SDK Build Tools. Android’s documentation is firm about the order: align first, then sign, because any change to an APK after apksigner has signed it breaks the signature.

apksigner reads the keystore password from standard input unless you pass it with --ks-pass. -P 16 aligns any native libraries to a 16 KB page boundary, which Android’s documentation says suits devices with either 16 KB or 4 KB pages, and verify --print-certs shows which certificate the app now carries, which is the quickest way to confirm the signing worked.

Your key is not the developer’s, and that matters on a phone that already has the app. Android’s update model expects an app’s signing key never to change, so a copy signed with test.jks will not install over the original as an update. Remove the original first, or test the patched build on an emulator or a spare device.

--copy-original keeps the original manifest and META-INF, but the FAQ is clear that this works only with the old v1 signature scheme, so it is no way round signing a modern app.

What changed in Apktool 3

Version 3, first published on GitHub as 3.0.1 in February 2026, dropped aapt1 for aapt2 alone, dropped 32-bit platforms, and now detects the API level itself, so -api is gone. The jar shrank with it, from 25.9 MB for 2.12.1 to 15.5 MB. The change most likely to break an old tutorial is the options: every advanced option lost its short form and now only has a long one.

So a v2 command such as apktool d -b app.apk now stops before it reads the file. I ran it against 3.0.3 with Binary Eye:

It exits with an error and prints the decode options, and that printout is worth knowing about. Run apktool on its own and the help lists only the common options; --no-debug-info, --match-original, --copy-original, --debuggable and the other long-only options do not appear, and neither do the framework-cleaning commands. The full list for d or b shows up when you give that command an option it does not know, or on the CLI parameters page at apktool.org. apktool b -c fails the same way, which matters because the project’s own FAQ still tells you to use -c / --copy-original.

Here is how the old short options map across, from the project’s 3.0 release notes:

Apktool 2	Apktool 3
d -b	d --no-debug-info
d -k	d --keep-broken-res
d -m	d --match-original
d -resm	d --res-resolve-mode
b -a	b --aapt
b -c	b --copy-original
b -d	b --debuggable
b -n	b --net-sec-conf
b -na	b --no-apk
b -nc	b --no-crunch
efd	cf (clean-frameworks)
-api, --use-aapt1, --only-main-classes	removed

Two smaller changes catch out scripts rather than people. The resource resolve modes are now default, greedy and lazy instead of remove, dummy and keep. And in apktool.yml, packageInfo is now resourcesInfo and forcedPackageId is now packageId, so anything that edits that file between decode and build needs updating. Decoded XML looks a little different too: dp instead of dip, match_parent instead of fill_parent, and short hex values, so a diff against a folder decoded with version 2 will be noisy.

There is more change to come. The 3.0.3 notes call it the last of the 3.0 line, and the changelog for the next release moves the project’s required build version to JDK 17.

Apktool vs jadx

They answer different questions. jadx decompiles Dalvik bytecode to Java you can read, in a command-line tool and a GUI with search, jump-to-declaration and a smali debugger, and its README warns that in most cases it cannot decompile all of the code. Apktool gives you smali instead of Java, which is harder to read but is what you edit, and rebuilding the app is Apktool’s job: jadx’s README lists no build step. A common pattern is to read the logic in jadx, then make the change in Apktool’s smali and rebuild.

dex2jar is the older route to Java. Its d2j-dex2jar converts an app’s .dex code into Java .class files packed in a jar, which you then open in a Java decompiler, and it carries its own smali and baksmali. Like jadx, it does not rebuild an app from resources and a manifest, and its last release, 2.4, came out in October 2023. For reading code, jadx does the conversion and the decompiling in one tool.

From our archive, Androguard is the Python route for scripting analysis across many APKs, and drozer tests an app’s exposed components on a running device, which is the natural next step once Apktool has shown you which components the manifest exports.

You can download Apktool here:

Apktool 3.0.3 on GitHub

Or read more here.

Advertisement