Build Variant — bu nima, build type va product flavor Android-da

Build Variant nima?

Build Variant — bu bitta Build Type va bitta Product Flavor kombinatsiyasining natijasidir. Loyihada Product Flavor aniqlanmagan bo'lsa, Build Variant Build Type bilan mos keladi. Gradle barcha FlavorDimensions, Product Flavors va Build Types-ning dekart ko'paytmasini avtomatik ravishda yaratadi. Masalan, free/paid flavor va debug/release turlari uchun 8 variant yaratiladi: freeDebug, freeRelease, paidDebug, paidRelease.

Har bir Build Variant <Flavor><Type> formatida o'z nomini oladi (flavor katta harf bilan). Bu variant uchun Gradle alohida topshiriqlar yaratadi: assembleFreeDebug, installFreeDebug, bundleFreeRelease. Android Studio-da variantlar o'rtasida o'tish Build Variants paneli (View → Tool Windows → Build Variants) orqali mumkin. Variantni tanlash qaysi kod kompilyatsiya qilinishiga, qaysi resurslar kiritilishiga va qaysi APK/AAB yaratilishiga ta'sir qiladi.

Build Variants tizimi uchta asosiy vazifani hal qiladi: turli muhitlar (dev/staging/production) uchun konfiguratsiyalarni ajratish, ilovaning bir nechta versiyalarini (free/paid) yaratish va kompilyatsiyalarning A/B testi. Build Variants bo'lmasa, dasturchilar bayroqlar va konfiguratsiyalarni qo'lda almashtirishga majbur bo'lar edilar, bu esa inson omilidan kelib chiqadigan xatolarga olib keladi. Gradle Inc., 2024 tadqiqotiga ko'ra, Build Variants-ni joriy etish uch va undan ortiq joylashtirish muhitiga ega loyihalarda kompilyatsiya xatolarini 60% ga kamaytiradi.

Gradle variantlarni qanday yaratadi

AGP (Android Gradle Plugin) konfiguratsiya bosqichida barcha kombinatsiyalarni hisoblab chiqadi. Loyihada ikki o'lchov mos ravishda ikki va uch flavor bilan bo'lsa, Gradle 2 × 2 × 3 = 12 kombinatsiya yaratadi, Build Types soniga (odatda 2) ko'paytiriladi. Har bir kombinatsiya noyob nom va topshiriqlar to'plamini oladi. AGP har bir variant uchun avtomatik ravishda source set qo'shadi: src/freeDebug/, src/paidRelease/, shuningdek umumlashtirilgan src/free/ va src/debug/. Resurslarni o'qish ustuvorligi: variant → flavor → type → main.

// Misol: 4 Build Variants
// flavorDimensions "version", "server"
// version: demo, prod
// server: mock, live
// buildTypes: debug, release
// Jami: 2 × 2 × 2 = 8 variant

android {
    flavorDimensions "version", "server"

    productFlavors {
        demo { dimension "version" }
        prod { dimension "version" }
        mock { dimension "server" }
        live { dimension "server" }
    }
}

Build Type va Product Flavor: farqlar

Build Type ilova qanday yig'ilishini belgilaydi — nosozliklarni tuzatish ma'lumoti bilan yoki unsiz, optimizatsiya bilan yoki unsiz, qanday imzolash bilan. Product Flavor nima yig'ilishini belgilaydi — mahsulotning qaysi versiyasini. Build Type — kompilyatsiya mexanizmi (debug, release, staging). Product Flavor — mahsulot varianti (free, paid, enterprise, demo). Ikkala tushuncha ortogonaldir: har qanday Build Type har qanday Product Flavor-ga qo'llanilishi mumkin.

Build Type sukut bo'yicha debug (debuggable=true, minification=false, signing=debug.keystore) va release (debuggable=false, minification=true, signing=production.keystore) ni o'z ichiga oladi. Product Flavor sukut bo'yicha bitta, nomsiz (aslida main source set). Dasturchi o'zining Build Types (masalan, “staging” debuggable=true va minification=true bilan) va Product Flavors-ni istalgan sonda qo'shishi mumkin. Farq shundaki, Build Type o'lchovlarga guruhlanishi mumkin emas, Product Flavor esa mumkin.

Asosiy amaliy farq: build.gradle-dagi defaultConfig barcha Variants-ga qo'llaniladi, lekin productFlavors va buildTypes-da bekor qilinishi mumkin. buildType-ga qo'shilgan BuildConfigField ushbu turning barcha flavor-larida ko'rinadi, productFlavor-ga qo'shilgan esa ushbu flavor-ning barcha turlarida. Agar maydon ham u yerda, ham bu yerda aniqlangan bo'lsa — buildType ustunlikka ega (zanjirda oxirgi qo'llaniladi).

Taqqoslash jadvali

Build Variants-ni build.gradle-da sozlash

Konfiguratsiyalar ustuvorligi

Build Variants-ni sozlash modul darajasidagi build.gradle faylining android blokida amalga oshiriladi. Avval buildTypes o'z parametrlari bilan, keyin flavorDimensions va productFlavors e'lon qilinadi. Gradle ushbu e'lonlar asosida avtomatik variantlar yaratadi. Har bir variant modulning defaultConfig-ni meros qilib oladi, belgilangan maydonlarni bekor qiladi. E'lon qilish tartibi ustuvorlikka ta'sir qiladi: buildTypes productFlavors-dan keyin qo'llaniladi.

Gradle skriptlarida aniq Build Variant-ga kirish uchun android.applicationVariants (app moduli uchun) yoki android.libraryVariants (kutubxona moduli uchun) ishlatiladi. Bu to'plam bo'lib, unda iteratsiya qilish va konfiguratsiya vaqtida har bir variant konfiguratsiyasini o'zgartirish mumkin. Masalan, “demo” so'zini o'z ichiga olgan barcha variantlar uchun dasturiy ravishda buildConfigField qo'shilishi mumkin.

Android Gradle Plugin 8.x, variantlarni lambdalar orqali sozlash uchun onVariants — tozaroq API qo'llab-quvvatlashini qo'shdi. Eski API (variantOutput, variantFilter) eskirgan deb belgilangan. Kutubxona modullari uchun onVariants bilan birga onEach ishlatish tavsiya etiladi. AGP 7.x dan 8.x ga yangilashda variantOutput-dan onVariants-ga migratsiya tavsiya etiladi.

android {
    buildTypes {
        debug {
            debuggable true
            minification false
            signingConfig signingConfigs.debug
        }
        release {
            debuggable false
            minification true
            proguardFiles "proguard-rules.pro"
            signingConfig signingConfigs.release
        }
        staging {
            debuggable true
            minification true
            versionNameSuffix "-staging"
        }
    }

    flavorDimensions "tier", "region"

    productFlavors {
        free { dimension "tier" }
        paid { dimension "tier" }
        us { dimension "region" }
        eu { dimension "region" }
    }
}

android.onVariants { variant ->
    if (variant.name.contains("Demo")) {
        variant.setEnabled(false)
    }
}

Source Sets va resurslarni bekor qilish

Har bir Build Variant o'zining source sets ierarxiyasini oladi — manba kodi, resurslar va manifest bilan kataloglar. Source set src/<variantName>/ da joylashgan (masalan, src/freeDebug/) va java/, res/, AndroidManifest.xml, assets/ ni o'z ichiga olishi mumkin. Agar fayl variant source setida mavjud bo'lsa, u asosiy source setdagi (src/main/) bir xil nomli faylni bekor qiladi. Resurslar uchun birlashtirish ishlaydi, almashtirish emas — tizim barcha faol source sets-lardan resurslarni birlashtiradi, variant-spetsifik bo'lganlarga ustunlik beradi.

Build Variant uchun source sets zanjir bo'ylab quriladi: src/main/ → src/flavor/ → src/type/ → src/flavorType/. Masalan, paidRelease uchun avval main, keyin paid, keyin release, keyin paidRelease qo'llaniladi. Har bir keyingi source set oldingisini bekor qiladi. Bu shuni anglatadiki, src/release/res/values/strings.xml src/paid/ faylidagi bir xil satrlarni bekor qiladi, lekin src/paid/release/res/ yanada ustunroqdir.

Variantlar uchun source sets ishlatish resurslarni sozlashning tavsiya etilgan usulidir. Koddagi BuildConfig.FLAVOR ni tekshirish va mantiqni tarmoqlash o'rniga, turli fayllarni turli source sets-larga joylashtirish mumkin. Masalan, free va paid versiyalari uchun piktogrammalar mos ravishda src/free/res/ va src/paid/res/ ga, turli ruxsatnomalar bilan AndroidManifest esa src/free/AndroidManifest.xml va src/paid/AndroidManifest.xml ga joylashtiriladi. Bu tozaroq, tezroq (resurslar kompilyatsiya qilinadi, runtime-da tekshirilmaydi) va xavfsizroqdir (kod xatosi tufayli tasodifan pullik funksionallikni bepul versiyaga kiritish mumkin emas).

Ko'p modulli loyihalarda Build Variant

Ko'p modulli loyihalarda har bir modul (kutubxona) o'zining Build Variants-iga ega bo'lishi mumkin. AGP variantlarni avtomatik sinxronlashtiradi: agar app moduli paidRelease-ni yig'sa, barcha bog'liq kutubxonalar ham paidRelease-ga mos keladigan variantlarida yig'iladi. Muammo kutubxonada product flavors bo'lmaganda, lekin app modulida bo'lganda yuzaga keladi — u holda kutubxona bir marta (turga qarab release yoki debug) yig'iladi.

Kutubxona modullari uchun Build Variant sukut bo'yicha app modulining Build Type bilan mos keladi, chunki kutubxonalarda product flavors mavjud emas. Agar kutubxona app modulining flavor-iga moslashishi kerak bo'lsa, kutubxonada bir xil flavorDimensions va productFlavors e'lon qilinishi kerak. AGP flavor-ni nomning to'liq mos kelishiga qarab moslashtiradi. Gradle, subprojects yoki Convention Plugins orqali ildiz loyihada flavor-larni sinxronlashtirishni tavsiya qiladi.

AGP 8.1 dan boshlab, kutubxonalar multiple variants nashr qilishi mumkin — kutubxonaning barcha variantlarini maven omboriga bir vaqtning o'zida joylashtirishi mumkin. Bu app moduli paid flavor ishlatganda, kutubxona faqat free uchun nashr qilinganda yuzaga keladigan muammoni hal qiladi. Multiple variants publishing (MVP) bog'liq loyihaga kerakli variantni avtomatik tanlash imkonini beradi. MVP-ni faollashtirish uchun kutubxonaning build.gradle fayliga publishing { multipleVariants { ... } } qo'shish kerak.

Variantlarni filtrlash va o'chirish

CI/CD orqali dinamik filtrlash

Ba'zan Build Variants-ning bir qismini o'chirish kerak bo'ladi — masalan, mockRelease kombinatsiyasi ma'nosiz bo'lsa (mock server ishlab chiqarishga tushmasligi kerak). Gradle variantFilter — DSL blokini taqdim etadi, unda har bir variantning xususiyatlarini tekshirish va setIgnore(true) orqali o'chirish mumkin. VariantFilter konfiguratsiya bosqichida, topshiriqlar yaratilishidan oldin qo'llaniladi, shuning uchun o'chirilgan variant assemble va install topshiriqlarini yaratmaydi.

Filtrlash shuningdek kompilyatsiyani tezlashtirish uchun foydalidir. Loyihada 8 variant bo'lsa va dasturchi faqat bittasi ustida ishlasa, qolgan 7 variant baribir konfiguratsiyadan (configuration phase) o'tadi. VariantFilter ishlatganda, o'chirilgan variantlar topshiriq yaratmaydi, bu 6+ flavor o'lchovli loyihalar uchun konfiguratsiya vaqtini 30-50% ga qisqartiradi. CI/CD da variantlarni buyruq satri parametrlari -PbuildOnly=paidRelease orqali dinamik filtrlash mumkin.

android {
    variantFilter { variant ->
        // Mock-ni release va demo-ni production uchun o'chiramiz
        def names = variant.flavors*.name
        def isMock = names.contains("mock")
        def isDemo = names.contains("demo")
        def isRelease = variant.buildType.name == "release"

        if ((isMock && isRelease) || (isDemo && !isMock)) {
            variant.setIgnore(true)
        }
    }
}

// Parametrlar orqali dinamik filtrlash
if (project.hasProperty("buildOnly")) {
    def target = project.property("buildOnly")
    android.variantFilter { variant ->
        variant.setIgnore(variant.name != target)
    }
}