Unit 2 : Android Build Process and Device Rooting
Android Build Process
Android apps are typically built with Gradle, which orchestrates a series of
steps to turn app source code and resources into a deployable APK. First, the
Android Asset Packaging Tool (AAPT) compiles resources: all files under res/
and the [Link] are converted into a binary format, and an [Link]
file mapping resource IDs is generated. Next, the Java and Kotlin source code
(including the generated [Link]) is compiled by javac/kotlinc into .class files
(Java bytecode). Optionally (for release builds) ProGuard/R8 is run to shrink and
obfuscate the code – removing unused classes and renaming methods and
fields to unreadable names. Then the compiled .class files are converted into
Dalvik bytecode in one or more .dex files using the D8 compiler. Finally, all .dex
files plus the compiled resources are packaged into the APK file by the
packager. (The debug build is automatically signed with a debug key, whereas a
release build must be signed with the developer’s own keystore.)
• Build Steps (Gradle): The build proceeds roughly as follows:
1. Resource compilation: AAPT compiles all XML resources (layouts,
strings, etc.) and the manifest into binary form, generating an
[Link] class.
2. Source compilation: All Java/Kotlin source (including [Link] and
libraries) is compiled into .class bytecode by javac/kotlinc.
3. Shrink & obfuscate (if enabled): Tools like R8/ProGuard remove
unused code and rename classes/methods to short meaningless
names.
4. DEX generation: All .class files are converted to Dalvik bytecode
([Link]) via the D8 compiler. Android uses DEX format
because the ART/Dalvik runtimes do not run raw .class files.
5. Packaging: The final APK is assembled, containing all .dex files plus
compiled resources. The build system then signs (and aligns) the
APK. The debug APK is auto-signed by the SDK’s debug key, but the
UNIT 2 : ANDROID BUILD PROCESS AND DEVICE ROOTING SILVER OAK UNIVERSITY
Unit 2 : Android Build Process and Device Rooting
release APK must be signed with the developer’s private key before
distribution.
APK Structure
An APK is simply a ZIP-formatted archive (essentially a JAR file with a .apk
extension). You can open it with any ZIP tool to inspect its contents. Key
components inside an APK include:
• [Link] – This binary XML file holds app metadata
(package name, activities, services, permissions, etc.). It is compiled
from a human-readable XML into a binary format, so it’s not directly
readable in raw form.
• [Link] – Contains the app’s Dalvik/ART bytecode (all compiled
code). All Java and Kotlin code ultimately ends up here. (Android apps are
written in Java/Kotlin, compiled to .class, then transformed into this .dex
format for the Android runtime.)
UNIT 2 : ANDROID BUILD PROCESS AND DEVICE ROOTING SILVER OAK UNIVERSITY
Unit 2 : Android Build Process and Device Rooting
• [Link] – A compiled archive of app resources (strings, layouts,
styles, etc.). Many XML resource files are compiled and optimized into
this single binary. (Resources that aren’t compiled into [Link]
remain in the res/ folder.)
• res/ directory – Contains raw resource files (e.g. images, uncompiled
XML in subfolders like layout/, drawable/, values/).
• assets/ directory – Holds raw files bundled with the app, accessible via
AssetManager. These are not given resource IDs; they are loaded by name
at runtime.
• lib/ directory – Contains native libraries (*.so files) compiled for specific
CPU architectures. If the app uses the NDK or other C/C++ code,
compiled libraries go here. Typically you’ll see subfolders like armeabi-
v7a/, arm64-v8a/, x86/, etc. Each subfolder holds .so files for that CPU
ABI. (Developers often publish separate APKs per architecture so each
APK includes only the relevant libraries, reducing size.)
• META-INF/ directory – Contains the digital signature of the APK. It
includes [Link] (listing all files and their hashes), a .SF file (signed
hashes), and a .RSA or .DSA file (the developer’s public key certificate).
This ensures the APK hasn’t been tampered with (Android’s
PackageManager verifies these signatures on install).
Essentially, when you unzip an APK you see files like: [Link],
[Link], [Link], subdirectories res/, assets/, lib/, and META-INF/
(with [Link], [Link], [Link]). The digital signature under META-
INF/ ties it all together – Android will refuse to install an APK if its signature
doesn’t match (for example, after any modification).
UNIT 2 : ANDROID BUILD PROCESS AND DEVICE ROOTING SILVER OAK UNIVERSITY
Unit 2 : Android Build Process and Device Rooting
The standard folder structure of an Android project in Android Studio. At the top
is the Manifests folder, which contains the [Link] file. This file is
essential as it defines the app’s structure and key configurations such as the
app's components (activities, services, etc.), permissions (like internet
access), and metadata required by the Android OS to install and run the app.
The Java folder holds all the source code written in Java or Kotlin. It typically
includes three sections: the main application code, the unit test code (under
the test folder), and instrumentation test code (under androidTest), which is
used for testing on real devices or emulators.
Next, the Resources (res) folder contains all non-code elements used in the
application. This includes images, XML layouts, strings, and more. Inside the
res folder, the Drawable folder contains graphic resources like icons and
images; the Layout folder holds the XML files that define the structure of each
user interface screen; the Mipmap folder is specifically used for storing
launcher icons in multiple screen resolutions; and the Values folder contains
XML files like [Link], [Link], and [Link] that define app-wide
constants and themes.
UNIT 2 : ANDROID BUILD PROCESS AND DEVICE ROOTING SILVER OAK UNIVERSITY
Unit 2 : Android Build Process and Device Rooting
At the bottom of the structure, the Gradle Scripts section includes
configuration files used to automate the build process. These include
[Link] for module-level configurations, [Link] for
defining the Gradle version, [Link] for obfuscation settings,
[Link] for project-level settings, and [Link] which often
contains SDK paths.
Code Signing
Every APK must be digitally signed to be installable. By policy, Android will not
install or update an unsigned app. For development, the build tools
automatically sign debug builds with a shared debug key (not secure for
production). For a release build, you must use the keytool to generate or use
your own keystore (private key) and sign the APK (via jarsigner or Gradle) before
publishing. The certificate ensures app integrity and identity. If you modify an
APK (e.g. during reversing), you have to re-sign it with your own certificate
before installing. Otherwise Android will detect the signature mismatch and
refuse to update over an existing app.
Scheme Introduced In Used For
V1 (JAR Signature) Android 1.0 Signs individual files inside APK (older method)
V2 Android 7.0
Signs the entire APK; faster verification
(Full APK Sign) (Nougat)
Supports key rotation (changing signing keys
V3 Android 9 (Pie)
safely)
Android 10+ Optimized for APK Signature verification before
V4
(for Play Store) installation (used by Google Play only)
UNIT 2 : ANDROID BUILD PROCESS AND DEVICE ROOTING SILVER OAK UNIVERSITY
Unit 2 : Android Build Process and Device Rooting
Reversing APKs
Reverse engineering an APK means unpacking and analyzing it to see its code
and resources. It is commonly done for security auditing or understanding
behavior when source code isn’t available. The process typically involves:
unzipping the APK, decoding resources, and decompiling code. Key tools
include:
• APKTool – Decodes the APK’s resources and manifest into nearly original
form. It converts the binary XML back into readable XML and transforms
[Link] into Smali code (a human-readable assembly language).
This lets you see and edit resources and even rebuild the APK.
• Dex2Jar + JD-GUI – Dex2Jar converts the .dex bytecode back into a Java
.jar file. JD-GUI (or other Java decompiler) can then open that .jar to
display approximated Java source code. This combination can reveal
high-level logic (though obfuscation makes it messy).
• Smali/Baksmali – These are assembler/disassembler for Dalvik
bytecode. If you want to inspect or modify the bytecode directly, you can
use Baksmali to disassemble a .dex into Smali (.smali text files), edit
them, and then reassemble (smali) back into a .dex.
If you repackage or modify an APK, remember to re-sign it (using your own key)
or Android won’t accept it. During reversing one often unpacks (with unzip or
Apktool), inspects code, then rebuilds (with Apktool or baksmali) if needed.
Obfuscation
UNIT 2 : ANDROID BUILD PROCESS AND DEVICE ROOTING SILVER OAK UNIVERSITY
Unit 2 : Android Build Process and Device Rooting
To hinder reverse engineering, Android build tools can obfuscate code. During
a release build, enabling “minify” in Gradle activates the R8 (or older ProGuard)
optimizer. R8/ProGuard will remove unused classes/methods (shrinking the
app) and rename remaining classes, methods, and fields to short, meaningless
names. For example, a method calculateInterest() might become a(). This
makes decompiled code very hard to understand. In short, R8 both optimizes
the bytecode (reducing APK size) and obfuscates it by scrambling identifiers, so
attackers cannot easily follow the app’s logic.
Hardware Optimization and OEM Apps
UNIT 2 : ANDROID BUILD PROCESS AND DEVICE ROOTING SILVER OAK UNIVERSITY
Unit 2 : Android Build Process and Device Rooting
Apps often include hardware-specific optimizations. For instance, the lib/
folder may contain native libraries optimized for specific CPU architectures
(e.g. ARM vs x86). Developers can produce separate APK variants per ABI to
reduce size – each APK then contains only the relevant .so files for that CPU.
Similarly, apps can use GPU acceleration (OpenGL/Vulkan) or special
instruction sets to run faster, though the APK structure is mostly agnostic to
such optimizations.
Finally, note that OEM (manufacturer) apps are often pre-installed on Android
devices (often with privileged permissions). These pre-installed apps (like OEM
utilities, custom settings, or bundled software) run with system-level privileges
that normal downloaded apps lack. Because they are included by the device
maker, they typically cannot be uninstalled by the user (only disabled), and they
can access more sensitive resources. In security terms, these OEM apps are
potential targets for exploits because their code is widely distributed and they
have elevated rights.
Device Rooting
Rooting
Rooting an Android device means gaining full administrative (root) access to
the system. In Unix terms, “root” is the superuser account. On most Android
devices, the OS is locked to prevent normal users from accessing system files.
Rooting breaks those restrictions, letting you modify any file or setting on the
device. (This typically involves unlocking the bootloader and installing su-
binaries or a custom recovery, but the key point is: after rooting you have
equivalent of root privileges on the Android filesystem.) Rooting is similar to
jailbreaking an iPhone: it removes built-in guardrails so the user can change
low-level behavior.
Potential Issues
UNIT 2 : ANDROID BUILD PROCESS AND DEVICE ROOTING SILVER OAK UNIVERSITY
Unit 2 : Android Build Process and Device Rooting
Rooting carries significant risks. Many OEMs will void your warranty once a
root has been applied. It is also quite easy to brick a device (rendering it
inoperable) by making a mistake in rooting or flashing a wrong ROM. Some
hardware features or apps may stop working: for example, banking or payment
apps usually detect tampering and refuse to run on rooted devices. Core
functionality like the camera or fingerprint reader can also malfunction if the
system code is altered.
From a security standpoint, rooting weakens the device’s defenses. Built-in
Android security features (like verified boot and certain sandbox protections)
may be bypassed or disabled on a rooted phone. If root is achieved by disabling
updates, the device might miss critical security patches, leaving it exposed to
malware or exploits. In short, the drawbacks of rooting include lost
functionality, voided warranty, and increased security risk.
Custom ROMs
A common reason people root is to install a custom ROM. A custom ROM is a
complete replacement of the stock Android firmware (often based on AOSP).
After unlocking the bootloader, one can “flash” a custom OS image (ROM) onto
the device. This allows users to remove unwanted vendor apps, get newer
Android versions, or add features not provided by the manufacturer. Popular
custom ROMs include LineageOS (formerly CyanogenMod), which offers a
near-stock Android experience. However, flashing a custom ROM still requires
root-like access: once flashed, the original firmware is overwritten. Like
rooting, installing a custom ROM risks bricking and security issues, and
typically voids the warranty.
Implications of Rooting
UNIT 2 : ANDROID BUILD PROCESS AND DEVICE ROOTING SILVER OAK UNIVERSITY
Unit 2 : Android Build Process and Device Rooting
Root access fundamentally changes the Android trust model. Because the
system runs un-locked, malware or misbehaving apps installed by the user can
potentially gain root and wreak havoc system-wide. For security testing, this
means a rooted device simulates a worst-case scenario where app isolation is
broken. Also, many official services (like Google’s SafetyNet or certain DRM
content) will fail on rooted devices, preventing some apps or payment
services from working. In practice, rooting is generally only used when
necessary, knowing the implications: it removes safeguards and can make the
device effectively “less Android” in terms of security.
Rooting for Testing
Despite its risks, rooting is often done for legitimate development and testing
purposes. Security researchers or QA engineers may root a test device to install
debugging tools, inspect protected data, or simulate attacks that require
privileged access. For example, rooting allows using frameworks like Xposed or
running adb root to explore system processes. In pentesting, a rooted device
can help reveal how an app behaves under compromised conditions. However,
any tests on a rooted device should be carefully controlled – a rooted phone
used for daily life can be far more vulnerable, and many security-sensitive apps
(banking, corporate, etc.) will refuse to run on a rooted device anyway.
Sources: Android documentation and security resources were used to detail
the build steps, APK anatomy, and rooting implications. For example, all APKs
must be signed before installation and reverse-engineering often uses tools like
apktool, dex2jar, JD-GUI, and Smali/Baksmali. The risks of rooting (bricking,
voided warranty, disabled apps, etc.) are likewise documented.
UNIT 2 : ANDROID BUILD PROCESS AND DEVICE ROOTING SILVER OAK UNIVERSITY