First lets take a lesson into apk files. Apks are nothing more than a zip file containing resources and assembled java code.
If you were to simply unzip an apk like so, you would be left with files such as classes.dex and resources.arsc.
$ unzip testapp.apk
Archive: testapp.apk
inflating: AndroidManifest.xml
inflating: classes.dex
extracting: res/drawable-hdpi/ic_launcher.png
inflating: res/xml/literals.xml
inflating: res/xml/references.xml
extracting: resources.arscAndroidManifest.xml. You'd be left viewing this.
P 4 F 0 \ f n v e r s i o n C o d e v e r s i o n N a m e a n d r o i d * h t t p : / / s c h e m a s . a n d r o i d . c o m / a p k / r e s / a n d r o i d p a c k a g e p l a t f o r m B u i l d V e r s i o n C o d e p l a t f o r m B u i l d V e r s i o n N a m e m a n i f e s t b r u t . a p k t o o l . t e s t a p p 1 . 0 2 1 A P K T O O L $ apktool d testapp.apk
I: Using Apktool 2.0.0 on testapp.apk
I: Loading resource table...
I: Decoding AndroidManifest.xml with resources...
I: Loading resource table from file: 1.apk
I: Regular manifest package...
I: Decoding file-resources...
I: Decoding values */* XMLs...
I: Baksmaling classes.dex...
I: Copying assets and libs...
$AndroidManifest.xml again results in something much more human readable
<?xml version="1.0" encoding="utf-8" standalone="no"?>
<manifest xmlns:android="https://schemas.android.com/apk/res/android" package="brut.apktool.testapp"
platformBuildVersionCode="21" platformBuildVersionName="APKTOOL" />
The decode option on Apktool can be invoked either from d or decode like shown below.
$ apktool d foo.jar
// decodes foo.jar to foo.jar.out folder
$ apktool decode foo.jar
// decodes foo.jar to foo.jar.out folder
$ apktool d bar.apk
// decodes bar.apk to bar folder
$ apktool decode bar.apk
// decodes bar.apk to bar folder
$ apktool d bar.apk -o baz
// decodes bar.apk to baz folder
The build option can be invoked either from b or build like shown below
$ apktool b foo.jar.out
// builds foo.jar.out folder into foo.jar.out/dist/foo.jar file
$ apktool build foo.jar.out
// builds foo.jar.out folder into foo.jar.out/dist/foo.jar file
$ apktool b bar
// builds bar folder into bar/dist/bar.apk file
$ apktool b .
// builds current directory into ./dist
$ apktool b bar -o new_bar.apk
// builds bar folder into new_bar.apk
$ apktool b bar.apk
// WRONG: brut.androlib.AndrolibException: brut.directory.PathNotExist: apktool.yml
// Must use folder, not apk/jar file
Info In order to run a rebuilt application. You must resign the application. Android documentation can help with this.
Frameworks can be installed either from if or install-framework, in addition two parameters
-p, --frame-path <dir> - Store framework files into <dir> -t, --tag <tag> - Tag frameworks using <tag>$ apktool if framework-res.apk
I: Framework installed to: 1.apk
// pkgId of framework-res.apk determines number (which is 0x01)
$ apktool if com.htc.resources.apk
I: Framework installed to: 2.apk
// pkgId of com.htc.resources is 0x02
$ apktool if com.htc.resources.apk -t htc
I: Framework installed to: 2-htc.apk
// pkgId-tag.apk
$ apktool if framework-res.apk -p foo/bar
I: Framework installed to: foo/bar/1.apk
$ apktool if framework-res.apk -t baz -p foo/bar
I: Framework installed to: foo/bar/1-baz.apk
As you probably know, Android apps utilize code and resources that are found on the Android OS itself. These are known as framework resources and Apktool relies on these
to properly decode and build apks.
Every Apktool release contains internally the most up to date AOSP framework at the time of the release. This allows you to decode and build most apks without a problem.
However, manufacturers add their own framework files in addition to the regular AOSP ones. To use apktool against these manufacturer apks you must first install the
manufacturer framework files.
HtcContacts.apk from an HTC device. If you try you will get an error message.
$ apktool d HtcContacts.apk
I: Loading resource table...
I: Decoding resources...
I: Loading resource table from file: 1.apk
W: Could not decode attr value, using undecoded value instead: ns=android, name=drawable
W: Could not decode attr value, using undecoded value instead: ns=android, name=icon
Can't find framework resources for package of id: 2. You must install proper framework files, see project website for more info.com.htc.resources.apk from our device and install it
$ apktool if com.htc.resources.apk
I: Framework installed to: 2.apk$ apktool d HtcContacts.apk
I: Loading resource table...
I: Decoding resources...
I: Loading resource table from file: /home/brutall/apktool/framework/1.apk
I: Loading resource table from file: /home/brutall/apktool/framework/2.apk
I: Copying assets and libs...1.apk and 2.apk framework files in order to properly decode this application.
/system/framework on a device will be a framework file. On some devices they might reside in
/data/system-framework and even cleverly hidden in /system/app or /system/priv-app. They are usually
named with the naming of "resources", "res" or "framework".
Example HTC has a framework calledAfter you find a framework file you could pull it via adb pull /path/to/file or use a file manager application. After you have the file locally, pay attention to how Apktool installs it. The number that the framework is named during install corresponds to the pkgId of the application. These values should range from 1 to 30. Any APK that installs itself ascom.htc.resources.apk, LG has one calledlge-res.apk
127 is 0x7F which is an internal pkgId.
$HOME/apktool/framework/1.apk during use.
Warning Apktool has no knowledge of what version of framework resides there. It will assume its up to date, so delete the file during Apktool upgrades
$HOME/.local/share/apktool%UserProfile%\AppData\Local\apktool$HOME/Library/apktooljava.io.tmpdir which is usually /tmp.
This is a volatile directory so it would make sense to take advantage of the parameter --frame-path to select an alternative folder for framework files.
apktool empty-framework-dir to empty out frameworks.
Note Apktool has no control over the frameworks once installed, but you are free to manage these files on your own.
<id>-<tag>.apk. They are identified by pkgId and optionally custom tag. Usually tagging frameworks isn't necessary, but if you work on apps from many different devices and they have incompatible frameworks, you will need some way to easily switch between them.
You could tag frameworks by:
$ apktool if com.htc.resources.apk -t hero
I: Framework installed to: /home/brutall/apktool/framework/2-hero.apk
$ apktool if com.htc.resources.apk -t desire
I: Framework installed to: /home/brutall/apktool/framework/2-desire.apk$ apktool d HtcContacts.apk -t hero
I: Loading resource table...
I: Decoding resources...
I: Loading resource table from file: /home/brutall/apktool/framework/1.apk
I: Loading resource table from file: /home/brutall/apktool/framework/2-hero.apk
I: Copying assets and libs...
$ apktool d HtcContacts.apk -t desire
I: Loading resource table...
I: Decoding resources...
I: Loading resource table from file: /home/brutall/apktool/framework/1.apk
I: Loading resource table from file: /home/brutall/apktool/framework/2-desire.apk
I: Copying assets and libs...
Warning SmaliDebugging has been marked as deprecated in 2.0.3, and removed in 2.1. Please check SmaliIdea for a debugger.
Docs exist for the mysterious 9patch images here
and there. (Read these first). These docs though are meant for developers
and lack information for those who work with already compiled 3rd party applications. There you can find information how to create them, but
no information about how they actually work.
I will try and explain it here. The official docs miss one point that 9patch images come in two forms: source & compiled.
npTc. You can't see or modify it easily, but Android OS can as its quicker to read.npTc chunk, thus breaking the image on the device.v1.3.0
and is automatically ran on all 9patch images during decode.
What about the -j switch shown from the original YouTube videos?
Read Issue 199. In short - it doesn't exist.
Is it possible to run apktool on a device?
Sadly not. There are some incompatibilities with running the aapt binary on the device. Additionally, older builds of Android have problems with java.nio.
Where can I download sources of apktool?
From our Github or Bitbucket project.
Resulting apk file is much smaller than original! Is there something missing?
There are a couple of reasons that might cause this.
META-INF is missing.META-INF contains apk signatures. After modifying the apk it is no longer signed. You can use -c / --copy-original to retain these signatures. However,
using -c uses the original AndroidManifest.xml file, so changes to it will be lost.
$HOME/.local/share/apktool
$HOME/Library/apktool
$HOME/AppData/Local/apktool
v2.6.0apktool empty-framework-dir --force
v2.5.0apktool empty-framework-dir --force
v2.3.1apktool empty-framework-dir --force
v2.3.0apktool empty-framework-dir --force
v2.2.1apktool empty-framework-dir --force
mkdir -p ~/.local/share; mv ~/apktool ~/.local/share
move %USERPROFILE%\apktool %USERPROFILE%\AppData\Local
v2.0.2$HOME/apktool/framework/1.apk due to internal API update (Android Marshmallow)
-a / --aapt are still used and can override the internal aapt)$HOME/apktool/framework/1.apk-o / --output is now used for the output of apk/directory-t / --tag is required for tagging framework files-advance / --advanced will launch advance parameters and information on the usage output-m / --match-original is a new feature for apk analysis. This retains the apk is nearly original format, but will make rebuild more than likely not work due to ignoring the changes that newer aapt requires[d]ecode, there will be new folders (original / unknown) in the decoded apk folderMETA-INF folder / AndroidManifest.xml, which are needed to retain the signature of apks to prevent needing to resign. Used with -c / --copy-original on [b]uildapktool.yml collects more information than last versionSdkInfo - Used to repopulate the sdk information in AndroidManifest.xml since newer aapt requires version information to be passed via parameterpackageInfo - Used to help support Android 4.2 renamed manifest feature. Automatically detects differences between resource and manifest and performs automatic --rename-manifest-package on [b]uildversionInfo - Used to repopulate the version information in AndroidManifest.xml since newer aapt requires version information to be passed via parametercompressionType - Used to determine the compression that resources.arsc had on the original apk in order to replicate during [b]uildunknownFiles - Used to record name/location of non-standard files in an apk in order to place correctly on rebuilt apksharedLibrary - Used to help support Android 5 shared library feature by automatically detecting shared libraries and using --shared-lib on [b]uild| Old (Apktool 1.5.x) | New (Apktool 2.0.x) |
|---|---|
| apktool if framework-res.apk tag | apktool if framework-res.apk -t tag |
| apktool d framework-res.apk output | apktool d framework.res.apk -o output |
| apktool b output new.apk | apktool b output -o new.apk |
v1.5.1r05-ibot via downloading Mac, Windows or Linux$HOME/apktool/framework/1.apk
Options that can be executed at any time.
-version, --version
Outputs current version. (Ex: 1.5.2)
Verbose output. Must be first parameter
Quiet output. Must be first parameter
Advance usage output
These are all the options when clearing the framework directory.
-f, --force
Force delete destination directory.
The location where framework files are loaded from
Info Added in v2.5.0These are all the options when listing the framework directory.
The location where framework files are loaded from
These are all the options when decoding an apk.
-api, --api-level <API>
The numeric api-level of the smali files to generate (defaults to targetSdkVersion)
Prevents baksmali from writing out debug info (.local, .param, .line, etc). Preferred to use if you are comparing smali from the same APK of different versions. The line numbers and debug will change among versions, which can make DIFF reports a pain.
Force delete destination directory. Use when trying to decode to a folder that already exists
Forces decode of AndroidManifest regardless of decoding of resources flag. Will more than likely prevent rebuild as used for static analysis of the manifest.
If there is an error like "Invalid Config Flags Detected. Dropping Resources...". This means that APK has a different structure then Apktool can handle. This might be a newer Android version or a random APK that doesn't match standards. Running this will allow the decode, but then you have to manually fix the folders with -ERR in them.
Matches files closest as possible to original, but prevents rebuild.
Prevents decoding/copying of unknown asset files.
The name of the folder that apk gets written to
Only disasemble dex classes in root (classes[0-9].dex)
The folder location where framework files should be stored/read from
This will prevent the decompile of resources. This keeps the resources.arsc intact without any decode. If only editing Java (smali) then this is the recommended action for faster decompile & rebuild
This will prevent the disassembly of the dex file(s). This keeps the apk dex file(s) and simply moves it during build. If you are only editing the resources. This is the recommended action for faster disassemble & assemble
Uses framework files tagged via <TAG>
These are all the options when building an apk.
-a, --aapt <FILE>
Loads aapt from the specified file location, instead of relying on path. Falls back to $PATH loading, if no file found. Unless $PATH references prebuilt custom aapt. This will more than likely not work.
The numeric api-level of the smali files to build against (defaults to minSdkVersion)
Copies original AndroidManifest.xml and META-INF folder into built apk. Scheduled for deprecation.
Adds debuggable="true" to AndroidManifest file.
Overwrites existing files during build, reassembling the resources.arsc file and dex file(s)
Adds a generic Network Security Configuration file in the output APK.
Disable crunching of resource files during the build step.
The name and location of the apk that gets written
The location where framework files are loaded from
Use the aapt2 binary instead of appt