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-сборка использует 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 использует его

Signing-конфигурация для разных типов сборки

SigningConfig определяет, каким сертификатом подписывается APK или AAB. Android требует подписи всех устанавливаемых приложений — без неё система не позволит установить APK. Для debug-сборок AGP использует debug.keystore — предустановленный сертификат с известным паролем, который генерируется Android SDK Tools. Для release-сборок необходимо создать собственный сертификат через Android Studio (Build → Generate Signed Bundle/APK) или командой keytool командной строки.

Хранение signing-ключей — критичный аспект безопасности. Рекомендуется не хранить release-ключи в репозитории исходного кода. Вместо этого используются: файл keystore.properties (добавлен в .gitignore), переменные окружения CI/CD, или Android Studio свои encrypted-хранилище. В CI/CD (GitHub Actions, GitLab CI) signing-ключи хранятся в secrets и передаются в build.gradle через системные свойства. Пример: storePassword = System.getenv("KEYSTORE_PASSWORD").

Каждый Build Type может ссылаться на свой signingConfig. Для release — production-сертификат, для debug — debug.keystore, для staging — отдельный staging-сертификат. Signing-конфигурация напрямую влияет на возможность установки приложения: если подписать 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
}