Build Variant — bu nədir, build type və product flavor Android-də

Build Variant nədir?

Build Variant — bir Build Type və bir Product Flavor-ın kombinasiyasının nəticəsidir. Layihədə Product Flavor müəyyən edilməyibsə, Build Variant Build Type ilə üst-üstə düşür. Gradle bütün FlavorDimensions, Product Flavors və Build Types-in dekart hasilini avtomatik olaraq yaradır. Məsələn, free/paid flavor və debug/release tipləri üçün 8 variant yaradılacaq: freeDebug, freeRelease, paidDebug, paidRelease.

Hər Build Variant <Flavor><Type> formatında öz adını alır (flavor böyük hərflə). Bu variant üçün Gradle ayrıca tapşırıqlar yaradır: assembleFreeDebug, installFreeDebug, bundleFreeRelease. Android Studio-da variantlar arasında keçid Build Variants paneli (View → Tool Windows → Build Variants) vasitəsilə mümkündür. Variant seçimi hansı kodun kompilyasiya ediləcəyinə, hansı resursların daxil ediləcəyinə və hansı APK/AAB-nin yaradılacağına təsir edir.

Build Variants sistemi üç əsas vəzifəni həll edir: müxtəlif mühitlər (dev/staging/production) üçün konfiqurasiyaların ayrılması, tətbiqin çoxsaylı versiyalarının (free/paid) yaradılması və kompilyasiyaların A/B testi. Build Variants olmadan tərtibatçılar bayraqları və konfiqurasiyaları əl ilə dəyişməli olardılar ki, bu da insan faktorundan qaynaqlanan səhvlərə gətirib çıxarır. Gradle Inc., 2024 araşdırmasına görə, Build Variants-ın tətbiqi üç və daha çox yerləşdirmə mühiti olan layihələrdə kompilyasiya səhvlərinin sayını 60% azaldır.

Gradle variantları necə yaradır

AGP (Android Gradle Plugin) konfiqurasiya mərhələsində bütün kombinasiyaları hesablayır. Layihədə iki ölçü müvafiq olaraq iki və üç flavor ilə varsa, Gradle 2 × 2 × 3 = 12 kombinasiya yaradacaq, Build Types sayına (adətən 2) vurulur. Hər kombinasiya unikal ad və tapşırıqlar toplusu alır. AGP hər variant üçün avtomatik olaraq source set əlavə edir: src/freeDebug/, src/paidRelease/, həmçinin ümumiləşdirilmiş src/free/ və src/debug/. Resursların oxunma prioriteti: variant → flavor → type → main.

// Nümunə: 4 Build Variants
// flavorDimensions "version", "server"
// version: demo, prod
// server: mock, live
// buildTypes: debug, release
// Cəmi: 2 × 2 × 2 = 8 variant

android {
    flavorDimensions "version", "server"

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

Build Type və Product Flavor: fərqlər

Build Type tətbiqin necə yığılacağını müəyyən edir — sazlama məlumatı ilə və ya olmadan, optimizasiya ilə və ya olmadan, hansı imzalama ilə. Product Flavor nəyin yığılacağını müəyyən edir — məhsulun hansı versiyasını. Build Type — kompilyasiya mexanizmidir (debug, release, staging). Product Flavor — məhsul variantıdır (free, paid, enterprise, demo). Hər iki anlayış ortoqonaldır: istənilən Build Type istənilən Product Flavor-a tətbiq edilə bilər.

Build Type standart olaraq debug (debuggable=true, minification=false, signing=debug.keystore) və release (debuggable=false, minification=true, signing=production.keystore) daxildir. Product Flavor standart olaraq bir dənədir, adsız (faktiki olaraq main source set). Tərtibatçı öz Build Types (məsələn, “staging” debuggable=true və minification=true ilə) və Product Flavors əlavə edə bilər. Fərq həmçinin ondadır ki, Build Type ölçülərə qruplaşdırıla bilməz, Product Flavor isə qruplaşdırıla bilər.

Əsas praktiki fərq: build.gradle-də defaultConfig bütün Variants-a tətbiq edilir, lakin productFlavors və buildTypes-də ləğv edilə bilər. buildType-də əlavə edilmiş BuildConfigField bu tipin bütün flavor-larında görünür, productFlavor-da əlavə edilmiş isə bu flavor-un bütün tiplərində. Əgər sahə həm orada, həm də orada təyin edilibsə — buildType üstünlük təşkil edir (zəncirdə sonuncu tətbiq olunur).

Müqayisə cədvəli

Build Variants-ın build.gradle-də qurulması

Konfiqurasiyaların prioriteti

Build Variants-ın qurulması modul səviyyəsində build.gradle faylının android blokunda həyata keçirilir. Əvvəlcə buildTypes öz parametrləri ilə, sonra flavorDimensions və productFlavors elan edilir. Gradle bu elanlar əsasında avtomatik variantlar yaradır. Hər variant modulun defaultConfig-ni miras alır, müəyyən sahələri ləğv edir. Elan sırası prioritetə təsir edir: buildTypes productFlavors-dan sonra tətbiq edilir.

Gradle skriptlərində konkret Build Variant-a daxil olmaq üçün android.applicationVariants (app modulu üçün) və ya android.libraryVariants (kitabxana modulu üçün) istifadə olunur. Bu kolleksiyadır, onun üzərində iterasiya edilə və konfiqurasiya vaxtı hər variantın konfiqurasiyası dəyişdirilə bilər. Məsələn, “demo” sözünü ehtiva edən bütün variantlar üçün proqramlı olaraq buildConfigField əlavə edilə bilər.

Android Gradle Plugin 8.x, variantları lambdalar vasitəsilə qurmaq üçün onVariants — daha təmiz API dəstəyi əlavə etdi. Köhnə API (variantOutput, variantFilter) köhnəlmiş kimi qeyd edilib. Kitabxana modulları üçün onVariants ilə birlikdə onEach istifadə etmək tövsiyə olunur. AGP 7.x-dən 8.x-ə yeniləyərkən variantOutput-dan onVariants-a miqrasiya tövsiyə olunur.

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 və resursların ləğvi

Hər Build Variant öz source sets iyerarxiyasını alır — mənbə kodu, resurslar və manifest ilə qovluqlar. Source set src/<variantName>/ ünvanında yerləşir (məsələn, src/freeDebug/) və java/, res/, AndroidManifest.xml, assets/ ehtiva edə bilər. Əgər fayl variantın source set-də mövcuddursa, o, əsas source set-dən (src/main/) eyni adlı faylı ləğv edir. Resurslar üçün birləşmə işləyir, əvəz etmə yox — sistem bütün aktiv source sets-lərdən resursları birləşdirir, variant-spesifik olanlara üstünlük verir.

Build Variant üçün source sets zəncir üzrə qurulur: src/main/ → src/flavor/ → src/type/ → src/flavorType/. Məsələn, paidRelease üçün əvvəlcə main, sonra paid, sonra release, sonra paidRelease tətbiq edilir. Hər növbəti source set əvvəlkini ləğv edir. Bu o deməkdir ki, src/release/res/values/strings.xml src/paid/ faylındakı eyni sətirləri ləğv edəcək, lakin src/paid/release/res/ daha da prioritetlidir.

Variantlar üçün source sets istifadə etmək resursları fərdiləşdirməyin tövsiyə olunan üsuludur. Koddə BuildConfig.FLAVOR-u yoxlayıb məntiqi budaqlamaq əvəzinə, sadəcə müxtəlif faylları müxtəlif source sets-lərdə yerləşdirmək olar. Məsələn, free və paid versiyaları üçün ikonlar müvafiq olaraq src/free/res/ və src/paid/res/ qovluqlarına, müxtəlif icazələri olan AndroidManifest isə src/free/AndroidManifest.xml və src/paid/AndroidManifest.xml fayllarına qoyulur. Bu daha təmiz, daha sürətli (resurslar kompilyasiya olunur, runtime-da yoxlanılmır) və daha təhlükəsizdir (kodda səhvə görə təsadüfən ödənişli funksionallığı pulsuz versiyaya daxil etmək mümkün deyil).

Çoxmodullu layihələrdə Build Variant

Çoxmodullu layihələrdə hər modul (kitabxana) öz Build Variants-na malik ola bilər. AGP variantları avtomatik sinxronlaşdırır: əgər app modulu paidRelease yığırsa, bütün asılı kitabxanalar da paidRelease-ə uyğun variantlarında yığılır. Problem kitabxanada product flavors olmadıqda, lakin app modulunda olduqda yaranır — onda kitabxana bir dəfə (tipdən asılı olaraq release və ya debug) yığılır.

Kitabxana modulları üçün Build Variant standart olaraq app modulunun Build Type ilə üst-üstə düşür, çünki kitabxanalarda product flavors yoxdur. Kitabxana app modulunun flavor-na uyğunlaşmalıdırsa, kitabxanada eyni flavorDimensions və productFlavors elan edilməlidir. AGP flavor-u adın tam uyğunluğuna görə uyğunlaşdırır. Gradle, subprojects və ya Convention Plugins vasitəsilə kök layihədə flavor-ları sinxronlaşdırmağı tövsiyə edir.

AGP 8.1-dən etibarən kitabxanalar multiple variants dərc edə bilər — kitabxananın bütün variantlarını maven deposuna eyni anda yerləşdirə bilər. Bu, app modulu paid flavor istifadə etdikdə, kitabxana yalnız free üçün dərc edildikdə yaranan problemi həll edir. Multiple variants publishing (MVP) asılı layihəyə lazım olan variantı avtomatik seçməyə imkan verir. MVP-ni aktivləşdirmək üçün kitabxananın build.gradle faylına publishing { multipleVariants { ... } } əlavə etmək lazımdır.

Variantların filtrasiyası və söndürülməsi

CI/CD vasitəsilə dinamik filtrasiya

Bəzən Build Variants-ın bir hissəsini söndürmək lazım gəlir — məsələn, mockRelease kombinasiyası mənasızdırsa (mock server istehsalata düşməməlidir). Gradle variantFilter — DSL bloku təqdim edir, burada hər variantın xüsusiyyətlərini yoxlamaq və setIgnore(true) vasitəsilə söndürmək olar. VariantFilter konfiqurasiya mərhələsində, tapşırıqlar yaradılmazdan əvvəl tətbiq edilir, buna görə söndürülmüş variant assemble və install tapşırıqları yaratmır.

Filtrasiya həmçinin kompilyasiyanı sürətləndirmək üçün faydalıdır. Layihədə 8 variant varsa və tərtibatçı yalnız biri üzərində işləyirsə, qalan 7 variant yenə də konfiqurasiyadan (configuration phase) keçir. VariantFilter istifadə edərkən söndürülmüş variantlar tapşırıq yaratmır, bu da 6+ flavor ölçüsü olan layihələr üçün konfiqurasiya vaxtını 30-50% azaldır. CI/CD-də variantları əmr sətiri parametrləri -PbuildOnly=paidRelease vasitəsilə dinamik filtrasiya etmək olar.

android {
    variantFilter { variant ->
        // Mock-u release üçün və demo-nu production üçün söndürürük
        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)
        }
    }
}

// Parametrlər vasitəsilə dinamik filtrasiya
if (project.hasProperty("buildOnly")) {
    def target = project.property("buildOnly")
    android.variantFilter { variant ->
        variant.setIgnore(variant.name != target)
    }
}