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 غیر فعال ہے، اس لیے بلڈ تیز ہے۔ ڈیبگ بلڈ میں، applicationId کو ".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 کالز کوڈ سے ہٹا دی جاتی ہیں۔

اہم: ڈیبگ بلڈز ریلیز رویے کی جانچ نہیں کرتے. Minification کوڈ کے رویے کو بدل سکتا ہے — reflection، سیریلائزیشن، Gson/SQLite اور دیگر لائبریریاں اکثر ProGuard قواعد کی ضرورت ہوتی ہیں۔ لہذا، شائع کرنے سے پہلے ہمیشہ ریلیز بلڈ بنائیں اور جانچیں۔ Google Play Console اور Firebase Test Lab شائع کرنے سے پہلے حقیقی آلات پر خودکار جانچ کے لیے ریلیز بلڈ اپ لوڈ کرنے کی اجازت دیتے ہیں۔

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 کو تمام انسٹال ایبل ایپلیکیشنز پر دستخط درکار ہیں — اس کے بغیر سسٹم انسٹالیشن کی اجازت نہیں دے گا۔ ڈیبگ بلڈز کے لیے، AGP debug.keystore استعمال کرتا ہے — Android SDK Tools کے ذریعے بنائے گئے معروف پاس ورڈ کے ساتھ پہلے سے انسٹال شدہ سرٹیفکیٹ۔ ریلیز بلڈز کے لیے، آپ کو Android Studio (Build → Generate Signed Bundle/APK) یا keytool کمانڈ لائن کے ذریعے اپنا سرٹیفکیٹ بنانا ہوگا۔

سائننگ کلیدوں کا ذخیرہ ایک اہم سیکیورٹی پہلو ہے۔ سفارش کی جاتی ہے کہ ریلیز کلیدوں کو سورس کوڈ ریپوزٹری میں ذخیرہ نہ کریں۔ اس کے بجائے، 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 کو ڈیبگ ورژن کے اوپر انسٹال نہیں کیا جا سکتا۔ 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 کو اوور رائڈ کرتی ہیں۔

ڈیبگ بلڈز کے لیے، 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 کے لیے وسائل source set src/<buildType>/res/ کے ذریعے بیان کیے جاتے ہیں۔ مثال کے طور پر، src/debug/res/values/strings.xml میں سٹرنگ "Server: Dev" ہو سکتی ہے، جبکہ src/release/res/ میں "Server: Prod" ہو سکتی ہے۔ مینی فیسٹ وسائل بھی source set کے ذریعے اوور رائڈ کیے جاتے ہیں: src/debug/AndroidManifest.xml صرف ڈیبگ بلڈز کے لیے <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
}