Build Type — vad är det, konfiguration av debug och release i Gradle

Vad är Build Type?

Build Type är ett element i Gradle-konfigurationen för ett Android-projekt som beskriver parametrarna för kompilering och paketering av applikationen. Varje Build Type är en namngiven uppsättning alternativ: debuggable (aktivera felsökning), minificationEnabled (aktivera kodkomprimering), shrinkResources (aktivera resurskomprimering), proguardFiles (ProGuard-regelfiler), signingConfig (signeringscertifikat) och andra. Build Types deklareras i android.buildTypes-blocket i build.gradle-filen för app-modulen.

Huvuduppgiften för Build Type är att separera development workflow (snabb bygg, detaljerade loggar, felsökning) och production release (optimerad kod, minimal storlek, säkerhet). Debug-bygget bör ske på några sekunder och ge utvecklaren maximal information. Release-bygget bör vara så snabbt och kompakt som möjligt för användarna. Build Type är en infrastrukturell konfiguration som inte är relaterad till applikationens funktionalitet.

Android Gradle Plugin skapar automatiskt en source set för varje Build Type — katalogen src/<buildType>/ (till exempel src/debug/, src/release/). I denna source set kan resurser, kod och manifest placeras som endast tillämpas för den byggtypen. Till exempel kan i src/debug/ AndroidManifest.xml med behörighet för installation från ADB placeras, och i src/release/ — utan den. Build Type source set har prioritet över Product Flavor source set.

Build Type vs Product Flavor

Den viktigaste skillnaden: Build Type svarar på frågan “hur ska vi bygga?”, medan Product Flavor — på frågan “vad ska vi bygga?”. Build Type kan vara debug, release, staging. Product Flavor kan vara free, paid, enterprise. Build Type ändrar inte applikationens funktionalitet (lägger inte till eller tar bort skärmar), Product Flavor — gör det. Build Type kan inaktivera felsökaren och aktivera obfuskering, Product Flavor kan ändra applicationId och resurser. Båda fungerar i par: varje Build Type kombineras med varje Product Flavor och bildar Build Variant.

Standard Build Types: debug och release

Debug är den Build Type som AGP skapar som standard. Den innehåller debuggable=true, vilket gör det möjligt att ansluta felsökaren, visa Log.d-loggar och använda Android Studio-profileraren. Minification är inaktiverad, så bygget går snabbt. I debug-bygget får applicationId suffixet “.debug” (om det inte har åsidosatts), vilket gör det möjligt att installera debug-versionen parallellt med release-versionen på samma enhet. Debug signeras med certifikatet från debug.keystore, som skapas automatiskt av Android SDK.

Release är Build Type för publicering av applikationen. debuggable=false, minificationEnabled=true (standard), shrinkResources=true. Utvecklaren måste ange signingConfig med ett produktionscertifikat — annars anses bygget inte vara release. Release använder ProGuard eller R8 för obfuskering, optimering och komprimering av kod. Android Studio kan inte ansluta felsökaren till ett release-bygge (om debuggable=false). Alla Log.d- och Log.v-anrop tas bort från koden i minificationsfasen, om lämpliga ProGuard-regler har konfigurerats.

Viktigt: debug-byggen testar inte release-beteende. Minification kan ändra kodens beteende — reflektion, serialisering, Gson/SQLite och andra bibliotek kräver ofta ProGuard-regler. Därför måste du före publicering bygga och testa release-versionen. Google Play Console och Firebase Test Lab gör det möjligt att ladda upp release-byggen för automatisk testning på verkliga enheter före publicering.

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

Skapa anpassade Build Types

Arv via initWith

Förutom debug och release kan du skapa egna Build Types — till exempel staging (mellanliggande miljö) eller benchmark (för prestandatester). En anpassad Build Type deklareras i buildTypes-blocket precis som debug och release. Namnet kan vara godtyckligt, men det rekommenderas att använda semantiskt förståeliga namn på engelska. För staging ställs vanligtvis debuggable=true (för diagnos av problem i staging-miljön) och minification=true (för att testa obfuskering före produktion).

En anpassad Build Type får automatiskt motsvarande source set (src/staging/) och genererar uppgifter som assembleStaging. AGP begränsar inte antalet anpassade typer, men varje ny typ multiplicerar antalet Build Variants. Den praktiska gränsen är 4-5 Build Types: debug, staging, benchmark, release och eventuellt debugMinified (debug med aktiverad minification för testning av ProGuard-regler).

För en anpassad Build Type kan debuggable ärvas från debug med hjälp av initWith. Nyckelordet initWith kopierar alla parametrar från den angivna Build Type, som sedan kan åsidosättas. Detta är praktiskt för att skapa staging baserat på debug: initWith debug + ytterligare aktivering av minification. Utan initWith skulle du manuellt behöva lista alla parametrar för bastypen.

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 — för bibliotek som inte har benchmark-typ
// om biblioteket endast har release — använder AGP det

Signeringskonfiguration för olika byggtyper

SigningConfig bestämmer med vilket certifikat APK eller AAB signeras. Android kräver signering av alla installerade applikationer — utan detta tillåter systemet inte installation av APK. För debug-byggen använder AGP debug.keystore — ett förinstallerat certifikat med känt lösenord, genererat av Android SDK Tools. För release-byggen måste du skapa ett eget certifikat via Android Studio (Build → Generate Signed Bundle/APK) eller med kommandot keytool.

Lagring av signeringsnycklar är en kritisk säkerhetsaspekt. Det rekommenderas att inte lagra release-nycklar i källkodsarkivet. Istället används: filen keystore.properties (tillagd i .gitignore), CI/CD-miljövariabler eller Android Studios krypterade lagring. I CI/CD (GitHub Actions, GitLab CI) lagras signeringsnycklar i secrets och skickas till build.gradle via systemegenskaper. Exempel: storePassword = System.getenv("KEYSTORE_PASSWORD").

Varje Build Type kan referera till sin egen signingConfig. För release — produktionscertifikat, för debug — debug.keystore, för staging — ett separat staging-certifikat. Signeringskonfigurationen påverkar direkt möjligheten att installera applikationen: om debug är signerad med debug.keystore och staging med produktionsnyckel, kan staging inte installeras över debug-versionen på grund av signaturob matchning. ApplicationId måste också vara olika — för detta används 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 och R8

Resource Shrinking

Minification är processen att ta bort oanvänd kod och byta namn på klasser, metoder och fält till korta namn. AGP utför minification med ProGuard (föråldrad) eller R8 (rekommenderad, inbyggd i AGP sedan version 3.4). R8 utför fyra operationer: shrinking (borttagning av oanvända klasser), optimisation (förenkling av kod), obfuscation (namnbyte) och preverify (tillägg av kompatibilitetsinformation). Resultat — en APK med mindre storlek som är svårare att dekompilera.

Minificationsregler definieras i ProGuard rules files — textfiler med syntax -keep, -dontwarn, -keepclassmembers. Utan regler kommer R8 att ta bort eller byta namn på klasser som används via reflektion (Gson, Retrofit, Room, Kotlin serialization). Android Studio projektskapare skapar proguard-rules.pro, där regler för specifika bibliotek läggs till. Bibliotek kan också innehålla inbyggda regler — de ansluts automatiskt från jar/aar.

Shrink resources (shrinkResources=true) tar bort oanvända resurser från APK. R8 bestämmer först vilka resurser som inte används i koden (kontrollerar R.java och referenser i manifestet) och tar sedan bort dem från den slutgiltiga bygget. För resurser som används via getIdentifier() eller tredjepartsbibliotek måste tools:keep="@layout/my_layout" läggas till i resurserna. I kombination med minification kan resource shrinking minska APK-storleken med 40-60%.

# proguard-rules.pro — obligatoriska regler
# Gson: behåll klasser för serialisering
-keepclassmembers class com.example.** {
    <fields>;
}

# Retrofit: behåll API-gränssnitt
-keep,allowobfuscation interface com.example.api.*

# Room: behåll DAO och Entity
-keep class * extends androidx.room.RoomDatabase
-keep @interface androidx.room.** { *; }

# Kotlin Coroutines: förhindra borttagning av Continuation
-keepnames class kotlinx.coroutines.internal.*

# OkHttp: behåll service loader
-keep class okhttp3.** { *; }

BuildConfigField och resurser för Build Type

BuildConfig är en automatiskt genererad Java/Kotlin-klass som innehåller konstanter definierade i defaultConfig, productFlavors och buildTypes. Genom buildConfigField kan anpassade fält läggas till: buildConfigField "String", "API_URL", '"https://api.example.com"'. BuildConfigField deklarerad i buildType är tillgänglig i alla varianter av denna typ. Värden i buildType åsidosätter värden från productFlavor, som i sin tur åsidosätter defaultConfig.

För debug-byggen är det praktiskt att ställa in API_URL på localhost eller staging-server, och för release — på produktion. BuildConfig.FLAVOR och BuildConfig.BUILD_TYPE genereras också automatiskt och innehåller namnet på nuvarande flavor och build type. I koden kan användas: if (BuildConfig.DEBUG) { /* loggar */ } — konstanten DEBUG är endast true för debug build type. BuildConfig.DEBUG är ett standardfält som AGP lägger till i varje BuildConfig.

Resurser för Build Type definieras via source set src/<buildType>/res/. Till exempel kan src/debug/res/values/strings.xml innehålla texten “Server: Dev” och src/release/res/ — “Server: Prod”. Manifestresurser åsidosätts också via source set: src/debug/AndroidManifest.xml kan inkludera <uses-permission android:name="android.permission.INTERNET" /> endast för debug-byggen. Detta är renare än att kontrollera BuildConfig i koden och fungerar även för attribut som inte kan ställas in programmatiskt (till exempel 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
}

// Användning: huvudklassen laddar Config via reflektion
fun getConfig(): AppConfig = when (BuildConfig.BUILD_TYPE) {
    "debug" -> DebugConfig
    else -> ReleaseConfig
}