Build Type — mi ez, debug és release konfiguráció a Gradle-ban

Mi az a Build Type?

Build Type az Android-projekt Gradle-konfigurációjának egy eleme, amely leírja az alkalmazás fordításának és csomagolásának paramétereit. Minden Build Type egy elnevezett opciókészlet: debuggable (hibakeresés engedélyezése), minificationEnabled (kódkompresszió engedélyezése), shrinkResources (erőforrás-kompresszió engedélyezése), proguardFiles (ProGuard szabályfájlok), signingConfig (aláíró tanúsítvány) és mások. A Build Types az app modul build.gradle fájljának android.buildTypes blokkjában kerülnek deklarálásra.

A Build Type fő feladata a development workflow (gyors build, részletes naplók, hibakeresés) és a production release (optimalizált kód, minimális méret, biztonság) szétválasztása. A debug build-nek másodpercek alatt el kell készülnie, és maximális információt kell nyújtania a fejlesztőnek. A release build-nek a lehető leggyorsabbnak és legkompaktabbnak kell lennie a felhasználók számára. A Build Type egy infrastrukturális konfiguráció, amely nem kapcsolódik az alkalmazás funkcionalitásához.

Az Android Gradle Plugin automatikusan létrehoz egy source set-et minden Build Type-hoz — a src/<buildType>/ könyvtárat (például src/debug/, src/release/). Ebbe a source set-be olyan erőforrások, kód és manifest helyezhető, amelyek csak az adott build típusra vonatkoznak. Például az src/debug/-ban elhelyezhető egy AndroidManifest.xml az ADB-ből történő telepítés engedélyével, az src/release/-ben pedig anélkül. A Build Type source set elsőbbséget élvez a Product Flavor source set felett.

Build Type vs Product Flavor

A legfontosabb különbség: a Build Type arra a kérdésre válaszol, hogy „hogyan építsünk?", a Product Flavor pedig arra, hogy „mit építsünk?". A Build Type lehet debug, release, staging. A Product Flavor lehet free, paid, enterprise. A Build Type nem változtatja meg az alkalmazás funkcionalitását (nem ad hozzá és nem távolít el képernyőket), a Product Flavor viszont igen. A Build Type kikapcsolhatja a debugger-t és bekapcsolhatja az obfuskációt, a Product Flavor megváltoztathatja az applicationId-t és az erőforrásokat. Mindkettő párban működik: minden Build Type minden Product Flavor-ral kombinálódik, létrehozva a Build Variant-ot.

Szabványos Build Types: debug és release

Debug az AGP által alapértelmezetten létrehozott Build Type. Tartalmazza a debuggable=true-t, ami lehetővé teszi a debugger csatlakoztatását, a Log.d naplók megtekintését és az Android Studio profiler használatát. A minification ki van kapcsolva, így a build gyors. A debug build-ben az applicationId megkapja a „.debug" utótagot (ha nem lett felülírva), ami lehetővé teszi a debug verzió párhuzamos telepítését a release verzióval ugyanazon az eszközön. A debug az Android SDK által automatikusan létrehozott debug.keystore tanúsítvánnyal van aláírva.

Release az alkalmazás publikálására szolgáló Build Type. debuggable=false, minificationEnabled=true (alapértelmezett), shrinkResources=true. A fejlesztőnek meg kell adnia a signingConfig-ot a production tanúsítvánnyal — különben a build nem tekinthető release-nek. A Release a ProGuard-ot vagy R8-at használja a kód obfuskációjához, optimalizálásához és kompressziójához. Az Android Studio nem tud debugger-t csatlakoztatni a release build-hez (ha debuggable=false). Az összes Log.d és Log.v hívás eltávolításra kerül a kódbol a minification fázisban, ha a megfelelő ProGuard szabályok konfigurálva vannak.

Fontos: a debug buildek nem tesztelik a release viselkedését. A minification megváltoztathatja a kód viselkedését — a reflection, szerializáció, Gson/SQLite és más könyvtárak gyakran igényelnek ProGuard szabályokat. Ezért publikálás előtt feltétlenül készítsen release build-et és tesztelje azt. A Google Play Console és a Firebase Test Lab lehetővé teszi a release buildek feltöltését automatikus teszteléshez valós eszközökön a publikálás előtt.

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

Egyéni Build Types létrehozása

Öröklés initWith segítségével

A debug és release mellett létrehozhat saját Build Types-okat is — például staging (átmeneti környezet) vagy benchmark (teljesítménytesztekhez). Az egyéni Build Type a buildTypes blokkban deklarálható, akárcsak a debug és release. A név tetszőleges lehet, de ajánlott szemantikailag érthető angol elnevezéseket használni. A staging esetében általában debuggable=true (a staging környezet problémáinak diagnosztizálásához) és minification=true (az obfuskáció teszteléséhez a production előtt) van beállítva.

Az egyéni Build Type automatikusan megkapja a megfelelő source set-et (src/staging/), és olyan feladatokat generál, mint az assembleStaging. Az AGP nem korlátozza az egyéni típusok számát, de minden új típus megsokszorozza a Build Variants számát. A gyakorlati korlát 4-5 Build Types: debug, staging, benchmark, release és esetleg debugMinified (debug bekapcsolt minification-nel a ProGuard szabályok teszteléséhez).

Az egyéni Build Type esetében a debuggable örökölhető a debug-ból az initWith segítségével. Az initWith kulcsszó lemásolja a megadott Build Type összes paraméterét, amelyek azután felülírhatók. Ez hasznos a staging debug alapú létrehozásához: initWith debug + kiegészítő minification bekapcsolása. Az initWith nélkül manuálisan kellene felsorolni az alaptípus összes paraméterét.

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 — olyan könyvtárakhoz, amelyeknek nincs benchmark típusa
// ha a könyvtárnak csak release van — az AGP azt használja

Aláírási konfiguráció különböző build típusokhoz

SigningConfig határozza meg, hogy milyen tanúsítvánnyal van aláírva az APK vagy AAB. Az Android megköveteli az összes telepíthető alkalmazás aláírását — enélkül a rendszer nem engedélyezi az APK telepítését. A debug buildekhez az AGP a debug.keystore-t használja — egy előre telepített, ismert jelszavú tanúsítványt, amelyet az Android SDK Tools generál. A release buildekhez saját tanúsítványt kell létrehoznia az Android Studio (Build → Generate Signed Bundle/APK) vagy a keytool parancs segítségével.

Az aláírási kulcsok tárolása kritikus biztonsági szempont. Javasolt nem tárolni a release kulcsokat a forráskód tárolójában. Ehelyett a következők használatosak: keystore.properties fájl (hozzáadva a .gitignore-hoz), CI/CD környezeti változók, vagy az Android Studio titkosított tárolója. CI/CD-ben (GitHub Actions, GitLab CI) az aláírási kulcsok titkosított változókban (secrets) tárolódnak, és rendszertulajdonságokon keresztül kerülnek átadásra a build.gradle-nek. Példa: storePassword = System.getenv("KEYSTORE_PASSWORD").

Minden Build Type hivatkozhat a saját signingConfig-jára. Release esetén — production tanúsítvány, debug esetén — debug.keystore, staging esetén — külön staging tanúsítvány. Az aláírási konfiguráció közvetlenül befolyásolja az alkalmazás telepíthetőségét: ha a debug debug.keystore-ral van aláírva, a staging pedig production kulccsal, a staging nem telepíthető a debug verzió fölé az aláírások eltérése miatt. Az applicationId-nak is eltérőnek kell lennie — ehhez az applicationIdSuffix használatos.

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 és R8

Resource Shrinking

Minification a nem használt kód eltávolításának, valamint az osztályok, metódusok és mezők rövid névre keresztelésének folyamata. Az AGP a minification-t ProGuard (elavult) vagy R8 (ajánlott, AGP 3.4 verziótól beépített) segítségével végzi. Az R8 négy műveletet hajt végre: shrinking (nem használt osztályok eltávolítása), optimisation (kód egyszerűsítése), obfuscation (átnevezés) és preverify (kompatibilitási információk hozzáadása). Eredmény — kisebb méretű APK, amelyet nehezebb dekompilálni.

A minification szabályok a ProGuard rules files-ban vannak meghatározva — -keep, -dontwarn, -keepclassmembers szintaxisú szöveges fájlokban. Szabályok nélkül az R8 eltávolítja vagy átnevezi a reflection (Gson, Retrofit, Room, Kotlin serialization) által használt osztályokat. Az Android Studio projektsablon létrehozza a proguard-rules.pro-t, amelyhez az egyes könyvtárakra vonatkozó szabályok adhatók hozzá. A könyvtárak beépített szabályokat is tartalmazhatnak — ezek automatikusan csatlakoztatásra kerülnek a jar/aar-ból.

Shrink resources (shrinkResources=true) eltávolítja a nem használt erőforrásokat az APK-ból. Az R8 először meghatározza, hogy mely erőforrások nem használatosak a kódban (ellenőrzi az R.java-t és a manifest hivatkozásokat), majd eltávolítja azokat a végleges build-ből. A getIdentifier() vagy harmadik féltől származó könyvtárak által használt erőforrások esetében tools:keep="@layout/my_layout" hozzáadása szükséges az erőforrásokhoz. A minification-nel kombinálva a resource shrinking 40-60%-kal csökkentheti az APK méretét.

# proguard-rules.pro — kötelező szabályok
# Gson: osztályok megőrzése szerializációhoz
-keepclassmembers class com.example.** {
    <fields>;
}

# Retrofit: API interfészek megőrzése
-keep,allowobfuscation interface com.example.api.*

# Room: DAO és Entity megőrzése
-keep class * extends androidx.room.RoomDatabase
-keep @interface androidx.room.** { *; }

# Kotlin Coroutines: a Continuation eltávolításának megakadályozása
-keepnames class kotlinx.coroutines.internal.*

# OkHttp: service loader megőrzése
-keep class okhttp3.** { *; }

BuildConfigField és erőforrások a Build Type-hoz

BuildConfig egy automatikusan generált Java/Kotlin osztály, amely a defaultConfig, productFlavors és buildTypes által meghatározott konstansokat tartalmazza. A buildConfigField segítségével egyéni mezők adhatók hozzá: buildConfigField "String", "API_URL", '"https://api.example.com"'. A buildType-ben deklarált BuildConfigField a típus összes változatában elérhető. A buildType-ben lévő értékek felülírják a productFlavor-ból származó értékeket, amelyek viszont felülírják a defaultConfig-ot.

Debug buildek esetén kényelmes az API_URL beállítása localhost-ra vagy staging szerverre, release esetén pedig production-re. A BuildConfig.FLAVOR és BuildConfig.BUILD_TYPE szintén automatikusan generálódik, és tartalmazza az aktuális flavor és build type nevét. A kódban használható: if (BuildConfig.DEBUG) { /* naplók */ } — a DEBUG konstans csak a debug build type esetén true. A BuildConfig.DEBUG egy szabványos mező, amelyet az AGP minden BuildConfig-hoz hozzáad.

A Build Type-hoz tartozó erőforrások a src/<buildType>/res/ source set-en keresztül definiálhatók. Például az src/debug/res/values/strings.xml tartalmazhatja a „Server: Dev" szöveget, az src/release/res/ pedig a „Server: Prod" szöveget. A manifest erőforrások is felülírhatók a source set-en keresztül: az src/debug/AndroidManifest.xml csak a debug buildek számára tartalmazhat <uses-permission android:name="android.permission.INTERNET" /> elemet. Ez tisztább, mint a BuildConfig ellenőrzése a kódban, és olyan attribútumok esetében is működik, amelyek nem állíthatók be programozottan (például 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
}

// Használat: a fő osztály a Config-ot reflection segítségével tölti be
fun getConfig(): AppConfig = when (BuildConfig.BUILD_TYPE) {
    "debug" -> DebugConfig
    else -> ReleaseConfig
}