Let’s discuss every layer:

Linux Kernel:

It is the bottom layer. Provide a level of abstraction between hardware and it

contains all essential hardware devices like Camera, Display Driver, Flash, Wi-Fi,
IPC, etc. It is the heart of Android architecture.

Android Libraries:
On the top of the Linux Kernel, Android libraries provide Java-based libraries,
like
Android.app- provide access to the app model
Android.Content- published & messaging between applications. etc.

Android Runtime:

On the Top of Android Libraries, there is Android Runtime, which provides a key
component called Dalvik Virtual Machine. This is a kind of Java Virtual Machine
(JVM) specially designed and optimized for Android. It takes less memory space and
provides high performance.

Application Framework:

On the Top of Android Runtime, there is an Application Framework. It provides

higher-level services to the application in the form of a Java class. Services are
like-
Activity Manager- controls all lifecycle.
Content Provider- Allow the application to share data with other apps.
Resource Manager- provides access to resources like strings, colors, and UI layout.
Notification Manager

Applications:

On the top of the Application Framework, there are Applications. All applications
like Home, Contacts, Phone, Browser, etc. use Android Framework that uses the
Android Runtime and Libraries.

Android Runtime:

Java Source code is compiled using Java compiler to byte code(.class file),
This byte code is compiled using Dex Compiler to Dalvik Bytecode,
Then run it in Dalvik's virtual machine.

Currnent version of Android executes the Dalvik bytecode, and in Android, it is

known as ART (Android Runtime), it is the successor of the Dalvik VM.

The difference between the ART and Dalvik VM is the way the bytecode is executed.

In DVM(Dalvik VM) the bytecode is translated into machine code at the time of
execution it is also known as JIT(Just-In-TIme compilation). It benefits the speed
of compiling code and also maintains the flexibility of code interpretation.

So it is about DVM but android did something next level and android implemented AoT
(Ahead-of-Time) and it replaces the DVM,
Android runtime uses a hybrid combination of Ahead-of-time and Just-in-time
compilation.

AOT goes ahead and improves the performance by a factor or 2 and reduces the power
consumption due to Device specific optimization.

Android Security:

Android implemented a Defence-in-Depth approach, It means if a malicious

application is installed in Android, but due to lower privileges and sandbox
technique it cannot escape its runtime and can't read the memory of other
applications.

Features of Android security:

Application Sandbox: Apps run in a sandboxed environment to prevent unauthorized

access to user data and system resources.

Permissions: The Android platform includes a permission system allowing users to

control the data and resources an app can access.

SELinux: Android uses Security-Enhanced Linux (SELinux) to enforce mandatory access

control policies, which helps protect the system from malicious apps.

Code Signing: Android requires that all apps be signed with a digital certificate,
which ensures that the app comes from a trusted source and hasn't been tampered
with.

Google Play Protect: Google Play Protect is a built-in security feature that scans
apps on Google Play for malware and other security threats.

Runtime Permissions: Starting with Android 6.0 (Marshmallow), users must grant
permission to an app to access certain data or resources at runtime rather than
during the installation.

Network Security Configuration: Android provides a way for app developers to

configure the network security of their app, including SSL/TLS certificate pinning
and other security settings.

Secure IPC: Android's Inter-Process Communication (IPC) mechanism provides secure

communication between apps and services running on the same device.

Verified Boot: Android devices include a verified boot process that ensures the
integrity of the device's software and prevents unauthorized modifications.

Hardware Security: Android devices include hardware security features such as a

Trusted Execution Environment (TEE) and hardware-backed key storage to protect
sensitive data.

Android APK file Structure:

Android applications are bundled in a single file type called APK (Android Package
Kit).
They come with an apk suffix but are just ZIP files. If you modify the suffix, you
can extract their contents.
To be more precise, an 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:

META-INF – This folder contains verification information and is generated when

“signing” the application. It is basically the fingerprint information for every
file contained within the APK, meaning 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 is used to verify app integrity with the public key.

MANIFEST.MF – Contains the SHA-256-Digest of all the files in the apk. It is used
to verify the validity of each file in the zip, ensuring that altering this file or
any other files in the zip container will revoke the signature and make it invalid.

assets – The developer controls application resources in the folder hierarchy.

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 store their Javascript code in the assets
folder.
Xamarin applications store DLL files in the assemblies folder, which acts in the
same manner.

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 and resources.
The permissions this application requires to run and the permissions required to
access this application’s information by other apps.
Compatibility features (e.g., 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.

Incidentally, Appdome’s TOTALCode, and more specifically Encrypt Strings and

Resources and Non-Native Code Obfuscation switches to seek out those files when
obfuscating the application’s code and alters 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,
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. Depending on the selected Fusion policy, its content
might change as part of the fusion process.

lib – A folder that 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 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 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.

Reverse Engineering the APK:

What is APK Decompilation?

APK decompilation is the process of reverse engineering an APK file to retrieve its
source code.

APK decompilation is useful for understanding how an Android app works.

How to decompile the APK

There are several free and open source APK decompiler tools available for doing
this. But, the three most popular ones are:

JADX
Apktool
Bytecode Viewer

SSL Pinning

SSL Certificate Pinning, or pinning for short, is the process of associating a host
with its certificate or public key. Once you know a host’s certificate or public
key, you pin it to that host.

The developer configures SSL pinning to refuse all except one or a few
predetermined certificates. The program validates the server certificate with the
pinned certificate whenever it connects to a server(s). The SSL connection is made
if and only if the server certificate & the pinned certificate match.

Why do we need SSL pinning?

The use of SSL pinning effectively protects apps from the aforementioned attacks by
narrowing down the set of trustworthy certificates. It also prevents reverse
engineers from installing a custom root CA to their own device’s store to examine
the application’s functioning and communication with the server.