Understanding the Differences: Android Project and Decompiled APK Structures Explained

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.

Structure After Decompiling with APKTool

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/

  • Contains original files that were not modified during the decoding process.

  • Examples:

    • AndroidManifest.xml (binary version).

    • Other untouched files from the original APK.

• 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/

  • Contains native libraries included in the APK.

  • Organized by CPU architecture:

    • armeabi/

    • armeabi-v7a/

    • arm64-v8a/

    • x86/

    • x86_64/

• 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)

  • Contains files that APKTool could not decode or place into other directories.

  • Often includes additional or custom data files used by the app.

Comparison: Android Project vs. Decompiled APK

Understanding both structures is vital for reverse engineering, debugging, or performing penetration tests on Android apps.