.APK is the file format to distribute Android apps. .apks contain all elements the app requires to function. Appdome is a no-code mobile app security platform designed to secure Android apk apps without coding.
This Knowledge Base article explains each of the structural components of an .apk and its purpose. An .apk file is an Android binary. APK stands for Android Package Kit (also Android Application Package) and is the file format that Android uses to distribute and install apps. It contains all the elements that an app needs to install correctly on your device.
We hope you find it useful and enjoy using Appdome!
Android applications are bundled in a single file of type APK (Android PacKage).
They come with an
apk suffix but are just ZIP files. If you modify the suffix you can extract their contents.
By-the-way, if you want to be more precise, APK is a type of JAR (Java ARchive) which is a type of ZIP.
The contents of the .apk file always fit a specific structure:
AndroidManifest.xml– A required file that describes the application.
A complete specification can be found here https://developer.android.com/guide/topics/manifest/manifest-intro
As part of the Fusion process, the binary representation of the AndroidManifest.xml usually changes, as Appdome adjusts the file to support the selected settings.
META-INF– This is a folder that contains verification information. This is what is generated when “signing” the application. This is basically fingerprint information for every file contained within the APK. This means that any modification to the APK (even replacing an icon) requires resigning the APK, otherwise, the OS will reject the installation, When signing applications these files are updated.
CERT.SF(May have another file name with the same suffix) – List of all files with their SHA-1 hashes.
CERT.RSA(May have another file name with the same suffix) – Contains signed content of
CERT.RFand is used to verify app integrity with the public key.
MANIFEST.MF– Contains the SHA-256-Digest of all the files in the apk. Is used to verify the validity of each file in the zip. Ensures that the alteration of this file or any of the other files in the zip container, will revoke the signature and make it invalid.
assets– Application resources in folder hierarchy controlled by the developer.
Incidentally, Appdome’s TOTALCode, and more specifically Encrypt Strings and Resources and Non-Native Code Obfuscation switches seek out those files when obfuscating the application’s code and alter them as part of the fusion process.
In addition, as part of the fusion process, some assets may be added to store information related to Fusion and the selected policy.
classes.dex– Google’s proprietary format for their version of the Java VM, it contains all Java/Kotlin code compiled to their specific bytecode called Dalvik.
classes.dexfile, due to limitations of the DEX format. Additional files will be numbered (i.e.
classes3.dexand so forth).
kotlin– This folder is present only if the application was written with Kotlin. It contains Kotlin specific data. Its content might be changed as part of the fusion process, dependable on the selected Fusion policy.
lib– A folder than contains native libraries (machine code). Since Android is cross-platform, it contains a subfolder for each supported processor:
armabi– Binaries that support at least ARMv5TE, deprecated since ndkr16 (Dec. 2017) and removed in ndkr17 (Jun. 2018).
armeabi-v7a– Binaries supporting ARMv7.
arm64-v8a– Binaries supporting ARMv8.
x86– Binaries supporting x86.
x86_64– Binaries supporting x86-64.
mips– Binaries for MIPS, deprecated since ndkr17.
The presence or lack of a subfolder indicates the support (or lack thereof) for that platform. For example, if there’s an
x86_64 subfolder, the application will be compatible with the Android emulator.
Appdome’s Binary Code Obfuscation will encrypt these files in order to protect them from reverse-engineering.
More info about supported ABI’s can be found here.
res– A folder that contains resources (like assets) but with a pre-defined folder hierarchy that the developer can’t change. These files are used to provide alternatives for different screen orientations, OS versions, and multi-language support.
resources.arsc– A file that contains information that links the code (
classes.dex) to the resources (
res). For example, the code might reference the text of a dialog, while the resources contain that text in all languages. The Android OS then chooses the correct language according to the device’s locale configuration.
If you have any questions, please send them our way at email@example.com or via the chat window on the Appdome platform.