Build Type — co to je, konfigurace debug a release v Gradle

Co je Build Type?

Build Type je prvek konfigurace Gradle projektu Android, který popisuje parametry kompilace a balení aplikace. Každý Build Type představuje pojmenovanou sadu možností: debuggable (povolit ladění), minificationEnabled (povolit kompresi kódu), shrinkResources (povolit kompresi zdrojů), proguardFiles (soubory pravidel ProGuard), signingConfig (podpisový certifikát) a další. Build Types jsou deklarovány v bloku android.buildTypes souboru build.gradle modulu app.

Hlavním úkolem Build Type je oddělení development workflow (rychlé sestavení, podrobné logy, ladění) a production release (optimalizovaný kód, minimální velikost, bezpečnost). Debug sestavení by mělo být hotovo během sekund a poskytovat vývojáři maximum informací. Release sestavení by mělo být pro uživatele co nejrychlejší a nejkompaktnější. Build Type je infrastrukturní konfigurace, která nesouvisí s funkčností aplikace.

Android Gradle Plugin automaticky vytváří source set pro každý Build Type — adresář src/<buildType>/ (například src/debug/, src/release/). Do tohoto source set lze umístit zdroje, kód a manifest, které se použijí pouze pro daný typ sestavení. Například do src/debug/ lze umístit AndroidManifest.xml s oprávněním pro instalaci z ADB, do src/release/ — bez něj. Source set Build Type má prioritu před source set Product Flavor.

Build Type vs Product Flavor

Klíčový rozdíl: Build Type odpovídá na otázku „jak sestavit?", zatímco Product Flavor — na otázku „co sestavit?". Build Type může být debug, release, staging. Product Flavor může být free, paid, enterprise. Build Type nemění funkčnost aplikace (nepřidává ani neodebírá obrazovky), Product Flavor — mění. Build Type může vypnout ladicí nástroj a zapnout obfuskaci, Product Flavor může změnit applicationId a zdroje. Oba pracují v páru: každý Build Type se kombinuje s každým Product Flavor a tvoří Build Variant.

Standardní Build Types: debug a release

Debug je Build Type vytvářený AGP ve výchozím nastavení. Obsahuje debuggable=true, což umožňuje připojení debuggeru, prohlížení logů Log.d a použití profilovacího nástroje Android Studio. Minification je vypnuto, takže sestavení je rychlé. V debug sestavení získává applicationId příponu „.debug" (pokud není přepsána), což umožňuje nainstalovat debug verzi souběžně s release verzí na stejném zařízení. Debug je podepsán certifikátem z debug.keystore, který je automaticky vytvořen Android SDK.

Release je Build Type pro publikaci aplikace. debuggable=false, minificationEnabled=true (výchozí), shrinkResources=true. Vývojář musí uvést signingConfig s produkčním certifikátem — jinak sestavení není považováno za release. Release používá ProGuard nebo R8 pro obfuskaci, optimalizaci a kompresi kódu. Android Studio nemůže připojit debugger k release sestavení (pokud debuggable=false). Všechna volání Log.d a Log.v jsou odstraněna z kódu ve fázi minification, pokud jsou nakonfigurována příslušná pravidla ProGuard.

Důležité: debug sestavení netestují chování release. Minification může změnit chování kódu — reflexe, serializace, Gson/SQLite a další knihovny často vyžadují pravidla ProGuard. Proto před publikací vždy vytvořte release sestavení a otestujte ho. Google Play Console a Firebase Test Lab umožňují nahrávat release sestavení pro automatické testování na reálných zařízeních před publikací.

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

Vytváření vlastních Build Types

Dědění pomocí initWith

Kromě debug a release můžete vytvářet vlastní Build Types — například staging (přechodné prostředí) nebo benchmark (pro testy výkonu). Vlastní Build Type je deklarován v bloku buildTypes stejně jako debug a release. Název může být libovolný, ale doporučuje se používat sémanticky srozumitelné názvy v angličtině. Pro staging se obvykle nastavuje debuggable=true (pro diagnostiku problémů v staging prostředí) a minification=true (pro testování obfuskace před produkcí).

Vlastní Build Type automaticky získá odpovídající source set (src/staging/) a generuje úlohy typu assembleStaging. AGP neomezuje počet vlastních typů, ale každý nový typ násobí počet Build Variants. Praktický limit je 4-5 Build Types: debug, staging, benchmark, release a případně debugMinified (debug s povolenou minification pro testování pravidel ProGuard).

Pro vlastní Build Type lze debuggable zdědit z debug pomocí initWith. Klíčové slovo initWith zkopíruje všechny parametry zadaného Build Type, které pak lze přepsat. To je užitečné pro vytvoření staging na základě debug: initWith debug + dodatečné povolení minification. Bez initWith by bylo nutné ručně vyjmenovat všechny parametry základního typu.

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 — pro knihovny, které nemají benchmark typ
// pokud knihovna má pouze release — AGP jej použije

Konfigurace podpisu pro různé typy sestavení

SigningConfig určuje, jakým certifikátem je podepsán APK nebo AAB. Android vyžaduje podpis všech instalovatelných aplikací — bez něj systém nepovolí instalaci APK. Pro debug sestavení AGP používá debug.keystore — předinstalovaný certifikát se známým heslem, generovaný Android SDK Tools. Pro release sestavení je třeba vytvořit vlastní certifikát pomocí Android Studio (Build → Generate Signed Bundle/APK) nebo příkazem keytool.

Ukládání podpisových klíčů je kritický aspekt bezpečnosti. Doporučuje se neukládat release klíče v repozitáři zdrojového kódu. Místo toho se používají: soubor keystore.properties (přidaný do .gitignore), proměnné prostředí CI/CD nebo šifrované úložiště Android Studio. V CI/CD (GitHub Actions, GitLab CI) jsou podpisové klíče uloženy v secrets a předávány do build.gradle prostřednictvím systémových vlastností. Příklad: storePassword = System.getenv("KEYSTORE_PASSWORD").

Každý Build Type může odkazovat na svůj vlastní signingConfig. Pro release — produkční certifikát, pro debug — debug.keystore, pro staging — samostatný staging certifikát. Konfigurace podpisu přímo ovlivňuje možnost instalace aplikace: pokud je debug podepsán debug.keystore a staging produkčním klíčem, staging nelze nainstalovat přes debug verzi kvůli neshodě podpisů. ApplicationId musí být také odlišné — k tomu slouží 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 a R8

Resource Shrinking

Minification je proces odstraňování nepoužitého kódu a přejmenování tříd, metod a polí na krátká jména. AGP provádí minification pomocí ProGuard (zastaralý) nebo R8 (doporučený, vestavěný v AGP od verze 3.4). R8 provádí čtyři operace: shrinking (odstranění nepoužívaných tříd), optimisation (zjednodušení kódu), obfuscation (přejmenování) a preverify (přidání informací o kompatibilitě). Výsledkem je APK menší velikosti, který je obtížnější dekompilovat.

Pravidla minification jsou definována v ProGuard rules files — textových souborech se syntaxí -keep, -dontwarn, -keepclassmembers. Bez pravidel R8 odstraní nebo přejmenuje třídy používané prostřednictvím reflexe (Gson, Retrofit, Room, Kotlin serialization). Šablona projektu Android Studio vytváří proguard-rules.pro, do kterého se přidávají pravidla pro konkrétní knihovny. Knihovny mohou také obsahovat vestavěná pravidla — ta jsou automaticky připojena z jar/aar.

Shrink resources (shrinkResources=true) odstraňuje nepoužité zdroje z APK. R8 nejprve určí, které zdroje nejsou v kódu použity (kontroluje R.java a odkazy v manifestu), poté je odstraní z finálního sestavení. Pro zdroje používané prostřednictvím getIdentifier() nebo knihovnami třetích stran je třeba přidat tools:keep="@layout/my_layout" do zdrojů. V kombinaci s minification může resource shrinking zmenšit velikost APK o 40-60%.

# proguard-rules.pro — povinná pravidla
# Gson: zachovat třídy pro serializaci
-keepclassmembers class com.example.** {
    <fields>;
}

# Retrofit: zachovat API rozhraní
-keep,allowobfuscation interface com.example.api.*

# Room: zachovat DAO a Entity
-keep class * extends androidx.room.RoomDatabase
-keep @interface androidx.room.** { *; }

# Kotlin Coroutines: zabránit odstranění Continuation
-keepnames class kotlinx.coroutines.internal.*

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

BuildConfigField a zdroje pro Build Type

BuildConfig je automaticky generovaná třída Java/Kotlin, která obsahuje konstanty definované v defaultConfig, productFlavors a buildTypes. Prostřednictvím buildConfigField lze přidat vlastní pole: buildConfigField "String", "API_URL", '"https://api.example.com"'. BuildConfigField deklarovaný v buildType je k dispozici ve všech variantách tohoto typu. Hodnoty v buildType přepisují hodnoty z productFlavor, které zase přepisují defaultConfig.

Pro debug sestavení je vhodné nastavit API_URL na localhost nebo staging server, pro release — na production. BuildConfig.FLAVOR a BuildConfig.BUILD_TYPE jsou také automaticky generovány a obsahují název aktuálního flavor a build type. V kódu lze použít: if (BuildConfig.DEBUG) { /* logy */ } — konstanta DEBUG je true pouze pro debug build type. BuildConfig.DEBUG je standardní pole, které AGP přidává do každého BuildConfig.

Zdroje pro Build Type jsou definovány prostřednictvím source set src/<buildType>/res/. Například src/debug/res/values/strings.xml může obsahovat text „Server: Dev", zatímco src/release/res/ — „Server: Prod". Zdroje manifestu jsou také přepisovány prostřednictvím source set: src/debug/AndroidManifest.xml může obsahovat <uses-permission android:name="android.permission.INTERNET" /> pouze pro debug sestavení. To je čistší než kontrola BuildConfig v kódu a funguje dokonce i pro atributy, které nelze nastavit programově (například 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
}

// Použití: hlavní třída načítá Config pomocí reflexe
fun getConfig(): AppConfig = when (BuildConfig.BUILD_TYPE) {
    "debug" -> DebugConfig
    else -> ReleaseConfig
}