APK stands for Android Package. It is the package file format used by the Android operating system for the distribution and installation of mobile apps.

There are multiple use cases of working with a compiled package. The absence of source code is the primary reason why you might be reading this but I’ve listed down some other use cases I’ve encountered in the past in the last section.

If you are short on time and want a quick fix one-time solution, I would recommend using an online tool like this. However, as an android developer, I would recommend going through the entire article and setting up your own rig to have greater control over this process.

I will be working with the Omni Notes app to give a detailed walkthrough of the process. It is an open-source application so we will have the source code to compare with at our disposal. You can find the source code here.

Extracting the APK from a device

Find the path at which the APK is located using the package name. For Omni Notes, the package name is it.feio.android.omninotes

adb shell pm path it.feio.android.omninotes

For my device, this produces an output 
/data/app/it.feio.android.omninotes-PVFvNp5KpYThjXVRoievrw==/base.apk

To extract the apk from the device run the following command using this path

adb pull <path returned from the command above> omninotes.apk

You will now have an APK in your current working directory

Note: Depending on the kind of app you are working with, the packaging of the apk might be different. It could be a single apk having all the configurations or can be multiple apk files to reduce the final size. Please go through this documentation on how split-apks are generated and the contents of each split

Exploring the APK

An APK is similar to a zipped version of all the components that go into the making of an app. Changing the extension of the extracted to .zip will reveal contents similar to this

This is just an easy way to explore the contents of an APK. You still cannot understand the contents of the files because they have been compressed using different tools. For example, the contents of the AndroidManifest.xml is

0300 0800 1c4f 0000 0100 1c00 c026 0000
9000 0000 0000 0000 0000 0000 5c02 0000
0000 0000 0000 0000 0e00 0000 1c00 0000
2800 0000 3400 0000 4c00 0000 5e00 0000
7200 0000 8400 0000 ac00 0000 c600 0000

This is because the XML files are packaged using the Android XML Binary Format. The binary resources have been packed into the resources.arsc file. The code has been packed into classes.dex. There are multiple tools to decode these files like apktool, androguard, dex2jar, etc. I’ll be using apktool because of the versatility of the tool itself and its ability to repackage the modifications that we perform on an APK and dex2jar to decompile the java/kotlin code.

Extracting the resources

Download the apktool and add it to your path under the alias apktool
Running the following command decompiles the resources and the XML files of the APK to human-readable text and the java,kotlin code to smali files

apktool d omninotes.apk 

The binary resources and the XML files have been converted to their original form

The java/kotlin code itself has been extracted into a smali folder. It is recommended to work with the smali format if we are going to modify code and repack the APK but that is not in the scope of this article.

Extracting the code

The code is packed into .dex files. Dex stands for Dalvik Executable. A Dex file contains code that is ultimately executed by the Android Runtime

Multiple dex files might be generated for an application depending on the number of methods that are being used. Applications with multiple dex files are hence called multidex applications

In our example of working with the omninotes apk, we have just a single classes.dex file

We can convert the dex file into a jar file using the dex2jar tool. The following command converts the dex file into a jar file

dex2jar classes.dex

This produces classes-dex2jar in the same folder

We can explore the classes in the jar file using the JD-GUI tool

Use Cases

Let me list down the use cases of why I have used this in the past

• Understanding what some cloning apps were doing with our app that had been distributed through the play store and allowing users to circumvent some of the terms of use
• Finding out the root cause of some crashes when the mapping.txt file was not available
• Getting an understanding of implementations of some features done by popular apps
• Security analysis of how our app can be compromised and the vulnerabilities that have not been taken care of
• Finding out that the assets are compressed during the process of zipalign and we need not put the extra effort of compressing them

As a responsible software contributor, I request you to use the contents of this article only for the purpose of educational research and not have mala fide intentions to disrupt the hard work that developers have put in over the years for creating important and helpful mobile applications