Build Type — nedir, Gradle'da debug ve release yapılandırması

Build Type Nedir?

Build Type, Android projelerinde Gradle yapılandırmasının bir öğesidir ve uygulamanın derleme ve paketleme parametrelerini tanımlar. Her Build Type, adlandırılmış bir seçenek kümesidir: debuggable (hata ayıklamayı etkinleştir), minificationEnabled (kod sıkıştırmasını etkinleştir), shrinkResources (kaynak sıkıştırmasını etkinleştir), proguardFiles (ProGuard kural dosyaları), signingConfig (imza sertifikası) ve diğerleri. Build Types, app modülünün build.gradle dosyasının android.buildTypes bloğunda bildirilir.

Build Type'ın temel görevi, geliştirme iş akışını (hızlı derleme, ayrıntılı günlükler, hata ayıklama) üretim sürümünden (optimize edilmiş kod, minimum boyut, güvenlik) ayırmaktır. Debug derlemesi saniyeler içinde derlenmeli ve geliştiriciye maksimum bilgi sağlamalıdır. Release derlemesi, kullanıcılar için mümkün olduğunca hızlı ve kompakt olmalıdır. Build Type, uygulamanın işlevselliğiyle ilgili olmayan bir altyapı ayarıdır.

Android Gradle Plugin, her Build Type için otomatik olarak bir source set oluşturur — src/<buildType>/ dizini (örneğin, src/debug/, src/release/). Bu source set'e yerleştirilen kaynaklar, kod ve manifest dosyaları yalnızca bu derleme türü için geçerlidir. Örneğin, src/debug/ içine ADB'den kurulum izni olan bir AndroidManifest.xml yerleştirilebilirken, src/release/ içine izinsiz yerleştirilebilir. Build Type source set'i, Product Flavor source set'ine göre önceliklidir.

Build Type ve Product Flavor Arasındaki Fark

Temel fark: Build Type "nasıl derlenir?" sorusuna yanıt verirken, Product Flavor "ne derlenir?" sorusuna yanıt verir. Build Type debug, release, staging olabilir. Product Flavor free, paid, enterprise olabilir. Build Type uygulamanın işlevselliğini değiştirmez (ekran eklemez veya kaldırmaz), Product Flavor değiştirir. Build Type hata ayıklayıcıyı devre dışı bırakabilir ve karartmayı etkinleştirebilir, Product Flavor applicationId ve kaynakları değiştirebilir. İkisi birlikte çalışır: her Build Type, her Product Flavor ile birleştirilerek Build Variant oluşturur.

Standart Build Types: debug ve release

Debug, AGP tarafından varsayılan olarak oluşturulan Build Type'dır. debuggable=true olup hata ayıklayıcı bağlamaya, Log.d günlüklerini görüntülemeye ve Android Studio profilleyicisini kullanmaya olanak tanır. Minification devre dışıdır, bu nedenle derleme hızlıdır. Bir debug derlemesinde applicationId ".debug" sonekini alır (geçersiz kılınmadıysa), böylece debug sürümü aynı cihazda release sürümüyle yan yana kurulabilir. Debug derlemesi, Android SDK tarafından otomatik olarak oluşturulan debug.keystore'daki bir sertifikayla imzalanır.

Release, uygulamayı yayınlamak için kullanılan Build Type'dır. debuggable=false, minificationEnabled=true (varsayılan), shrinkResources=true. Geliştirici, bir üretim sertifikasıyla signingConfig belirtmelidir — aksi takdirde derleme release olarak kabul edilmez. Release derlemesi, karartma, optimizasyon ve kod sıkıştırması için ProGuard veya R8 kullanır. Android Studio, bir release derlemesine hata ayıklayıcı bağlayamaz (debuggable=false ise). Uygun ProGuard kuralları yapılandırılmışsa, minification sırasında tüm Log.d ve Log.v çağrıları koddan kaldırılır.

Önemli: debug derlemeleri release davranışını test etmez. Minification, kod davranışını değiştirebilir — yansıma, serileştirme, Gson/SQLite ve diğer kitaplıklar genellikle ProGuard kuralları gerektirir. Bu nedenle, yayınlamadan önce her zaman bir release derlemesi oluşturun ve test edin. Google Play Console ve Firebase Test Lab, yayınlamadan önce gerçek cihazlarda otomatik test için release derlemeleri yüklemeye olanak tanır.

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" }
        }
    }
}

Özel Build Types Oluşturma

initWith ile Kalıtım

Debug ve release'e ek olarak, özel Build Types oluşturulabilir — örneğin staging (ara ortam) veya benchmark (performans testleri için). Özel bir Build Type, debug ve release ile aynı şekilde buildTypes bloğunda bildirilir. Adı herhangi bir şey olabilir, ancak İngilizce anlamsal olarak net adlar kullanılması önerilir. Staging için genellikle debuggable=true (staging ortamındaki sorunları teşhis etmek için) ve minification=true (üretimden önce karartmayı test etmek için) ayarlanır.

Özel bir Build Type otomatik olarak karşılık gelen bir source set (src/staging/) alır ve assembleStaging gibi görevler oluşturur. AGP, özel türlerin sayısına sınırlama getirmez, ancak her yeni tür Build Variants sayısını çarpar. Pratik sınır 4-5 Build Types'dır: debug, staging, benchmark, release ve muhtemelen debugMinified (ProGuard kurallarını test etmek için minification etkinleştirilmiş debug).

Özel bir Build Type için initWith kullanarak debug'dan debuggable özelliğini devralabilirsiniz. initWith anahtar sözcüğü, belirtilen Build Type'ın tüm parametrelerini kopyalar ve ardından bunlar geçersiz kılınabilir. Bu, debug'a dayalı staging oluşturmak için kullanışlıdır: initWith debug + ek olarak minification'ı etkinleştirme. initWith olmadan, temel türün tüm parametrelerini manuel olarak listelemeniz gerekirdi.

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 — benchmark türü olmayan kitaplıklar için
// kitaplık yalnızca release'e sahipse — AGP onu kullanır

Farklı Derleme Türleri İçin İmza Yapılandırması

SigningConfig, APK veya AAB'yi imzalamak için hangi sertifikanın kullanılacağını belirler. Android, yüklenebilir tüm uygulamaların imzalanmasını gerektirir — aksi takdirde sistem kuruluma izin vermez. Debug derlemeleri için AGP, debug.keystore'u kullanır — Android SDK Tools tarafından oluşturulan bilinen bir parolaya sahip önceden yüklenmiş bir sertifika. Release derlemeleri için Android Studio (Build → Generate Signed Bundle/APK) veya keytool komut satırı aracılığıyla kendi sertifikanızı oluşturmalısınız.

İmza anahtarlarının saklanması kritik bir güvenlik konusudur. Release anahtarlarının kaynak kodu deposunda saklanmaması önerilir. Bunun yerine, bir keystore.properties dosyası (.gitignore'a eklenmiş), CI/CD ortam değişkenleri veya Android Studio'nun şifrelenmiş deposu kullanılır. CI/CD'de (GitHub Actions, GitLab CI), imza anahtarları secrets'ta saklanır ve sistem özellikleri aracılığıyla build.gradle'a iletilir. Örnek: storePassword = System.getenv("KEYSTORE_PASSWORD").

Her Build Type kendi signingConfig'ine başvurabilir. Release için — üretim sertifikası, debug için — debug.keystore, staging için — ayrı bir staging sertifikası. İmza yapılandırması, uygulamanın kurulabilirliğini doğrudan etkiler: debug'u debug.keystore ile ve staging'i bir üretim anahtarıyla imzalarsanız, imzalar uyuşmadığı için staging debug sürümünün üzerine kurulamaz. ApplicationId de farklı olmalıdır — bunun için applicationIdSuffix kullanın.

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 ve R8

Resource Shrinking

Minification, kullanılmayan kodu kaldırma ve sınıfları, yöntemleri ve alanları kısa adlarla yeniden adlandırma işlemidir. AGP, ProGuard (eski) veya R8 (önerilen, AGP sürüm 3.4'ten itibaren yerleşik) ile minification gerçekleştirir. R8 dört işlem yapar: shrinking (kullanılmayan sınıfları kaldırma), optimisation (kodu basitleştirme), obfuscation (yeniden adlandırma) ve preverify (uyumluluk bilgisi ekleme). Sonuç, daha küçük ve derlemesi daha zor bir APK'dır.

Minification kuralları, ProGuard kural dosyalarında tanımlanır — -keep, -dontwarn, -keepclassmembers gibi sözdizimine sahip metin dosyaları. Kurallar olmadan R8, yansıma (Gson, Retrofit, Room, Kotlin serileştirme) yoluyla kullanılan sınıfları kaldıracak veya yeniden adlandıracaktır. Android Studio proje şablonu, belirli kitaplıklar için kuralların eklendiği bir proguard-rules.pro dosyası oluşturur. Kitaplıklar ayrıca yerleşik kurallar içerebilir — jar/aar'dan otomatik olarak dahil edilirler.

Shrink resources (shrinkResources=true), APK'dan kullanılmayan kaynakları kaldırır. R8 önce kodda hangi kaynakların kullanılmadığını belirler (R.java ve manifest referanslarını kontrol eder) ve ardından bunları son derlemeden kaldırır. getIdentifier() veya üçüncü taraf kitaplıklar aracılığıyla kullanılan kaynaklar için kaynaklara tools:keep="@layout/my_layout" eklemeniz gerekir. Minification ile birleştirildiğinde, resource shrinking APK boyutunu %40-60 oranında azaltabilir.

# proguard-rules.pro — zorunlu kurallar
# Gson: serileştirme için sınıfları koru
-keepclassmembers class com.example.** {
    <fields>;
}

# Retrofit: API arayüzlerini koru
-keep,allowobfuscation interface com.example.api.*

# Room: DAO ve Entity'yi koru
-keep class * extends androidx.room.RoomDatabase
-keep @interface androidx.room.** { *; }

# Kotlin Coroutines: Continuation'ın kaldırılmasını önle
-keepnames class kotlinx.coroutines.internal.*

# OkHttp: service loader'ı koru
-keep class okhttp3.** { *; }

BuildConfigField ve Build Type için Kaynaklar

BuildConfig, defaultConfig, productFlavors ve buildTypes içinde tanımlanan sabitleri içeren otomatik oluşturulan bir Java/Kotlin sınıfıdır. buildConfigField aracılığıyla özel alanlar eklenebilir: buildConfigField "String", "API_URL", '"https://api.example.com"'. BuildType içinde bildirilen bir BuildConfigField, bu türün tüm varyantlarında kullanılabilir. BuildType içindeki değerler, productFlavor'daki değerleri geçersiz kılar ve productFlavor da defaultConfig'i geçersiz kılar.

Debug derlemeleri için API_URL'yi localhost veya staging sunucusuna, release için ise üretime ayarlamak uygundur. BuildConfig.FLAVOR ve BuildConfig.BUILD_TYPE da otomatik olarak oluşturulur ve geçerli flavor ve build type adını içerir. Kodda şu şekilde kullanılabilir: if (BuildConfig.DEBUG) { /* günlükler */ } — DEBUG sabiti yalnızca debug build type için true'dur. BuildConfig.DEBUG, AGP'nin her BuildConfig'a eklediği standart bir alandır.

Build Type için kaynaklar, src/<buildType>/res/ source set'i aracılığıyla tanımlanır. Örneğin, src/debug/res/values/strings.xml "Server: Dev" dizesini içerebilirken, src/release/res/ "Server: Prod" içerebilir. Manifest kaynakları da source set aracılığıyla geçersiz kılınır: src/debug/AndroidManifest.xml, yalnızca debug derlemeleri için <uses-permission android:name="android.permission.INTERNET" /> içerebilir. Bu, kodda BuildConfig'i kontrol etmekten daha temizdir ve programlı olarak ayarlanamayan öznitelikler (networkSecurityConfig gibi) için bile çalışır.

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

// Kullanım: ana sınıf, yansıma yoluyla Config'i yükler
fun getConfig(): AppConfig = when (BuildConfig.BUILD_TYPE) {
    "debug" -> DebugConfig
    else -> ReleaseConfig
}