Build Type — bu nədir, Gradle-də debug və release konfiqurasiyası

Build Type nədir?

Build Type — Android layihəsinin Gradle konfiqurasiyasının elementi olub, tətbiqin kompilyasiya və paketləmə parametrlərini təsvir edir. Hər Build Type adlandırılmış seçimlər dəstidir: debuggable (debug-u aktivləşdirmək), minificationEnabled (kod sıxılmasını aktivləşdirmək), shrinkResources (resurs sıxılmasını aktivləşdirmək), proguardFiles (ProGuard qayda faylları), signingConfig (imza sertifikatı) və başqaları. Build Types app modulunun build.gradle faylının android.buildTypes blokunda elan edilir.

Build Type-in əsas vəzifəsi development workflow (sürətli yığma, ətraflı loglar, debug) və production release-i (optimallaşdırılmış kod, minimal ölçü, təhlükəsizlik) ayırmaqdır. Debug yığması saniyələr ərzində yığılmalı və tərtibatçıya maksimum məlumat verməlidir. Release yığması istifadəçilər üçün maksimum sürətli və yığcam olmalıdır. Build Type — tətbiqin funksionallığı ilə əlaqəli olmayan infrastruktur konfiqurasiyadır.

Android Gradle Plugin hər Build Type üçün avtomatik source set yaradır — src/<buildType>/ kataloqu (məsələn, src/debug/, src/release/). Bu source set-ə yalnız həmin yığma tipi üçün tətbiq ediləcək resurslar, kod və manifest yerləşdirilə bilər. Məsələn, src/debug/-də ADB-dən quraşdırma icazəsi olan AndroidManifest.xml yerləşdirilə bilər, src/release/-də isə onsuz. Build Type source set-i Product Flavor source set-indən üstünlük təşkil edir.

Build Type vs Product Flavor

Əsas fərq: Build Type “necə yığmalı?” sualına cavab verir, Product Flavor isə “nə yığmalı?” sualına. Build Type debug, release, staging ola bilər. Product Flavor free, paid, enterprise ola bilər. Build Type tətbiqin funksionallığını dəyişmir (ekranları əlavə etmir və ya çıxarmır), Product Flavor dəyişir. Build Type debug-u söndürüb obfuskasiyanı aktivləşdirə bilər, Product Flavor applicationId və resursları dəyişə bilər. Hər ikisi cütlükdə işləyir: hər Build Type hər Product Flavor ilə birləşərək Build Variant yaradır.

Standart Build Types: debug və release

Debug — AGP tərəfindən defolt yaradılan Build Type-dir. O, debuggable=true aktivləşdirir ki, bu da debuger qoşmağa, Log.d loglarına baxmağa və Android Studio profilerindən istifadə etməyə imkan verir. Minification söndürülüb, ona görə yığma sürətli olur. Debug yığmasında applicationId ".debug" suffiksi alır (əgər dəyişdirilməyibsə), bu, debug versiyasını release ilə eyni cihazda paralel quraşdırmağa imkan verir. Debug Android SDK tərəfindən avtomatik yaradılan debug.keystore sertifikatı ilə imzalanır.

Release — tətbiqin nəşri üçün Build Type-dir. debuggable=false, minificationEnabled=true (defolt), shrinkResources=true. Tərtibatçı signingConfig-də production sertifikatını göstərməlidir — əks halda yığma release hesab edilməyəcək. Release kodun obfuskasiyası, optimallaşdırılması və sıxılması üçün ProGuard və ya R8 istifadə edir. Android Studio release yığmasına debuger qoşa bilməz (əgər debuggable=false). Bütün Log.d və Log.v çağırışları müvafiq ProGuard qaydaları konfiqurasiya edilibsə, minification mərhələsində koddan silinir.

Vacib: debug yığmaları release davranışını test etmir. Minification kodun davranışını dəyişə bilər — reflection, serializasiya, Gson/SQLite və digər kitabxanalar tez-tez ProGuard qaydaları tələb edir. Buna görə nəşrdən əvvəl mütləq release yığmasını qurub test etmək lazımdır. Google Play Console və Firebase Test Lab nəşrdən əvvəl real cihazlarda avtomatik test üçün release yığmalarını yükləməyə imkan verir.

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

Xüsusi Build Types yaratmaq

initWith vasitəsilə miras

Debug və release-ə əlavə olaraq öz Build Types-lər yarada bilərsiniz — məsələn staging (aralıq mühit) və ya benchmark (performans testləri üçün). Xüsusi Build Type debug və release kimi buildTypes blokunda elan edilir. Ad istənilən ola bilər, amma ingilis dilində semantik başa düşülən adlardan istifadə etmək tövsiyə olunur. Staging üçün adətən debuggable=true (staging mühitində problemlərin diaqnostikası üçün) və minification=true (production-a qədər obfuskasiyanı test etmək üçün) qoyulur.

Xüsusi Build Type avtomatik müvafiq source set (src/staging/) alır və assembleStaging tipli tapşırıqlar yaradır. AGP xüsusi tiplərin sayına məhdudiyyət qoymur, amma hər yeni tip Build Variants sayını artırır. Praktik hədd — 4-5 Build Types: debug, staging, benchmark, release və bəlkə də debugMinified (ProGuard qaydalarını test etmək üçün minification aktivləşdirilmiş debug).

Xüsusi Build Type üçün debuggable-i debug-dan initWith vasitəsilə miras almaq olar. initWith açar sözü göstərilən Build Type-in bütün parametrlərini kopyalayır, sonra onları dəyişdirmək olar. Bu, staging-i debug əsasında yaratmaq üçün əlverişlidir: initWith debug + əlavə minification aktivləşdirmək. initWith olmadan baza tipinin bütün parametrlərini əl ilə sadalamaq lazım gələrdi.

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 tipi olmayan kitabxanalar üçün
// kitabxanada yalnız release varsa — AGP ondan istifadə edir

Müxtəlif yığma tipləri üçün imza konfiqurasiyası

SigningConfig APK və ya AAB-in hansı sertifikatla imzalanacağını müəyyən edir. Android bütün quraşdırılan tətbiqlərin imzalanmasını tələb edir — onsuz sistem APK-nı quraşdırmağa icazə verməz. Debug yığmaları üçün AGP debug.keystore-dan istifadə edir — Android SDK Tools tərəfindən yaradılan, məlum parollu əvvəlcədən quraşdırılmış sertifikat. Release yığmaları üçün Android Studio (Build → Generate Signed Bundle/APK) və ya keytool əmr sətri vasitəsilə öz sertifikatınızı yaratmalısınız.

İmza açarlarının saxlanması — kritik təhlükəsizlik məsələsidir. Release açarlarını saxlamamaq tövsiyə olunur mənbə kodu deposunda. Bunun əvəzinə istifadə olunur: keystore.properties faylı (.gitignore-a əlavə edilib), CI/CD mühit dəyişənləri və ya Android Studio-nun şifrələnmiş anbarı. CI/CD-də (GitHub Actions, GitLab CI) imza açarları secrets-də saxlanılır və build.gradle-a sistem xassələri vasitəsilə ötürülür. Nümunə: storePassword = System.getenv("KEYSTORE_PASSWORD").

Hər Build Type öz signingConfig-ə istinad edə bilər. Release üçün — production sertifikatı, debug üçün — debug.keystore, staging üçün — ayrıca staging sertifikatı. İmza konfiqurasiyası birbaşa tətbiqin quraşdırılması imkanına təsir edir: əgər debug debug.keystore ilə, staging isə production açarı ilə imzalanıbsa, staging debug versiyası üzərində imza uyğunsuzluğu səbəbindən quraşdırıla bilməz. ApplicationId də fərqli olmalıdır — bunun üçün applicationIdSuffix istifadə olunur.

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 və R8

Resource Shrinking

Minification — istifadə olunmayan kodun silinməsi və siniflərin, metodların, sahələrin adlarının qısaldılması prosesidir. AGP minification-ı ProGuard (köhnəlmiş) və ya R8 (tövsiyə olunur, AGP 3.4 versiyasından daxildir) vasitəsilə həyata keçirir. R8 dörd əməliyyat yerinə yetirir: shrinking (istifadə olunmayan siniflərin silinməsi), optimisation (kodun sadələşdirilməsi), obfuscation (adların dəyişdirilməsi) və preverify (uyğunluq məlumatının əlavə edilməsi). Nəticə — daha kiçik ölçülü APK, onu dekompilasiya etmək çətindir.

Minification qaydaları ProGuard rules files-da müəyyən edilir — -keep, -dontwarn, -keepclassmembers sintaksisi olan mətn faylları. Qaydalar olmadan R8 reflection (Gson, Retrofit, Room, Kotlin serialization) vasitəsilə istifadə olunan sinifləri siləcək və ya adlarını dəyişəcək. Android Studio layihə şablonu proguard-rules.pro yaradır, oraya konkret kitabxanalar üçün qaydalar əlavə edilir. Kitabxanalar da daxili qaydalar ehtiva edə bilər — onlar avtomatik jar/aar-dan qoşulur.

Shrink resources (shrinkResources=true) APK-dan istifadə olunmayan resursları silir. R8 əvvəlcə hansı resursların koddan istifadə edilmədiyini müəyyən edir (R.java və manifestdə istinadları yoxlayır), sonra onları son yığmadan silir. getIdentifier() və ya üçüncü tərəf kitabxanaları vasitəsilə istifadə olunan resurslar üçün resurslarda tools:keep="@layout/my_layout" əlavə etmək lazımdır. Minification ilə birlikdə resource shrinking APK ölçüsünü 40-60% azalda bilər.

# proguard-rules.pro — məcburi qaydalar
# Gson: serializasiya üçün sinifləri saxla
-keepclassmembers class com.example.** {
    <fields>;
}

# Retrofit: API interfeyslərini saxla
-keep,allowobfuscation interface com.example.api.*

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

# Kotlin Coroutines: Continuation silinməsinin qarşısını al
-keepnames class kotlinx.coroutines.internal.*

# OkHttp: service loader-ı saxla
-keep class okhttp3.** { *; }

Build Type üçün BuildConfigField və resurslar

BuildConfig — defaultConfig, productFlavors və buildTypes-də müəyyən edilmiş sabitləri ehtiva edən avtomatik yaradılan Java/Kotlin sinifidir. buildConfigField vasitəsilə xüsusi sahələr əlavə etmək olar: buildConfigField "String", "API_URL", '"https://api.example.com"'. buildType-də elan edilmiş BuildConfigField bu tipin bütün variantlarında əlçatandır. buildType-dəki dəyərlər productFlavor-dakı dəyərləri, onlar da öz növbəsində defaultConfig-i ləğv edir.

Debug yığmaları üçün API_URL-i localhost və ya staging serverinə, release üçün isə production-a təyin etmək rahatdır. BuildConfig.FLAVOR və BuildConfig.BUILD_TYPE də avtomatik yaradılır və cari flavor və build type adını ehtiva edir. Koddan istifadə etmək olar: if (BuildConfig.DEBUG) { /* loglar */ } — DEBUG sabiti yalnız debug build type üçün true-dur. BuildConfig.DEBUG — AGP-nin hər BuildConfig-ə əlavə etdiyi standart sahədir.

Build Type üçün resurslar src/<buildType>/res/ source set-i vasitəsilə təyin edilir. Məsələn, src/debug/res/values/strings.xml “Server: Dev” mətnini, src/release/res/ isə “Server: Prod” mətnini ehtiva edə bilər. Manifest resursları da source set vasitəsilə ləğv edilir: src/debug/AndroidManifest.xml yalnız debug yığmaları üçün <uses-permission android:name="android.permission.INTERNET" /> daxil edə bilər. Bu, koddakı BuildConfig yoxlamasından daha təmizdir və proqramla təyin edilə bilməyən atributlar (məsələn, networkSecurityConfig) üçün də işləyir.

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

// İstifadə: əsas sinif Config-i reflection vasitəsilə yükləyir
fun getConfig(): AppConfig = when (BuildConfig.BUILD_TYPE) {
    "debug" -> DebugConfig
    else -> ReleaseConfig
}