Once in a while I find an Android app on the play store that I really think is cool. As an Android developer, I often analyze the technical aspects of the app I'm interested in. It might be just the way the UI works or some specific use of sensors and graphics rendering. I often also would like to know which frameworks or technologies the developer used to create that particular app.

There are already apps that can show you some of the frameworks the developer used, but I also wanted to figure this out my self. New frameworks appear all the time, so it might not be covered by these apps. Additionally, I thought that this could be a suitable feature for my Power APK app, which can be used to analyze apps installed on your device.

In this post I'll show some techniques I've used to analyze APKs, so that I could figure out what technologies and frameworks the developer used to build those apps. Luckily, Android makes it really easy to access and analyze APK files on the device.

Most of the time I just checked certain file names and grepped for strings because I wanted to make it quick and simple. That means that the results might not always be accurate, but it should still be fairly accurate most of the time.

Disclaimer: When you copy and analyze APK files, always make sure that you comply with developer's licenses and laws in you country.

Requirements

The tools that I found useful for analyzing APK files were already part of Android SDK and NDK, so in my case I didn't need to install anything additional.

Android SDK contains ADB and tools for dumping dex files.

The NDK contains various tools from LLVM compiler toolchain, from which I've used nm utility to dump symbol names inside of native libraries.

Then I only needed some zip utility for unzipping APK files and a text editor, both of which were already preinstalled on my system.

Pulling APK File From Device

The first thing you need to do is to get the APK file from the Android device to your development machine. I've already wrote a more detailed post on how to pull APK files from Android device, so here I'll just summarize the main steps.

First you should find the package name of the app you want to pull from the device. You can use my Android app Power Apk to do this. An alternative way would be to go through each package and dump its manifest with the aapt2 tool which is also part of Android SDK. And of course, you can often deduce which package name belongs to a certain app just by looking at the package name after listing all package names with adb shell pm list packages. But there are package names (including package names of my apps) where it's not completely obvious to which app they belong.

Once you have the package name, you can check the storage location of the APK file on the device with the following ADB command

adb shell pm path my.package.name

This is what I got when I dumped the path of my Bugjaeger app.

package:/data/app/eu.sisik.hackendebug-sxrxA4zM7Ngi9gCOEktU7Q==/base.apk

You can then use the path to pull the APK file from the device with ADB

adb pull /path/to/my.apk

Overview of APK File Structure

APK file is a regular ZIP archive with a certain file and folder structure. Which files and folders are present can vary a bit between applications. I'll try to mention the most important parts and the parts relevant to this post.

classes.dex

APK files contain one or more classes.dex files. These files contain the compiled Java/Kotlin code in Dalvik executable format. You can use the dexdump tool that is part of Android SDK to dump the content of .dex files. Even though you often find only one dex file per APK, there is a limit of maximum 65,536 methods per dex file that you can use in your app, so some apps need multiple dex files to work properly.

assets

As the name suggests, this folder contains various assets that you can bundle within your app. The nice thing about this folder (in comparison to res folder that I mentioned bellow) is that as a developer you can use the AssetManager class to access the read-only files in a similar way to how you access regular file system. It can contain .html and .js files loaded by a WebView and therefore it can be used by frameworks like Apache Cordova or Ionic.

res

This folder can also contain various resources and assets, but it has a bit more rigorous structure than the assets folder. It contains drawables, layouts, menus, and other stuff that you often use within your view hierarchy in binary xml format. It usually also contains the app icon as a mipmap for various screen resolutions. One advantage of keeping some resources in this folder is that you can provide localized versions of resources for different languages and versions for different screen orientations, and the system handles the proper loading of resources automatically. Additionally, the resources can be statically referenced directly in your code through IDs.

resources.arsc

This file contains the resource table in a binary format. It contains the type of resource (e.g. string, dimension,..), resource id, and resource name. The resources in the res folder can than be referenced through the ids listed in the table.

lib

The lib folder contains native shared .so libraries in elf format. This is the C/C++ code compiled to machine code with tools from Android NDK. Because Android supports multiple architectures and CPUs, the folder is organized into subfolders for different ABIs (e.g. armeabi-v7a, x86,...).

META-INF

This folder contains information related to application signing. It is used when signing the app with the JAR signing (V1) scheme. Newer Android versions (7.0+) also support v2/v3 schemes.

AndroidManifest.xml

Android manifest contains important information about the app that is used by the development tools, Android system, and app stores. It contains app's package name, version information, declarations of app components, requested permissions, and other important things. It is serialized into a binary xml format. You can dump its content with the appt tool or with my PowerApk app.

Finding Which Technologies/Frameworks Were Used

Once you have the APK file of the app you are interested in, you can view its content and extract it the same way as a regular zip file (renaming it and changing the file extension to .zip should allow you to browse the file on Windows).

Looking for presence of specific files inside of our APK/ZIP file should already reveal the use of some of the frameworks. In some cases we might need to dump content of some files and grep for specific strings.

Godot

[Godot] is a cross-platform 3D game engine with it's own visual editor. It's packed with a lot of features and it's open source. For now I only experimented with it in my tiny free-time projects (a game & voice changer), but I would really like to use Godot for some bigger client projects.

Godot's build system generates libgodot_android.so that you will find in subdirectories inside of the lib folder. There should be at least the armeabi-v7a folder, or the x86 folder.

In the unlikely case when somebody would also name his own native C++ library libgodot_android.so, you can additionally check symbol names inside of the library

arm-linux-androideabi-nm -D libgodot_android.so

Here I used the nm tool located somewhere inside my NDK directory (/toolchains/arm-linux-androideabi-4.9/prebuilt/windows-x86_64/bin) and dumped the dynamic symbols. You should be able to find multiple function names that correspond with the names in Godot's github repo.

Unity 3D

Unity 3D is another cross-platform game engine. I've used it in several client projects. It allows you to program applications in C# by using Mono project.

App that uses Unity 3D usually contains the libunity.so file inside of lib subfolders for each supported ABI. Additionally, the APK file will also contain either libmono.so or libil2cpp.so. The former library is used when selecting the usual mono scripting backend. The latter library is build with Unity's IL2CPP technology, which allows to convert IL code to C++, before compiling it to native .so library.

Apache Cordova

This framework was previously known as PhoneGap (now PhoneGap is Adobe's commercial version of this framework). It allows you to build Android apps using standard web technologies - HTML, CSS, and JavaScript.

It uses a WebView to load the HTML and JavaScript and through hooks into the Java API from JS you're able to use all the phone-specific stuff (e.g. accessing some sensors). Although I prefer cross-platform frameworks that use the native platform APIs directly (instead of a WebView), I still think this is an interesting technology. Longer time ago I created a web-based app generator that could spit out an APK file after you wrote your HTML/JS code in web editor.

App that uses Cordova should have cordova.js and index.html inside of assets/www directory.

Ionic Framework

Ionic is another hybrid mobile app framework that uses web technologies (HTML/CSS/JS) for creating apps. Ionic seems to be using Cordova under the hood together with Angular.js. That means it again uses a WebView to load HTML and JS from index.html and cordova.js.

When you check the content of assets/www/index.html, you can see that there are XML elements prefixed with "ion-", e.g. <ion-side-menus>, <ion-nav-bar>, or <ion-nav-buttons>

Cocos2d

Cocos2d is an open source framework for building apps and games. It contains multiple branches, but I guess on Android the Cocos2d-x branch might be used more often.

Dumping classes.dex should reveal names of classes that are clearly part of the framework

dexdump classes.dex | grep "cocos"

Above I used the dexdump tool which is part of Android SDK. You should be able to find it somewhere inside of the sdk/build-tools/[version number]/ directory.

Grepping for "cocos" listed multiple Cocos2d-x classes, e.g. "org/cocos2dx/lib/Cocos2dxActivity", "Lorg/cocos2dx/lib/Cocos2dxTypefaces", or "org/cocos2dx/lib/Cocos2dxSound".

How to Check This Stuff Quickly With an App

My Power APK Android app can be used to extract various details about apps installed on the phone. I've used the techniques I've described in this post to show some of the technologies used for creating an app. If you are interested in this stuff, you might find it useful. Additionally, it also allows you to extract Dalvik bytecode, so that you can get even more information about how a particullar app works internally.

Recently I have also created a simple online tool for analyzing APK files. You might want to check it out as well

https://sisik.eu/apk-tool

Previous Post