Build Type — क्या है, Gradle में debug और release कॉन्फ़िगरेशन

Build Type क्या है?

Build Type Android प्रोजेक्ट्स में Gradle कॉन्फ़िगरेशन का एक तत्व है जो एप्लिकेशन के कंपाइलेशन और पैकेजिंग पैरामीटर का वर्णन करता है। प्रत्येक Build Type विकल्पों का एक नामित सेट है: debuggable (डीबगिंग सक्षम करें), minificationEnabled (कोड संपीड़न सक्षम करें), shrinkResources (संसाधन संपीड़न सक्षम करें), proguardFiles (ProGuard नियम फ़ाइलें), signingConfig (साइनिंग सर्टिफिकेट) और अन्य। Build Types को app मॉड्यूल की build.gradle फ़ाइल के android.buildTypes ब्लॉक में घोषित किया जाता है।

Build Type का मुख्य उद्देश्य डेवलपमेंट वर्कफ़्लो (त्वरित बिल्ड, विस्तृत लॉग, डीबगिंग) को प्रोडक्शन रिलीज़ (ऑप्टिमाइज़्ड कोड, न्यूनतम आकार, सुरक्षा) से अलग करना है। Debug बिल्ड को सेकंडों में बनना चाहिए और डेवलपर को अधिकतम जानकारी प्रदान करनी चाहिए। Release बिल्ड उपयोगकर्ताओं के लिए जितना संभव हो उतना तेज़ और कॉम्पैक्ट होना चाहिए। Build Type एक इन्फ्रास्ट्रक्चर सेटिंग है, जो एप्लिकेशन की कार्यक्षमता से संबंधित नहीं है।

Android Gradle Plugin स्वचालित रूप से प्रत्येक Build Type के लिए एक source set बनाता है — src/<buildType>/ निर्देशिका (जैसे, src/debug/, src/release/)। इस source set में रखे गए संसाधन, कोड और मेनिफ़ेस्ट फ़ाइलें केवल उस बिल्ड प्रकार पर लागू होते हैं। उदाहरण के लिए, src/debug/ में ADB से इंस्टॉलेशन अनुमति के साथ AndroidManifest.xml रखा जा सकता है, और src/release/ में बिना। Build Type source set की Product Flavor source set पर प्राथमिकता होती है।

Build Type बनाम Product Flavor

मुख्य अंतर: Build Type प्रश्न का उत्तर देता है "कैसे बनाएं?", जबकि Product Flavor उत्तर देता है "क्या बनाएं?". Build Type debug, release, staging हो सकता है। Product Flavor free, paid, enterprise हो सकता है। Build Type एप्लिकेशन की कार्यक्षमता नहीं बदलता (स्क्रीन नहीं जोड़ता या हटाता), Product Flavor बदलता है। Build Type डीबगर को अक्षम कर सकता है और ऑबफ़स्केशन सक्षम कर सकता है, Product Flavor applicationId और संसाधन बदल सकता है। दोनों एक साथ काम करते हैं: प्रत्येक Build Type प्रत्येक Product Flavor के साथ मिलकर Build Variant बनाता है।

मानक Build Types: debug और release

Debug AGP द्वारा डिफ़ॉल्ट रूप से बनाया गया Build Type है। इसमें debuggable=true है, जो डीबगर अटैचमेंट, Log.d लॉग देखने और Android Studio प्रोफ़ाइलर का उपयोग करने की अनुमति देता है। Minification अक्षम है, इसलिए बिल्ड तेज़ है। Debug बिल्ड में, applicationId को ".debug" सफ़िक्स मिलता है (यदि ओवरराइड न किया गया हो), जो डीबग संस्करण को रिलीज़ संस्करण के साथ एक ही डिवाइस पर इंस्टॉल करने की अनुमति देता है। Debug बिल्ड debug.keystore से सर्टिफिकेट के साथ साइन किया जाता है, जो Android SDK द्वारा स्वचालित रूप से बनाया जाता है।

Release एप्लिकेशन प्रकाशित करने के लिए Build Type है। debuggable=false, minificationEnabled=true (डिफ़ॉल्ट रूप से), shrinkResources=true। डेवलपर को प्रोडक्शन सर्टिफिकेट के साथ signingConfig निर्दिष्ट करना होगा — अन्यथा बिल्ड को रिलीज़ नहीं माना जाएगा। Release बिल्ड ऑबफ़स्केशन, ऑप्टिमाइज़ेशन और कोड संपीड़न के लिए ProGuard या R8 का उपयोग करता है। Android Studio रिलीज़ बिल्ड से डीबगर अटैच नहीं कर सकता (यदि debuggable=false)। यदि उपयुक्त ProGuard नियम कॉन्फ़िगर किए गए हैं तो minification के दौरान सभी Log.d और Log.v कॉल कोड से हटा दिए जाते हैं।

महत्वपूर्ण: debug बिल्ड release व्यवहार का परीक्षण नहीं करते. Minification कोड व्यवहार बदल सकता है — reflection, सीरियलाइज़ेशन, Gson/SQLite और अन्य लाइब्रेरीज़ को अक्सर ProGuard नियमों की आवश्यकता होती है। इसलिए, प्रकाशन से पहले हमेशा release बिल्ड बनाएं और उसका परीक्षण करें। Google Play Console और Firebase Test Lab प्रकाशन से पहले वास्तविक उपकरणों पर स्वचालित परीक्षण के लिए release बिल्ड अपलोड करने की अनुमति देते हैं।

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

कस्टम Build Types बनाना

initWith के माध्यम से इनहेरिटेंस

debug और release के अलावा, कस्टम Build Types बनाए जा सकते हैं — उदाहरण के लिए staging (मध्यवर्ती वातावरण) या benchmark (प्रदर्शन परीक्षण के लिए)। कस्टम Build Type को buildTypes ब्लॉक में debug और release की तरह ही घोषित किया जाता है। नाम कुछ भी हो सकता है, लेकिन अंग्रेज़ी में अर्थपूर्ण नामों का उपयोग करने की अनुशंसा की जाती है। Staging के लिए आमतौर पर debuggable=true (staging वातावरण में समस्याओं के निदान के लिए) और minification=true (प्रोडक्शन से पहले ऑबफ़स्केशन का परीक्षण करने के लिए) सेट किया जाता है।

कस्टम Build Type स्वचालित रूप से एक संबंधित source set (src/staging/) प्राप्त करता है और assembleStaging जैसे कार्य उत्पन्न करता है। AGP कस्टम प्रकारों की संख्या पर कोई सीमा नहीं लगाता, लेकिन प्रत्येक नया प्रकार Build Variants की संख्या को गुणा करता है। व्यावहारिक सीमा 4-5 Build Types है: debug, staging, benchmark, release, और संभवतः debugMinified (ProGuard नियमों के परीक्षण के लिए minification सक्षम के साथ debug)।

कस्टम Build Type के लिए, आप initWith का उपयोग करके debug से debuggable इनहेरिट कर सकते हैं। initWith कीवर्ड निर्दिष्ट Build Type के सभी पैरामीटर कॉपी करता है, जिसके बाद उन्हें ओवरराइड किया जा सकता है। यह debug के आधार पर staging बनाने के लिए सुविधाजनक है: initWith debug + अतिरिक्त रूप से minification सक्षम करें। initWith के बिना, आपको बेस प्रकार के सभी पैरामीटर मैन्युअल रूप से सूचीबद्ध करने होंगे।

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 प्रकार नहीं है
// यदि लाइब्रेरी के पास केवल release है — AGP इसका उपयोग करता है

विभिन्न बिल्ड प्रकारों के लिए साइनिंग कॉन्फ़िगरेशन

SigningConfig निर्धारित करता है कि APK या AAB पर हस्ताक्षर करने के लिए किस सर्टिफिकेट का उपयोग किया जाए। Android को सभी इंस्टॉल करने योग्य एप्लिकेशन पर हस्ताक्षर करना आवश्यक है — इसके बिना सिस्टम इंस्टॉलेशन की अनुमति नहीं देगा। Debug बिल्ड के लिए, AGP debug.keystore का उपयोग करता है — Android SDK Tools द्वारा उत्पन्न ज्ञात पासवर्ड के साथ एक प्री-इंस्टॉल्ड सर्टिफिकेट। Release बिल्ड के लिए, आपको Android Studio (Build → Generate Signed Bundle/APK) या keytool कमांड लाइन के माध्यम से अपना स्वयं का सर्टिफिकेट बनाना होगा।

साइनिंग कुंजियों का भंडारण एक महत्वपूर्ण सुरक्षा पहलू है। यह अनुशंसा की जाती है कि release कुंजियों को स्रोत कोड रिपॉजिटरी में संग्रहीत न करें। इसके बजाय, keystore.properties फ़ाइल (.gitignore में जोड़ी गई), CI/CD पर्यावरण चर, या Android Studio का एन्क्रिप्टेड स्टोरेज उपयोग करें। CI/CD (GitHub Actions, GitLab CI) में, साइनिंग कुंजियाँ secrets में संग्रहीत की जाती हैं और सिस्टम गुणों के माध्यम से build.gradle को पास की जाती हैं। उदाहरण: storePassword = System.getenv("KEYSTORE_PASSWORD")।

प्रत्येक Build Type अपने स्वयं के signingConfig को संदर्भित कर सकता है। Release के लिए — प्रोडक्शन सर्टिफिकेट, debug के लिए — debug.keystore, staging के लिए — एक अलग staging सर्टिफिकेट। साइनिंग कॉन्फ़िगरेशन सीधे एप्लिकेशन इंस्टॉल करने की क्षमता को प्रभावित करता है: यदि आप debug को debug.keystore से और staging को प्रोडक्शन कुंजी से साइन करते हैं, तो हस्ताक्षरों के बेमेल होने के कारण staging को debug संस्करण के ऊपर इंस्टॉल नहीं किया जा सकता। applicationId भी भिन्न होना चाहिए — इसके लिए 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 और R8

Resource Shrinking

Minification अप्रयुक्त कोड को हटाने और कक्षाओं, विधियों और फ़ील्ड का नाम बदलने की प्रक्रिया है। AGP ProGuard (पुराना) या R8 (अनुशंसित, AGP संस्करण 3.4 से निर्मित) के साथ minification करता है। R8 चार ऑपरेशन करता है: shrinking (अप्रयुक्त कक्षाओं को हटाना), optimisation (कोड को सरल बनाना), obfuscation (नाम बदलना), और preverify (संगतता जानकारी जोड़ना)। परिणाम एक छोटा APK है जिसे डीकंपाइल करना कठिन है।

Minification नियम ProGuard नियम फ़ाइलों में परिभाषित किए जाते हैं — टेक्स्ट फ़ाइलें जिनमें -keep, -dontwarn, -keepclassmembers जैसी वाक्य रचना होती है। नियमों के बिना, R8 reflection (Gson, Retrofit, Room, Kotlin सीरियलाइज़ेशन) के माध्यम से उपयोग की जाने वाली कक्षाओं को हटा या नाम बदल देगा। Android Studio प्रोजेक्ट टेम्पलेट एक proguard-rules.pro फ़ाइल बनाता है जहाँ विशिष्ट लाइब्रेरीज़ के लिए नियम जोड़े जाते हैं। लाइब्रेरीज़ में अंतर्निहित नियम भी हो सकते हैं — वे स्वचालित रूप से jar/aar से शामिल होते हैं।

Shrink resources (shrinkResources=true) APK से अप्रयुक्त संसाधनों को हटाता है। R8 पहले यह निर्धारित करता है कि कोड में कौन से संसाधन उपयोग नहीं किए गए हैं (R.java और मेनिफ़ेस्ट संदर्भों की जाँच करता है), फिर उन्हें अंतिम बिल्ड से हटा देता है। getIdentifier() या तृतीय-पक्ष लाइब्रेरीज़ के माध्यम से उपयोग किए जाने वाले संसाधनों के लिए, आपको संसाधनों में tools:keep="@layout/my_layout" जोड़ना होगा। Minification के साथ संयुक्त, resource shrinking APK आकार को 40-60% तक कम कर सकता है।

# proguard-rules.pro — अनिवार्य नियम
# Gson: सीरियलाइज़ेशन के लिए कक्षाएं रखें
-keepclassmembers class com.example.** {
    <fields>;
}

# Retrofit: API इंटरफ़ेस रखें
-keep,allowobfuscation interface com.example.api.*

# Room: DAO और Entity रखें
-keep class * extends androidx.room.RoomDatabase
-keep @interface androidx.room.** { *; }

# Kotlin Coroutines: Continuation को हटाने से रोकें
-keepnames class kotlinx.coroutines.internal.*

# OkHttp: service loader संरक्षित करें
-keep class okhttp3.** { *; }

BuildConfigField और Build Type के लिए संसाधन

BuildConfig एक स्वचालित रूप से उत्पन्न Java/Kotlin क्लास है जिसमें defaultConfig, productFlavors और buildTypes में परिभाषित स्थिरांक होते हैं। buildConfigField के माध्यम से कस्टम फ़ील्ड जोड़े जा सकते हैं: buildConfigField "String", "API_URL", '"https://api.example.com"'। buildType में घोषित BuildConfigField उस प्रकार के सभी वेरिएंट में उपलब्ध है। buildType के मान productFlavor के मानों को ओवरराइड करते हैं, जो बदले में defaultConfig को ओवरराइड करते हैं।

Debug बिल्ड के लिए, API_URL को localhost या staging सर्वर पर सेट करना सुविधाजनक है, और release के लिए — प्रोडक्शन पर। BuildConfig.FLAVOR और BuildConfig.BUILD_TYPE भी स्वचालित रूप से उत्पन्न होते हैं और वर्तमान flavor और build type के नाम रखते हैं। कोड में उपयोग कर सकते हैं: if (BuildConfig.DEBUG) { /* लॉग */ } — DEBUG स्थिरांक केवल debug build type के लिए सत्य है। BuildConfig.DEBUG एक मानक फ़ील्ड है जिसे AGP प्रत्येक BuildConfig में जोड़ता है।

Build Type के लिए संसाधन src/<buildType>/res/ source set के माध्यम से परिभाषित किए जाते हैं। उदाहरण के लिए, src/debug/res/values/strings.xml में स्ट्रिंग "Server: Dev" हो सकती है, जबकि src/release/res/ में "Server: Prod" हो सकता है। मेनिफ़ेस्ट संसाधन भी source set के माध्यम से ओवरराइड किए जाते हैं: src/debug/AndroidManifest.xml में केवल debug बिल्ड के लिए <uses-permission android:name="android.permission.INTERNET" /> शामिल हो सकता है। यह कोड में BuildConfig जाँचने से अधिक स्वच्छ है और उन विशेषताओं के लिए भी काम करता है जिन्हें प्रोग्रामेटिक रूप से सेट नहीं किया जा सकता (जैसे 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
}

// उपयोग: मुख्य क्लास reflection के माध्यम से Config लोड करता है
fun getConfig(): AppConfig = when (BuildConfig.BUILD_TYPE) {
    "debug" -> DebugConfig
    else -> ReleaseConfig
}