Build Type — apa itu, konfigurasi debug dan release di Gradle

Apa itu Build Type?

Build Type adalah elemen konfigurasi Gradle proyek Android yang menjelaskan parameter kompilasi dan pengemasan aplikasi. Setiap Build Type adalah kumpulan opsi bernama: debuggable (mengaktifkan debugging), minificationEnabled (mengaktifkan kompresi kode), shrinkResources (mengaktifkan kompresi sumber daya), proguardFiles (file aturan ProGuard), signingConfig (sertifikat penandatanganan) dan lainnya. Build Types dideklarasikan dalam blok android.buildTypes file build.gradle modul app.

Tugas utama Build Type adalah memisahkan development workflow (build cepat, log detail, debugging) dan production release (kode yang dioptimalkan, ukuran minimal, keamanan). Build debug harus dibangun dalam hitungan detik dan memberikan informasi maksimal kepada pengembang. Build release harus secepat dan sekompak mungkin untuk pengguna. Build Type adalah konfigurasi infrastruktur yang tidak terkait dengan fungsionalitas aplikasi.

Android Gradle Plugin secara otomatis membuat source set untuk setiap Build Type — direktori src/<buildType>/ (misalnya src/debug/, src/release/). Dalam source set ini dapat ditempatkan sumber daya, kode dan manifes yang hanya akan diterapkan untuk jenis build tersebut. Misalnya, di src/debug/ dapat ditempatkan AndroidManifest.xml dengan izin instalasi dari ADB, dan di src/release/ — tanpa. Source set Build Type memiliki prioritas di atas source set Product Flavor.

Build Type vs Product Flavor

Perbedaan utama: Build Type menjawab pertanyaan “bagaimana membangun?”, dan Product Flavor — pertanyaan “apa yang dibangun?”. Build Type bisa debug, release, staging. Product Flavor bisa free, paid, enterprise. Build Type tidak mengubah fungsionalitas aplikasi (tidak menambah atau menghapus layar), Product Flavor — mengubah. Build Type dapat menonaktifkan debugger dan mengaktifkan obfuscation, Product Flavor dapat mengubah applicationId dan sumber daya. Keduanya bekerja berpasangan: setiap Build Type dikombinasikan dengan setiap Product Flavor, membentuk Build Variant.

Build Types standar: debug dan release

Debug adalah Build Type yang dibuat secara default oleh AGP. Ini menyertakan debuggable=true, yang memungkinkan menghubungkan debugger, melihat log Log.d dan menggunakan profiler Android Studio. Minification dinonaktifkan, sehingga build cepat. Dalam build debug, applicationId mendapatkan sufiks “.debug” (jika tidak ditimpa), yang memungkinkan menginstal versi debug secara paralel dengan versi release di perangkat yang sama. Debug ditandatangani dengan sertifikat dari debug.keystore, yang dibuat secara otomatis oleh Android SDK.

Release adalah Build Type untuk publikasi aplikasi. debuggable=false, minificationEnabled=true (default), shrinkResources=true. Pengembang harus menentukan signingConfig dengan sertifikat produksi — jika tidak, build tidak akan dianggap release. Release menggunakan ProGuard atau R8 untuk obfuscation, optimasi dan kompresi kode. Android Studio tidak dapat menghubungkan debugger ke build release (jika debuggable=false). Semua panggilan Log.d dan Log.v dihapus dari kode pada tahap minification, jika aturan ProGuard yang sesuai telah dikonfigurasi.

Penting: build debug tidak menguji perilaku release. Minification dapat mengubah perilaku kode — reflection, serialisasi, Gson/SQLite dan pustaka lain sering memerlukan aturan ProGuard. Oleh karena itu, sebelum publikasi, Anda harus membuat dan menguji build release. Google Play Console dan Firebase Test Lab memungkinkan mengunggah build release untuk pengujian otomatis pada perangkat nyata sebelum publikasi.

android {
    buildTypes {
        debug {
            debuggable true
            minification false
            signingConfig signingConfigs.debug
            versionNameSuffix "-debug"
        }

        release {
            debuggable false
            minification true
            shrinkResources true
            proguardFiles "proguard-rules.pro"
            signingConfig signingConfigs.release
            ndk { abiFilters "arm64-v8a", "x86_64" }
        }
    }
}

Membuat Build Types kustom

Pewarisan melalui initWith

Selain debug dan release, Anda dapat membuat Build Types kustom — misalnya staging (lingkungan perantara) atau benchmark (untuk pengujian kinerja). Build Type kustom dideklarasikan dalam blok buildTypes seperti debug dan release. Nama dapat berupa apa saja, tetapi disarankan menggunakan nama yang bermakna secara semantik dalam bahasa Inggris. Untuk staging biasanya diatur debuggable=true (untuk diagnosa masalah di lingkungan staging) dan minification=true (untuk menguji obfuscation sebelum produksi).

Build Type kustom secara otomatis mendapatkan source set yang sesuai (src/staging/) dan menghasilkan tugas seperti assembleStaging. AGP tidak memberlakukan batasan pada jumlah jenis kustom, tetapi setiap jenis baru melipatgandakan jumlah Build Variants. Batas praktis adalah 4-5 Build Types: debug, staging, benchmark, release dan mungkin debugMinified (debug dengan minification diaktifkan untuk menguji aturan ProGuard).

Untuk Build Type kustom, debuggable dapat diwarisi dari debug menggunakan initWith. Kata kunci initWith menyalin semua parameter Build Type yang ditentukan, setelah itu dapat ditimpa. Ini berguna untuk membuat staging berdasarkan debug: initWith debug + tambahan mengaktifkan minification. Tanpa initWith, Anda harus menyebutkan semua parameter tipe dasar secara manual.

android {
    buildTypes {
        staging {
            initWith debug
            minification true
            shrinkResources true
            proguardFiles "staging-proguard-rules.pro"
            versionNameSuffix "-staging"
        }

        benchmark {
            initWith release
            signingConfig signingConfigs.debug
            matchingFallbacks = ["release"]
        }
    }
}

// matchingFallbacks — untuk pustaka yang tidak memiliki jenis benchmark
// jika pustaka hanya memiliki release — AGP menggunakannya

Konfigurasi penandatanganan untuk berbagai jenis build

SigningConfig menentukan dengan sertifikat apa APK atau AAB ditandatangani. Android memerlukan penandatanganan semua aplikasi yang dapat diinstal — tanpa itu, sistem tidak akan mengizinkan instalasi APK. Untuk build debug, AGP menggunakan debug.keystore — sertifikat yang sudah diinstal sebelumnya dengan kata sandi yang diketahui, yang dihasilkan oleh Android SDK Tools. Untuk build release, Anda harus membuat sertifikat sendiri melalui Android Studio (Build → Generate Signed Bundle/APK) atau dengan perintah keytool.

Penyimpanan kunci penandatanganan adalah aspek keamanan yang kritis. Disarankan tidak menyimpan kunci release di repositori kode sumber. Sebagai gantinya, digunakan: file keystore.properties (ditambahkan ke .gitignore), variabel lingkungan CI/CD, atau penyimpanan terenkripsi Android Studio. Di CI/CD (GitHub Actions, GitLab CI), kunci penandatanganan disimpan di secrets dan diteruskan ke build.gradle melalui properti sistem. Contoh: storePassword = System.getenv("KEYSTORE_PASSWORD").

Setiap Build Type dapat merujuk ke signingConfig sendiri. Untuk release — sertifikat produksi, untuk debug — debug.keystore, untuk staging — sertifikat staging terpisah. Konfigurasi penandatanganan secara langsung mempengaruhi kemungkinan instalasi aplikasi: jika debug ditandatangani dengan debug.keystore, dan staging dengan kunci produksi, staging tidak dapat diinstal di atas versi debug karena ketidakcocokan tanda tangan. ApplicationId juga harus berbeda — untuk ini digunakan applicationIdSuffix.

android {
    signingConfigs {
        debug {
            storeFile file("debug.keystore")
            storePassword "android"
            keyAlias "androiddebugkey"
            keyPassword "android"
        }
        release {
            storeFile file("release-key.jks")
            storePassword System.getenv("KEYSTORE_PASS")
            keyAlias "my-key"
            keyPassword System.getenv("KEY_PASS")
        }
    }

    buildTypes {
        release {
            signingConfig signingConfigs.release
        }
    }
}

Minification, ProGuard dan R8

Resource Shrinking

Minification adalah proses menghapus kode yang tidak digunakan dan mengganti nama kelas, metode dan field dengan nama pendek. AGP menjalankan minification menggunakan ProGuard (usang) atau R8 (direkomendasikan, terintegrasi dalam AGP sejak versi 3.4). R8 melakukan empat operasi: shrinking (menghapus kelas yang tidak digunakan), optimisation (menyederhanakan kode), obfuscation (mengganti nama) dan preverify (menambahkan informasi kompatibilitas). Hasilnya — APK dengan ukuran lebih kecil yang lebih sulit didekompilasi.

Aturan minification didefinisikan dalam ProGuard rules files — file teks dengan sintaks -keep, -dontwarn, -keepclassmembers. Tanpa aturan, R8 akan menghapus atau mengganti nama kelas yang digunakan melalui reflection (Gson, Retrofit, Room, Kotlin serialization). Template proyek Android Studio membuat proguard-rules.pro, di mana aturan untuk pustaka tertentu ditambahkan. Pustaka juga dapat berisi aturan bawaan — aturan tersebut secara otomatis dihubungkan dari jar/aar.

Shrink resources (shrinkResources=true) menghapus sumber daya yang tidak digunakan dari APK. R8 pertama menentukan sumber daya mana yang tidak digunakan dalam kode (memeriksa R.java dan referensi di manifes), kemudian menghapusnya dari build final. Untuk sumber daya yang digunakan melalui getIdentifier() atau oleh pustaka pihak ketiga, perlu ditambahkan tools:keep="@layout/my_layout" di sumber daya. Dalam kombinasi dengan minification, resource shrinking dapat mengurangi ukuran APK sebesar 40-60%.

# proguard-rules.pro — aturan wajib
# Gson: pertahankan kelas untuk serialisasi
-keepclassmembers class com.example.** {
    <fields>;
}

# Retrofit: pertahankan antarmuka API
-keep,allowobfuscation interface com.example.api.*

# Room: pertahankan DAO dan Entity
-keep class * extends androidx.room.RoomDatabase
-keep @interface androidx.room.** { *; }

# Kotlin Coroutines: cegah penghapusan Continuation
-keepnames class kotlinx.coroutines.internal.*

# OkHttp: pertahankan service loader
-keep class okhttp3.** { *; }

BuildConfigField dan sumber daya untuk Build Type

BuildConfig adalah kelas Java/Kotlin yang dihasilkan secara otomatis yang berisi konstanta yang didefinisikan dalam defaultConfig, productFlavors dan buildTypes. Melalui buildConfigField dapat ditambahkan field kustom: buildConfigField "String", "API_URL", '"https://api.example.com"'. BuildConfigField yang dideklarasikan dalam buildType tersedia di semua varian jenis ini. Nilai dalam buildType menimpa nilai dari productFlavor, yang pada gilirannya menimpa defaultConfig.

Untuk build debug, mudah untuk mengatur API_URL ke localhost atau server staging, dan untuk release — ke production. BuildConfig.FLAVOR dan BuildConfig.BUILD_TYPE juga dihasilkan secara otomatis dan berisi nama flavor dan build type saat ini. Dalam kode dapat digunakan: if (BuildConfig.DEBUG) { /* log */ } — konstanta DEBUG hanya true untuk build type debug. BuildConfig.DEBUG adalah field standar yang ditambahkan AGP ke setiap BuildConfig.

Sumber daya untuk Build Type didefinisikan melalui source set src/<buildType>/res/. Misalnya, src/debug/res/values/strings.xml dapat berisi teks “Server: Dev”, dan src/release/res/ — “Server: Prod”. Sumber daya manifes juga ditimpa melalui source set: src/debug/AndroidManifest.xml dapat menyertakan <uses-permission android:name="android.permission.INTERNET" /> hanya untuk build debug. Ini lebih bersih daripada pemeriksaan BuildConfig dalam kode dan berfungsi bahkan untuk atribut yang tidak dapat diatur secara terprogram (misalnya networkSecurityConfig).

// src/debug/kotlin/.../DebugConfig.kt
object DebugConfig {
    val apiUrl = "http://localhost:8080/api"
    val enableLogging = true
    val enableCrashReporting = false
}

// src/release/kotlin/.../ReleaseConfig.kt
object ReleaseConfig {
    val apiUrl = "https://api.production.com/v2"
    val enableLogging = false
    val enableCrashReporting = true
}

// Penggunaan: kelas utama memuat Config melalui reflection
fun getConfig(): AppConfig = when (BuildConfig.BUILD_TYPE) {
    "debug" -> DebugConfig
    else -> ReleaseConfig
}