Debug vs Release в Android: коротко и по делу

Debug‑сборка содержит символы отладки и все инструменты для разработки (breakpoints, Logcat, BuildConfig.DEBUG), а Release‑сборка — оптимизированная, обфусцированная и подписанная версия для публикации. Ниже — что именно меняется и как безопасно собрать релиз.

Что такое debug build и как он работает

Debug build предназначен только для разработки и тестирования:

  • Включены символы отладки, работающий отладчик и возможность ставить breakpoints.
  • В манифесте и сборке присутствует флаг android:debuggable=true и константа BuildConfig.DEBUG = true.
  • Minify (R8/ProGuard) обычно отключён: имена классов и методов остаются читаемыми.
  • Сборка подписывается автоматически с помощью debug keystore (генерируется Android Studio).
  • Полные логи и дополнительные инструменты (статические проверки, дебаг‑плаги) доступны по умолчанию.

Практический совет: не распространяйте debug‑APK пользователям — он может раскрывать внутренности приложения, работать медленнее и занимать больше места.

Чтобы переключиться между сборками, откройте Build Variants в Android Studio: выберите "debug" для локальной разработки.

Что такое release build и какие настройки важно знать

Release build — версия для публикации:

  • Minify (R8/ProGuard) обычно включён: shrinking, obfuscation, optimization уменьшают размер и затрудняют реверс‑инжиниринг.
  • Сборка подписывается вашим release keystore; без него обновления в Google Play невозможны.
  • Отладочные символы и android:debuggable отключены; BuildConfig.DEBUG = false.
  • Генерируется mapping.txt при обфускации — сохраните его, чтобы деобфусцировать stack traces в Crashlytics/других трекерах.

Короткий пример команды для генерации keystore: keytool -genkey -v -keystore my-release-key.jks -keyalg RSA -keysize 2048 -validity 10000 -alias my-key-alias

Минимальная конфигурация в app/build.gradle (пример): signingConfigs { release { storeFile file("my-release-key.jks") storePassword "" keyAlias "my-key-alias" keyPassword "" } } buildTypes { release { signingConfig signingConfigs.release minifyEnabled true proguardFiles getDefaultProguardFile('proguard-android-optimize.txt'), 'proguard-rules.pro' } }

Не потеряйте keystore и mapping.txt — без них вы не сможете выкладывать обновления и декодировать обфусцированные ошибки.

Практические отличия и рекомендации

Краткое сравнение debug и release

АспектDebugRelease
ОтладкаПолная (символы, breakpoints)Отключена
МинификацияВыключенаВключена (R8/ProGuard)
ПодписьАвто debug keystoreВаш release keystore
Размер APKБольшеМеньше
ПроизводительностьНиже (отладочный код)Выше
ИспользованиеРазработка / тестированиеПубликация / production

Рекомендации:

  • Всегда тестируйте именно release‑сборку на реальных устройствах — обфускация и оптимизации могут вызвать баги (например, из‑за reflection).
  • Для CI: храните keystore и пароли в защищённых секретах, не в репозитории.
  • Настройте правила ProGuard/R8 (keep‑rules) для библиотек, использующих reflection или аннотации.

Частые ошибки

  • Забвение mapping.txt после сборки — невозможно декодировать стектрейсы.
  • Хранение keystore/паролей в публичном репозитории.
  • Тестирование только debug‑сборки и выпуск релиза без проверки на устройствах.
  • Слишком агрессивная obfuscation без keep‑правил, ломает reflection/JSON‑парсинг.
  • Отправка приложения с android:debuggable=true в публичные репозитории.

FAQ

  • Как понять, что сборка debug? — Проверьте BuildConfig.DEBUG или значение android:debuggable в APK.
  • Можно ли установить debug‑APK обычным пользователям? — Да, но это небезопасно и может привести к утечке данных или нестабильной работе.
  • Зачем сохранять mapping.txt? — Для восстановления читабельных стектрейсов после обфускации.
  • Как собрать подписанный релиз в Android Studio? — Build > Generate Signed Bundle / APK, укажите keystore и сборку release.
  • Что делать, если релиз падает на устройстве, а debug нет? — Проверьте ProGuard/R8 правила, логи, и протестируйте с включённым minifyLocalTesting (соберите release локально с дебаг‑логами).

Кратко: используйте debug для быстрой разработки и отладки, release — для публикации. Тестируйте релизную сборку, храните keystore и mapping.txt в безопасности и настраивайте правила обфускации под ваши библиотеки.