Build Process - Vadym-Popovych24/Template GitHub Wiki
This document describes the Android build process implemented in the Template repository. It explains how source code is transformed into a final APK (Android Package), covering the build configuration files, build phases, and customization options. For information about the overall component structure of an Android application, see Component Structure, and for resource organization details, see Resource Organization.
The Android build system is based on Gradle and uses several configuration files to define how the application is built.
In a standard Android project template, the following configuration files control the build process:
File | Purpose |
settings.gradle | Defines which modules are included in the build |
build.gradle (Project-level) | Contains build configurations applied to all modules |
build.gradle (Module-level) | Contains build configurations specific to each module |
gradle.properties | Contains project-wide gradle settings |
AndroidManifest.xml | Defines essential app information required during build |
The build process transforms your project from source code to an installable Android package (APK) through several distinct phases.
During this phase, the Java or Kotlin compiler converts your source code into DEX (Dalvik Executable) bytecode that can run on Android devices.
The Android Asset Packaging Tool (AAPT2) processes and compiles resources into a format that can be efficiently accessed at runtime:
- Compiles resources into a binary format
- Generates the R.java file with resource IDs
- Creates resource tables for different configurations
The Java bytecode from compiled source classes and libraries is converted into DEX files, which contain bytecode that runs on the Android Runtime (ART).
All compiled code, processed resources, and assets are packaged into an Android Package (APK) file.
The APK is signed using the keystore configured in the build process:
- Debug builds use an automatically generated debug key
- Release builds require a specified signing configuration
The final APK is optimized using the zipalign tool, which aligns uncompressed data on 4-byte boundaries to improve runtime memory usage and performance.
Build variants allow you to create different versions of your application from a single codebase. The Template project contains dev and prod versions, the example below contains free and paid as an example.
Build types define certain build properties, typically differentiating between development and distribution builds.
Common build types:
Build Type | Purpose | Typical Settings |
debug | Development builds | Debugging enabled, no obfuscation, signed with debug key |
release | Production builds | Debugging disabled, obfuscation enabled, requires specified signing config |
In a module's build.gradle file, build types would typically be defined as:
android {
buildTypes {
debug {
// Debug-specific configuration
debuggable true
minifyEnabled false
}
release {
// Release-specific configuration
minifyEnabled true
shrinkResources true
proguardFiles getDefaultProguardFile('proguard-android-optimize.txt'), 'proguard-rules.pro'
}
}
}
Product flavors define different versions of your application that you might want to release to users, such as free and paid versions.
In a module's build.gradle file, product flavors could be defined as:
android {
flavorDimensions "monetization"
productFlavors {
free {
dimension "monetization"
// Free version configuration
}
paid {
dimension "monetization"
// Paid version configuration
}
}
}
The build process is executed through Gradle tasks, which can be run from the command line or through Android Studio.
Common Gradle tasks include:
Task | Description |
---|---|
./gradlew build | Builds all build variants |
./gradlew clean | Deletes all build directories |
./gradlew assembleDebug | Assembles the debug APK |
./gradlew assembleRelease | Assembles the release APK |
./gradlew installDebug | Builds and installs the debug APK on a connected device |
./gradlew test | Runs unit tests |
./gradlew connectedAndroidTest | Runs instrumented tests on a connected device |
The Template repository likely provides a foundation for customizing the build process to meet specific project requirements.
Common customizations include:
1. Application version management
android {
defaultConfig {
versionCode 1
versionName "1.0.0"
}
}
2. Custom signing configurations
android {
signingConfigs {
release {
storeFile file("release.keystore")
storePassword "password"
keyAlias "alias"
keyPassword "password"
}
}
}
3. Custom Gradle tasks
task copyAssets(type: Copy) {
from 'src/main/assets'
into 'build/intermediates/assets'
}
preBuild.dependsOn(copyAssets)
When using this Template in a CI/CD environment, you may need to configure additional build settings.
Consideration | Implementation |
---|---|
Automated Versioning | Use build number from CI system for versionCode |
Secret Management | Store signing keys securely in CI environment variables |
Build Caching | Configure Gradle build cache to speed up builds |
Parallel Execution | Enable parallel execution with org.gradle.parallel=true |
Test Automation | Configure test execution and reporting |
The build process within the Template repository follows the standard Android build system patterns based on Gradle. While the provided repository contains minimal configuration as shown in the README.md, the documentation above outlines the expected build process that would be implemented in this template and can be customized for specific project needs.