BuildConfig nedir ve projede nasıl uygulanır?

Kerem Aydın·7 Temmuz 2026·⏱3 dk

BuildConfig, Android'de Gradle tarafından otomatik olarak oluşturulan ve derleme sabitlerini (sürümler, debug bayrakları, URL'ler, anahtarlar) saklayan bir sınıftır; hardcode yapmadan debug/release/flavor'a göre değerleri değiştirmenize olanak tanır. Aşağıda alanların nasıl tanımlanacağı, nerede saklanacağı ve kodda güvenli bir şekilde nasıl kullanılacağı açıklanmaktadır.

BuildConfig ne içerir ve neden gereklidir?

BuildConfig derleme sırasında oluşturulur ve şunları içerir:

BuildConfig.DEBUG — debug derlemeleri için otomatik olarak true olur.
build.gradle'den gelen sabitler: buildConfigField("String", "API_URL", ""https://..."").
Sürümler, bayraklar, özellik bayrakları ve buildType veya flavor'a bağlı değerler.

Neden kullanmalısınız:

Yapılandırmaya tür güvenliği sağlayan erişim (derleyici türleri kontrol eder).
Kodda koşullu ifadeler olmadan debug/release/staging için farklı değerler.
CI/CD ile kolay entegrasyon (Gradle'da ortam değişkenlerinin yerleştirilmesi).

Gizli bilgileri depo dışında saklayın (local.properties veya gradle.properties) ve bunları properties aracılığıyla buildConfigField içine yerleştirin; bu sayede sızıntı riskini azaltırsınız.

BuildConfig nasıl tanımlanır ve oluşturulur?

Groovy DSL'de (build.gradle):

android {
  defaultConfig {
    applicationId "com.example.app"
    buildConfigField "String", "API_URL", "\"https://api.example.com\""
  }
  buildTypes {
    debug {
      buildConfigField "boolean", "ENABLE_LOGGING", "true"
    }
    release {
      buildConfigField "boolean", "ENABLE_LOGGING", "false"
      minifyEnabled true
    }
  }
}

Kotlin DSL'de (build.gradle.kts):

android {
  defaultConfig {
    buildConfigField("String", "APP_VERSION", "\"${versionName}\"")
    buildConfigField("String", "API_KEY", "\"${properties["apiKey"] ?: ""}\"")
  }
  buildTypes {
    debug {
      buildConfigField("boolean", "ENABLE_LOGGING", "true")
    }
    release {
      buildConfigField("boolean", "ENABLE_LOGGING", "false")
    }
  }
}

./gradlew clean assemble komutundan sonra sınıf build/generated/source/buildConfig/... dizininde görünür. İçe aktarma: import com.yourapp.BuildConfig

Gerçek anahtarları içeren local.properties dosyasını asla commit etmeyin. Dosyayı .gitignore'a ekleyin.

Pratik kullanım ve öneriler

Kod örnekleri:

if (BuildConfig.DEBUG) {
  Log.d("Main", "Debug modu")
}
val client = Retrofit.Builder()
  .baseUrl(BuildConfig.API_URL)
  .build()

Öneriler:

Kütüphaneler için unutmayın: library modülünün kendi paket adıyla ayrı bir BuildConfig'i vardır.
Uzun gizli bilgileri BuildConfig'de saklamayın — değerler APK'ya dahil edilir ve dekompile edildiğinde erişilebilir olabilir.
CI anahtarlarını saklamak için local.properties/gradle.properties kullanın: gradle.properties CI gizlilerinde saklanabilir ve derleme sırasında çekilebilir.

Yapılandırma saklama yöntemlerinin karşılaştırılması

Yöntem	Avantajlar	Dezavantajlar
BuildConfig	Otomatik oluşturma, tür güvenliği, bayraklar ve URL'ler için uygun	Değerler APK'ya girer (gizli bilgiler için uygun değil)
local.properties / gradle.properties	Doğru yapılandırıldığında depoda bulunmaz	Makineler arasında manuel senkronizasyon gerekir
Product Flavors	Birden fazla ortam desteği	APK/variant sayısını artırır
Remote Config (Firebase)	Yeniden derlemeden değiştirilebilir	Ağ bağımlılığı, güncelleme gecikmesi

Sık yapılan hatalar

BuildConfig bulunamadı: applicationId'yi kontrol edin, Build > Clean Project > Rebuild işlemini uygulayın.
Gizli bilgilerin depoda saklanması: local.properties dosyasını commit etmeyin.
Kotlin DSL'de yanlış escape edilmiş dizgeler: ""değer"" veya rawString kullanın ve derlemeyi kontrol edin.
Çalışma zamanı güncellemeleri beklentisi: BuildConfig değeri derleme anında sabitlenir.

SSS

API anahtarları için BuildConfig kullanmalı mıyım?
- Yalnızca anahtar gizli değilse kullanın. Gizli bilgiler için güvenli depolar/sunucu proxy'leri kullanın veya çalışma zamanında güvenli bir backend'den yükleyin.
Staging ve production için farklı değerler nasıl alınır?
- productFlavors veya ayrı buildTypes oluşturun ve her variant için buildConfigField tanımlayın.
A modülündeki BuildConfig B modülünde kullanılabilir mi?
- Hayır: her modül kendi BuildConfig'ini oluşturur. Ortak yapılandırma için ortak bir kütüphane veya kaynak tabanlı çözüm kullanın.

Gerekirse, CI değişken yerleştirme ile build.gradle(.kts) dosyanız için hazır kod parçacıkları sunabilirim.