Appdome is a no-code mobile integration platform as a service (iPaaS), supporting a wide variety of implementations for Android and iOS apps.
This Knowledge Base article summarizes what a .apk file is. A .apk file is an Android binary.
All of Appdome’s services can be added to any iOS or Android app instantly, with no code or coding.
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 partial list of them:
- Application’s package name.
- All the application’s components like activities.
- What permissions this application requires to run, and the permissions required to access this application’s information by other apps.
- Compatibility feature like 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.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.
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:
- 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.dexfile, due to limitations of the DEX format. Additional files will be numbered (i.e.
classes3.dexand 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_64subfolder, 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 pre-defined folder hierarchy that the developer can’t change, these files used to provide alternatives for different screen orientation, 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 selected Fusion policy, more files may be added to this folder and files content may change.
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?
If you have any questions, please send them our way at firstname.lastname@example.org or via the chat window on the Appdome platform.