Build Type — шта је то, конфигурација debug и release у Gradle-у

Шта је Build Type?

Build Type је елемент Gradle конфигурације Android пројекта који описује параметре компилације и паковања апликације. Сваки Build Type представља именовани скуп опција: debuggable (укључити отклањање грешака), minificationEnabled (укључити компресију кода), shrinkResources (укључити компресију ресурса), proguardFiles (датотеке правила ProGuard), signingConfig (сертификат потписа) и друге. Build Types се декларишу у блоку android.buildTypes датотеке build.gradle модула app.

Главни задатак Build Type-а је раздвајање development workflow (брза градња, детаљни дневници, отклањање грешака) и production release (оптимизован код, минимална величина, безбедност). Debug верзија треба да се гради у секундама и пружи максимум информација програмеру. Release верзија треба да буде максимално брза и компактна за кориснике. Build Type је инфраструктурно подешавање, које није везано за функционалност апликације.

Android Gradle Plugin аутоматски креира source set за сваки Build Type — директоријум src/<buildType>/ (на пример, src/debug/, src/release/). У овај source set се могу сместити ресурси, код и манифест који ће се примењивати само за дати тип градње. На пример, у src/debug/ се може поставити AndroidManifest.xml са дозволом за инсталацију из ADB, а у src/release/ — без ње. Source set Build Type-а има приоритет над source set Product Flavor-а.

Build Type vs 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 је Build Type који AGP креира подразумевано. Он укључује debuggable=true, што омогућава повезивање отклањача грешака, преглед дневника Log.d и коришћење профилера Android Studio. Minification је искључен, па је градња брза. У debug верзији, applicationId добија суфикс “.debug” (ако није преиначен), што омогућава инсталацију debug верзије упоредо са release верзијом на истом уређају. Debug верзија се потписује сертификатом из debug.keystore, који аутоматски креира Android SDK.

Release је Build Type за објављивање апликације. debuggable=false, minificationEnabled=true (подразумевано), shrinkResources=true. Програмер мора навести signingConfig са production сертификатом — иначе се верзија неће сматрати release. Release користи ProGuard или R8 за обфускацију, оптимизацију и компресију кода. Android Studio не може да се повеже отклањачем грешака на release верзију (ако је debuggable=false). Сви позиви Log.d и Log.v се уклањају из кода у фази minification, ако су подешена одговарајућа ProGuard правила.

Важно: 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 (debug са укљученом minification за тестирање ProGuard правила).

За прилагођени Build Type, debuggable се може наследити од debug-а користећи initWith. Кључна реч initWith копира све параметре наведеног Build Type-а, након чега се они могу преиначити. Ово је згодно за креирање staging-а на основу debug-а: 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 захтева потписивање свих инсталабилних апликација — без тога систем неће дозволити инсталацију APK-а. За 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 — production сертификат, за debug — debug.keystore, за staging — посебан staging сертификат. Конфигурација потписивања директно утиче на могућност инсталације апликације: ако је debug потписан debug.keystore-ом, а staging production кључем, staging се не може инсталирати преко debug верзије због неусклађености потписа. 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 извршава minification помоћу ProGuard-а (застарео) или R8 (препоручује се, уграђен у AGP од верзије 3.4). R8 обавља четири операције: shrinking (уклањање некоришћених класа), optimisation (поједностављивање кода), obfuscation (преименовање) и preverify (додавање информација о компатибилности). Резултат — APK мање величине који је теже декомпајлирати.

Правила minification-а се дефинишу у ProGuard rules files — текстуалним датотекама са синтаксом -keep, -dontwarn, -keepclassmembers. Без правила, R8 ће уклонити или преименовати класе које се користе путем reflection-а (Gson, Retrofit, Room, Kotlin serialization). Шаблон пројекта 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"'. BuildConfigField декларисан у buildType доступан је у свим варијантама овог типа. Вредности у buildType преписују вредности из productFlavor-а, које заузврат преписују defaultConfig.

За debug верзије је згодно подесити API_URL на localhost или staging сервер, а за release — на production. BuildConfig.FLAVOR и BuildConfig.BUILD_TYPE се такође аутоматски генеришу и садрже назив тренутног flavor-а и build type-а. У коду се може користити: if (BuildConfig.DEBUG) { /* дневници */ } — константа DEBUG је true само за debug build type. BuildConfig.DEBUG је стандардно поље које AGP додаје у сваки BuildConfig.

Ресурси за Build Type се дефинишу путем source set-а src/<buildType>/res/. На пример, src/debug/res/values/strings.xml може садржати текст “Server: Dev”, а src/release/res/ — “Server: Prod”. Ресурси манифеста се такође преписују путем source set-а: src/debug/AndroidManifest.xml може укључити <uses-permission android:name="android.permission.INTERNET" /> само за debug верзије. Ово је чистије од провере 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
}

// Коришћење: главна класа учитава Config путем reflection
fun getConfig(): AppConfig = when (BuildConfig.BUILD_TYPE) {
    "debug" -> DebugConfig
    else -> ReleaseConfig
}