Build Type — bu nima, Gradle-da debug va release konfiguratsiyasi

Build Type nima?

Build Type — Android loyihasining Gradle konfiguratsiyasi elementi bo'lib, ilovani kompilyatsiya va paketlash parametrlarini tavsiflaydi. Har bir Build Type nomlangan variantlar to'plamidir: debuggable (tuzatishni yoqish), minificationEnabled (kod siqishni yoqish), shrinkResources (resurs siqishni yoqish), proguardFiles (ProGuard qoidalari fayllari), signingConfig (imzo sertifikati) va boshqalar. Build Types app modulining build.gradle faylining android.buildTypes blokida e'lon qilinadi.

Build Type ning asosiy vazifasi development workflow (tez yig'ish, batafsil jurnallar, tuzatish) va production release (optimallashtirilgan kod, minimal hajm, xavfsizlik) ni ajratishdir. Debug yig'masi soniyalar ichida yig'ilishi va dasturchiga maksimal ma'lumot berishi kerak. Release yig'masi foydalanuvchilar uchun maksimal tez va ixcham bo'lishi kerak. Build Type — ilova funksionalligi bilan bog'liq bo'lmagan infratuzilma sozlamasi.

Android Gradle Plugin har bir Build Type uchun avtomatik source set yaratadi — src/<buildType>/ katalogi (masalan, src/debug/, src/release/). Bu source set ga faqat o'sha yig'ish turi uchun qo'llaniladigan resurslar, kod va manifest joylashtirilishi mumkin. Masalan, src/debug/ da ADB dan o'rnatish ruxsati bilan AndroidManifest.xml joylashtirilishi mumkin, src/release/ da esa unsiz. Build Type source set i Product Flavor source set idan ustunlikka ega.

Build Type vs Product Flavor

Asosiy farq: Build Type “qanday yig'ish?” degan savolga javob beradi, Product Flavor esa “nimani yig'ish?” degan savolga. Build Type debug, release, staging bo'lishi mumkin. Product Flavor free, paid, enterprise bo'lishi mumkin. Build Type ilovaning funksionalligini o'zgartirmaydi (ekranlarni qo'shmaydi yoki olib tashlamaydi), Product Flavor o'zgartiradi. Build Type tuzatishni o'chirib, obfuskatsiyani yoqishi mumkin, Product Flavor applicationId va resurslarni o'zgartirishi mumkin. Ikkalasi juftlikda ishlaydi: har bir Build Type har bir Product Flavor bilan birlashib, Build Variant hosil qiladi.

Standart Build Types: debug va release

Debug — AGP tomonidan sukut bo'yicha yaratiladigan Build Type. U debuggable=true ni o'z ichiga oladi, bu tuzatishni ulash, Log.d jurnallarini ko'rish va Android Studio profilidan foydalanish imkonini beradi. Minification o'chirilgan, shuning uchun yig'ish tez amalga oshiriladi. Debug yig'masida applicationId “.debug” suffiksini oladi (agar qayta yozilmagan bo'lsa), bu debug versiyasini release bilan bir qurilmada parallel o'rnatish imkonini beradi. Debug Android SDK tomonidan avtomatik yaratilgan debug.keystore sertifikati bilan imzolanadi.

Release — ilovani nashr qilish uchun Build Type. debuggable=false, minificationEnabled=true (sukut bo'yicha), shrinkResources=true. Dasturchi signingConfig da production sertifikatini ko'rsatishi kerak — aks holda yig'ma release hisoblanmaydi. Release kodni obfuskatsiya, optimallashtirish va siqish uchun ProGuard yoki R8 dan foydalanadi. Android Studio release yig'masiga tuzatishni ulay olmaydi (agar debuggable=false bo'lsa). Barcha Log.d va Log.v chaqiruvlari tegishli ProGuard qoidalari sozlangan bo'lsa, minification bosqichida koddan olib tashlanadi.

Muhim: debug yig'malari release xatti-harakatini test qilmaydi. Minification kod xatti-harakatini o'zgartirishi mumkin — reflection, serializatsiya, Gson/SQLite va boshqa kutubxonalar ko'pincha ProGuard qoidalarini talab qiladi. Shuning uchun nashrdan oldin release yig'masini qurib, test qilish majburiy. Google Play Console va Firebase Test Lab nashrdan oldin real qurilmalarda avtomatik test qilish uchun release yig'malarini yuklash imkonini beradi.

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

Maxsus Build Types yaratish

initWith orqali meros olish

Debug va release dan tashqari o'z Build Types laringizni yaratishingiz mumkin — masalan staging (oraliq muhit) yoki benchmark (ishlash testlari uchun). Maxsus Build Type buildTypes blokida debug va release kabi e'lon qilinadi. Nomi ixtiyoriy bo'lishi mumkin, ammo ingliz tilida semantik tushunarli nomlardan foydalanish tavsiya etiladi. Staging uchun odatda debuggable=true (staging muhitida muammolarni diagnostika qilish uchun) va minification=true (production dan oldin obfuskatsiyani test qilish uchun) o'rnatiladi.

Maxsus Build Type avtomatik ravishda tegishli source set (src/staging/) oladi va assembleStaging kabi vazifalarni yaratadi. AGP maxsus turlar soniga cheklov qo'ymaydi, lekin har bir yangi tur Build Variants sonini ko'paytiradi. Amaliy chegara — 4-5 Build Types: debug, staging, benchmark, release va ehtimol debugMinified (ProGuard qoidalarini test qilish uchun minification yoqilgan debug).

Maxsus Build Type uchun debuggable ni debug dan initWith yordamida meros olish mumkin. initWith kalit so'zi ko'rsatilgan Build Type ning barcha parametrlarini nusxalaydi, so'ngra ularni qayta yozish mumkin. Bu staging ni debug asosida yaratish uchun qulay: initWith debug + qo'shimcha minification yoqish. initWith bo'lmasa, asosiy turning barcha parametrlarini qo'lda sanab o'tish kerak bo'ladi.

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 turi bo'lmagan kutubxonalar uchun
// kutubxonada faqat release bo'lsa — AGP undan foydalanadi

Turli yig'ish turlari uchun imzo konfiguratsiyasi

SigningConfig APK yoki AAB qaysi sertifikat bilan imzolanishini belgilaydi. Android barcha o'rnatiladigan ilovalarni imzolashni talab qiladi — usiz tizim APK ni o'rnatishga ruxsat bermaydi. Debug yig'malari uchun AGP debug.keystore dan foydalanadi — Android SDK Tools tomonidan yaratilgan, ma'lum parol bilan oldindan o'rnatilgan sertifikat. Release yig'malari uchun Android Studio (Build → Generate Signed Bundle/APK) yoki keytool buyruq qatori orqali o'z sertifikatingizni yaratishingiz kerak.

Imzo kalitlarini saqlash — muhim xavfsizlik jihati. Release kalitlarini saqlamaslik tavsiya etiladi manba kod omborida. Buning o'rniga ishlatiladi: keystore.properties fayli (.gitignore ga qo'shilgan), CI/CD muhit o'zgaruvchilari yoki Android Studio ning shifrlangan ombori. CI/CD da (GitHub Actions, GitLab CI) imzo kalitlari secrets da saqlanadi va build.gradle ga tizim xususiyatlari orqali uzatiladi. Misol: storePassword = System.getenv("KEYSTORE_PASSWORD").

Har bir Build Type o'z signingConfig iga murojaat qilishi mumkin. Release uchun — production sertifikati, debug uchun — debug.keystore, staging uchun — alohida staging sertifikati. Imzo konfiguratsiyasi to'g'ridan-to'g'ri ilovani o'rnatish imkoniyatiga ta'sir qiladi: agar debug debug.keystore bilan, staging esa production kaliti bilan imzolangan bo'lsa, staging debug versiyasi ustiga imzo mos kelmasligi sababli o'rnatilmaydi. ApplicationId ham farqli bo'lishi kerak — buning uchun applicationIdSuffix ishlatiladi.

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

Resource Shrinking

Minification — foydalanilmayotgan kodni olib tashlash va sinflar, metodlar va maydonlar nomlarini qisqa nomlarga o'zgartirish jarayoni. AGP minification ni ProGuard (eskirgan) yoki R8 (tavsiya etiladi, AGP 3.4 versiyasidan o'rnatilgan) yordamida amalga oshiradi. R8 to'rtta operatsiyani bajaradi: shrinking (foydalanilmayotgan sinflarni olib tashlash), optimisation (kodni soddalashtirish), obfuscation (nomlarni o'zgartirish) va preverify (moslik ma'lumotini qo'shish). Natija — kichikroq hajmli APK, uni dekompilyatsiya qilish qiyinroq.

Minification qoidalari ProGuard rules files da belgilanadi — -keep, -dontwarn, -keepclassmembers sintaksisiga ega matn fayllari. Qoidalarsiz R8 reflection (Gson, Retrofit, Room, Kotlin serialization) orqali ishlatiladigan sinflarni olib tashlaydi yoki nomini o'zgartiradi. Android Studio loyiha shabloni proguard-rules.pro ni yaratadi, unga ma'lum kutubxonalar uchun qoidalar qo'shiladi. Kutubxonalar ham o'rnatilgan qoidalarga ega bo'lishi mumkin — ular avtomatik ravishda jar/aar dan ulanadi.

Shrink resources (shrinkResources=true) APK dan foydalanilmayotgan resurslarni olib tashlaydi. R8 avval qaysi resurslar koddan foydalanilmayotganini aniqlaydi (R.java va manifestdagi havolalarni tekshiradi), so'ngra ularni yakuniy yig'madan olib tashlaydi. getIdentifier() yoki uchinchi tomon kutubxonalari orqali ishlatiladigan resurslar uchun resurslarda tools:keep="@layout/my_layout" qo'shish kerak. Minification bilan birgalikda resource shrinking APK hajmini 40-60% kamaytirishi mumkin.

# proguard-rules.pro — majburiy qoidalar
# Gson: serializatsiya uchun sinflarni saqla
-keepclassmembers class com.example.** {
    <fields>;
}

# Retrofit: API interfeyslarini saqla
-keep,allowobfuscation interface com.example.api.*

# Room: DAO va Entity ni saqla
-keep class * extends androidx.room.RoomDatabase
-keep @interface androidx.room.** { *; }

# Kotlin Coroutines: Continuation olib tashlanishining oldini ol
-keepnames class kotlinx.coroutines.internal.*

# OkHttp: service loader ni saqla
-keep class okhttp3.** { *; }

Build Type uchun BuildConfigField va resurslar

BuildConfig — defaultConfig, productFlavors va buildTypes da belgilangan konstantalarni o'z ichiga olgan avtomatik yaratilgan Java/Kotlin sinfi. buildConfigField orqali maxsus maydonlar qo'shilishi mumkin: buildConfigField "String", "API_URL", '"https://api.example.com"'. buildType da e'lon qilingan BuildConfigField bu turning barcha variantlarida mavjud. buildType dagi qiymatlar productFlavor dagi qiymatlarni, ular esa o'z navbatida defaultConfig ni bekor qiladi.

Debug yig'malari uchun API_URL ni localhost yoki staging serveriga, release uchun esa production ga o'rnatish qulay. BuildConfig.FLAVOR va BuildConfig.BUILD_TYPE ham avtomatik yaratiladi va joriy flavor va build type nomini o'z ichiga oladi. Koddan foydalanish mumkin: if (BuildConfig.DEBUG) { /* jurnallar */ } — DEBUG doimiysi faqat debug build type uchun true. BuildConfig.DEBUG — AGP har bir BuildConfig ga qo'shadigan standart maydon.

Build Type uchun resurslar src/<buildType>/res/ source set i orqali belgilanadi. Masalan, src/debug/res/values/strings.xml “Server: Dev” matnini, src/release/res/ esa “Server: Prod” matnini o'z ichiga olishi mumkin. Manifest resurslari ham source set orqali bekor qilinadi: src/debug/AndroidManifest.xml faqat debug yig'malari uchun <uses-permission android:name="android.permission.INTERNET" /> ni o'z ichiga olishi mumkin. Bu koddagi BuildConfig tekshiruvidan tozaroq va dasturiy o'rnatib bo'lmaydigan atributlar (masalan, networkSecurityConfig) uchun ham ishlaydi.

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

// Foydalanish: asosiy sinf Config ni reflection orqali yuklaydi
fun getConfig(): AppConfig = when (BuildConfig.BUILD_TYPE) {
    "debug" -> DebugConfig
    else -> ReleaseConfig
}