Structure of an Android App Binary (.apk)

Learn about the structure of an Android application binary (.apk).

.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!

About .apk files

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.
  The manifest contains key information elements about the application, here’s a partial list of them:
  • Application’s package name.
  • All the application’s components, such as activities, resources.
  • What permissions this application requires to run, and the permissions required to access this application’s information by other apps.
  • Compatibility features (eg: minimum android version and supported devices).

  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.
  The contents of this folder are:
  • 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.RF and 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.
  For example, if your application displays a video, or comes with some document templates, they will be stored in the assets folder.
  In addition, certain frameworks also use the assets folder to store code and data. For example:
  • Cordova or React-native applications will store their Javascript code in the assets folder.
  • Xamarin applications will store DLL files in the assemblies folder, which acts in the same manner.

  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.
  APK files may contain more than one classes.dex file, due to limitations of the DEX format. Additional files will be numbered (i.e. classes2.dex, classes3.dex and so forth).
  As part of the fusion process, Appdome adds at least one more classes.dex containing only the selected policy. The application’s original classes.dex is also altered as part of the fusion process. Appdome’s Flow Relocation will obfuscate the original application’s code flow within the dex files.

• 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.
  During the Fusion process, Appdome unpacks and repacks the resource folder, so its binary representation of the .xml files or the nine-patch png files may change. Depending on the third-party SDKs and UI/Networking resources added to the application according to the customer selected Fusion set, more files may be added to this folder, and the content of files may change as well.
• 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.
  During the Fusion process, Appdome unpacks and repacks the resource folder, so its binary representation usually changes.

How Do I Learn More?

Check out the related Appdome article on .ipa files  (for iOS apps) or request a demo at any time.

If you have any questions, please send them our way at support@appdome.com or via the chat window on the Appdome platform.

Thank You

Thanks for visiting Appdome! Our mission is to make mobile integration easy. We hope we’re living up to the mission with your project. If you don’t already have an account, you can sign up for free.