Understanding the Structure of an Android Project
When starting with Android app development, it’s essential to understand the structure of an Android project. Here's a breakdown of the typical directory and file structure:
project/
├── app/
│ ├── build/
│ ├── src/
│ │ ├── main/
│ │ │ ├── java/com/example/app/
│ │ ┒ ├── res/
│ │ ┒ ┒ ├── drawable/
│ │ ┒ ┒ ├── layout/
│ │ ┒ ┒ ├── values/
│ │ ┒ ┒ ├── mipmap/
│ │ ┒ ┒ ├── raw/
│ │ ├── AndroidManifest.xml
│ ┒ ├── test/
│ ┒ ├── androidTest/
│ ├── build.gradle
│
├── build/
├── gradle/
├── settings.gradle
├── build.gradle
├── gradlew
├── gradlew.bat
└── local.properties
Breakdown of Directories and Files
app/
This is the primary module containing the app’s source code and resources.
src/
main/: The main source set for the app.
java/: Contains the Java/Kotlin source files organized by package structure (e.g., com.example.app).
res/: Contains all the app’s resources, such as layouts, drawables, and strings.
drawable/: Holds drawable resources such as images or XML-based vector assets.
layout/: Contains UI layout files in XML format.
values/: Holds resource files like strings.xml, styles.xml, and colors.xml.
mipmap/: Stores launcher icons for various screen densities.
raw/: Contains raw assets like audio or video files.
anim/: Stores animation XML files.
menu/: Contains XML resources for menus.
color/: XML files defining color resources.
xml/: Contains custom XML configuration files.
assets/: Stores raw files such as fonts or JSON files to be included in the app.
AndroidManifest.xml: The manifest file declaring app components, permissions, and configurations.
test/: Contains unit test files.
androidTest/: Contains instrumentation test files for testing app functionality on devices.
build/: Holds build outputs and intermediate files for the app module.
build.gradle: Module-level build configuration, defining dependencies, build types, and variants.
build/
This directory contains build outputs and intermediate files generated during the build process.
gradle/
Holds Gradle’s wrapper configuration files.
.gradle/
Caches for the Gradle build system to improve build speed and efficiency.
settings.gradle
Defines the project’s structure and modules. Typically lists the app module and other included modules.
build.gradle (Project-level)
Specifies global configurations, such as dependency repositories, plugins, and build script dependencies.
gradlew and gradlew.bat
Scripts to execute the Gradle wrapper. gradlew is for Unix-based systems, and gradlew.bat is for Windows.
local.properties
Contains local configurations, such as the path to the Android SDK, and is not included in version control.
Steps to Decompile an Android App
Before understanding the structure of decompiled files from an APK, we have to know that we can decompile an APK using below command, which can be downloaded from here.
apktool.jar d <app-name>.apk
- Replace
<app-name> with the actual name of the APK file.
Below is the structure we get after decompiling the app using APKTool:
decompiled_app/
├── AndroidManifest.xml
├── apktool.yml
├── assets/
│ ├── fonts/
│ ├── data.json
│ ├── ...
├── lib/
│ ├── armeabi/
│ ├── armeabi-v7a/
│ ├── arm64-v8a/
│ ├── x86/
│ ├── x86_64/
├── original/
│ ├── AndroidManifest.xml
│ ├── ...
├── res/
│ ├── drawable/
│ ├── layout/
│ ├── values/
│ ├── mipmap/
│ ├── anim/
│ ├── raw/
│ ├── ...
├── smali/
│ ├── com/
│ │ ├── example/
│ │ │ ├── app/
│ │ │ ├── utils/
├── smali_classes2/ (if multidex)
├── smali_classes3/ (if multidex)
└── unknown/
├── file1.dat
├── ...
Key Components
original/
smali/
Contains the app's code in smali format, a human-readable representation of the Dalvik bytecode.
Organized by package structure:
smali/com/example/app/
smali/com/example/utils/
If the app is multidex, you may see:
smali_classes2/
smali_classes3/
res/
Decompiled resources such as layouts, drawables, and values.
Subdirectories:
drawable/: Image resources.
layout/: UI layout XML files.
values/: Strings, styles, and other resource XMLs.
raw/: Raw files like audio, video, etc.
menu/: Menu XML resources.
These files are in their decoded form and can be modified directly.
assets/
Raw asset files included in the app.
These are not compiled and remain in their original form.
Examples: Fonts, JSON files, text files, etc.
lib/
AndroidManifest.xml
The decoded version of the app’s manifest file.
Contains permissions, components (activities, services, etc.), and other configuration details in readable XML format.
apktool.yml
Metadata for APKTool.
Includes information about the APK being decompiled, such as the original package name, version, and other build settings.
Example:
version: 1
apkFileName: app-release.apk
isFrameworkApk: false
sdkInfo:
minSdkVersion: 21
targetSdkVersion: 33
unknown/ (Optional)
Comparison: Android Project vs. Decompiled APK
| Feature | Android Project | Decompiled APK |
| Source Code | Written in Java/Kotlin | Decompiled to Smali |
| Resources | Organized and human-readable | Decoded but may lose some metadata |
| Manifest | Editable XML | Decompiled and may contain obfuscations |
| Build Files | Gradle scripts for configuration | Absent |
| Native Libraries | Part of jniLibs or external dependencies | Extracted into lib/ directory |
| Assets | Organized in assets/ | Directly copied |
| Debug Info | Available (if project is debug-enabled) | Minimal or absent |
Understanding both structures is vital for reverse engineering, debugging, or performing penetration tests on Android apps.
