What it does
Apktool decodes an Android package into something you can read and edit, then puts it back together again. On the resource side it parses the binary resources.arsc table and the compiled binary XML in the manifest and layout files, restoring them to the plain text form the developer originally wrote, complete with resolved resource identifiers and names. On the code side it disassembles the DEX bytecode into smali, a readable assembly syntax for the Dalvik instruction set.
The rebuild path is what separates it from a pure decompiler. After you edit smali, swap a resource, or change a manifest flag, Apktool recompiles the resource table, reassembles the smali back to DEX, and packs a new APK. That package is unsigned, so you sign it yourself before installing. This decode, patch, rebuild loop is the standard way to disable certificate pinning, enable debuggable mode, insert an instrumentation library, or prove that a control can be removed from a shipped binary.
Where it fits
This is a workstation tool operated by someone doing hands on analysis: a mobile penetration tester, a malware analyst, or an engineer verifying what actually made it into a release build. It sits upstream of dynamic testing, since the repackaged and resigned APK is often the artifact you then run under a hooking framework. It presumes you are comfortable reading assembly level code and that you have the Android SDK signing tools available.
Strengths
- Resource decoding is the reason people reach for it. Recovering readable XML and named resources from the compiled table is work few other tools do properly.
- The rebuild path actually produces installable packages, which makes it a patching tool rather than only an inspection tool.
- Handles framework resource dependencies, so applications that reference vendor specific system frameworks decode correctly once you install the matching framework file.
Limitations
- Smali is not Java. For understanding program logic you will usually pair Apktool with a decompiler that produces Java-like source, and use Apktool only for the edit and rebuild half.
- Rebuilds fail on some applications. Unusual resource constructs, aggressive packers and obfuscators that emit deliberately malformed structures all break the round trip, and diagnosing that failure is manual work.
- It does no security analysis of its own. There are no findings, no rules and no report, only decoded files.
Who it suits
Anyone doing manual Android reverse engineering or repackaging. It is the wrong choice for a team that wants automated scanning of release builds with a triaged finding list, because Apktool is a component of that workflow, not the workflow itself.
Used Apktool? Recommend it under your own name and title.
Recommend this tool