Build Type — কি, Gradle-এ debug এবং release কনফিগারেশন

Build Type কী?

Build Type Android প্রকল্পগুলিতে Gradle কনফিগারেশনের একটি উপাদান যা অ্যাপ্লিকেশনের কম্পাইলেশন এবং প্যাকেজিং প্যারামিটার বর্ণনা করে। প্রতিটি Build Type হল অপশনের একটি নামযুক্ত সেট: debuggable (ডিবাগিং সক্ষম করুন), minificationEnabled (কোড কম্প্রেশন সক্ষম করুন), shrinkResources (রিসোর্স কম্প্রেশন সক্ষম করুন), proguardFiles (ProGuard নিয়ম ফাইল), signingConfig (সাইনিং সার্টিফিকেট) এবং অন্যান্য। Build Types অ্যাপ মডিউলের 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-এর উপর অগ্রাধিকার রয়েছে।

BuildType বনাম 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 ডিবাগ সংস্করণের উপর ইনস্টল করা যাবে না। 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
}