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.apkArchive: 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.arscHowever, at this point you have simply inflated compiled sources. If you tried to view AndroidManifest.xml. You'd be left viewing this.P4F0\fnversionCodeversionNameandroid* , editing or viewing a compiled file is next to impossible. That is where Apktool comes into play.$ apktool d testapp.apkI: Using Apktool 2.0.0 on testapp.apkI: Loading resource table...I: Decoding AndroidManifest.xml with resources...I: Loading resource table from file: 1.apkI: Regular manifest package...I: Decoding file-resources...I: Decoding values */* XMLs...I: Baksmaling classes.dex...I: Copying assets and libs...$Viewing AndroidManifest.xml again results in something much more human readableIn addition to XMLs, resources such as 9 patch images, layouts, strings and much more are correctly decoded to source form.
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 fileInfo 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 - Store framework files into -t, --tag - Tag frameworks using Allow for a finer control over how the files are named and how they are stored.$ apktool if framework-res.apkI: Framework installed to: 1.apk // pkgId of framework-res.apk determines number (which is 0x01)$ apktool if com.htc.resources.apkI: Framework installed to: 2.apk // pkgId of com.htc.resources is 0x02$ apktool if com.htc.resources.apk -t htcI: Framework installed to: 2-htc.apk // pkgId-tag.apk$ apktool if framework-res.apk -p foo/barI: Framework installed to: foo/bar/1.apk$ apktool if framework-res.apk -t baz -p foo/barI: 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 theseto 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.ExampleLets say you want to decode HtcContacts.apk from an HTC device. If you try you will get an error message.$ apktool d HtcContacts.apkI: Loading resource table...I: Decoding resources...I: Loading resource table from file: 1.apkW: Could not decode attr value, using undecoded value instead: ns=android, name=drawableW: Could not decode attr value, using undecoded value instead: ns=android, name=iconCan't find framework resources for package of id: 2. You must install proper framework files, see project website for more info.We must get HTC framework resources before decoding this apk. We pull com.htc.resources.apk from our device and install it$ apktool if com.htc.resources.apkI: Framework installed to: 2.apkNow we will try this decode again.$ apktool d HtcContacts.apk I: Loading resource table...I: Decoding resources...I: Loading resource table from file: /home/brutall/apktool/framework/1.apkI: Loading resource table from file: /home/brutall/apktool/framework/2.apkI: Copying assets and libs...As you can see. Apktool leveraged both 1.apk and 2.apk framework files in order to properly decode this application.Finding FrameworksFor the most part any apk in /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 usuallynamed with the naming of "resources", "res" or "framework".Example HTC has a framework called com.htc.resources.apk, LG has one called lge-res.apkAfter you find a framework file you could pull it via adb pull /path/to/file or use a file manager application. After you have thefile locally, pay attention to how Apktool installs it. The number that the framework is named during install corresponds to the pkgId of theapplication. These values should range from 1 to 30. Any APK that installs itself as 127 is 0x7F which is an internal pkgId.Internal FrameworksApktool comes with an internal framework like mentioned above. This file is copied to $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 upgradesManaging framework filesFrameworks are stored in different places depending on the OS in question. unix - $HOME/.local/share/apktool windows - %UserProfile%\AppData\Local\apktool mac - $HOME/Library/apktoolIf these directories are not available it will default to java.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.Since these locations are in sometimes hidden directories, managing these frameworks becomes a challenge. A simple helper function(added in v2.2.1) allows you to run 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.Tagging framework filesFrameworks are stored in the naming convention of: -.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 heroI: Framework installed to: /home/brutall/apktool/framework/2-hero.apk$ apktool if com.htc.resources.apk -t desireI: Framework installed to: /home/brutall/apktool/framework/2-desire.apkThen:$ apktool d HtcContacts.apk -t heroI: Loading resource table...I: Decoding resources...I: Loading resource table from file: /home/brutall/apktool/framework/1.apkI: Loading resource table from file: /home/brutall/apktool/framework/2-hero.apkI: Copying assets and libs...$ apktool d HtcContacts.apk -t desireI: Loading resource table...I: Decoding resources...I: Loading resource table from file: /home/brutall/apktool/framework/1.apkI: Loading resource table from file: /home/brutall/apktool/framework/2-desire.apkI: Copying assets and libs...You don't have to select a tag when building apk - apktool automatically uses the same tag, as when decoding.
Docs exist for the mysterious 9patch images hereand there. (Read these first). These docs though are meant for developersand lack information for those who work with already compiled 3rd party applications. There you can find information how to create them, butno 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. source - You know this one. You find it in the source of an application or freely available online. These are images with a black border around them. compiled - The mysterious form found in apk files. There are no borders and the 9patch data is written into a binary chunk called npTc. You can't see or modify it easily, but Android OS can as its quicker to read.There are problems related to the above two points. You can't move 9patch images between both types without a conversion. If you try and unpack 9patch images from an apk and use it in the source of another, you will get errors during build. Also vice versa, you cannot take source 9patch images directly into an apk. 9patch binary chunk isn't recognized by modern image processing tools. So modifying the compiled image will more than likely break the npTc chunk, thus breaking the image on the device.The only solution to this problem is to easily convert between these two types. The encoder (which takes source to compiled) is built intothe aapt tool and is automatically used during build. This means we only need to build a decoder which has been in apktool since v1.3.0and is automatically ran on all 9patch images during decode.So if you want to modify 9patch images, don't do it directly. Use apktool to decode the application (including the 9patch images) and thenmodify the images. At that point when you build the application back, the source 9patch images will be compiled. 2b1af7f3a8