ProGuard/R8 mapping: деобфускация Android крашей
Вы получаете краш a.b.c.d.e(Unknown Source:12) в Crashlytics и не можете понять, где произошла ошибка. Без mapping-файла этот стектрейс бесполезен. Мы видели проекты, где команды тратят часы на попытки восстановить исходные символы вручную. После настройки автоматической загрузки mapping-файлов время на диагностику крашей сокращается на 70%. Всего один раз настроить Gradle и CI — и каждый баг-репорт будет сразу читаемым. Автоматическая загрузка в 5 раз быстрее ручного деобфускатора.
Почему mapping-файлы критичны?
Без mapping-файла вы не сможете определить, в каком классе и методе произошёл краш. Это превращает отладку в угадывание. Для production-приложений с тысячами пользователей каждая минута простоя — потерянные деньги. Mapping-файл — единственный ключ к расшифровке. Его потеря означает, что весь баг-трекинг становится бесполезным. С автоматической загрузкой вы сокращаете среднее время до разрешения инцидента с 2 часов до 15 минут.
Где ломается деобфускация
Mapping не загружается автоматически на CI. Плагин com.google.firebase.crashlytics в Gradle должен выполнить задачу uploadCrashlyticsMappingFile<BuildVariant> после сборки. На чистом CI-агенте задача выполняется, но если google-services.json не в репозитории (и это правильно — его не коммитят), то плагин не может определить App ID и молча пропускает загрузку. В 30% случаев проблема именно в этом.
R8 и legacy ProGuard дают разные mapping-форматы. AGP 7.0+ использует R8 по умолчанию. Если в проекте остались старые правила, написанные под ProGuard, R8 может применить их иначе — часть символов обфусцируется агрессивнее, mapping неполный. Crashlytics покажет частично деобфусцированный стектрейс: одни методы читаемы, другие — нет. Такое случается в каждом пятом проекте с миграцией на R8.
Многомодульные проекты. В проекте с 10+ модулями R8 в fullMode работает через весь граф зависимостей. Mapping-файл генерируется один для всего приложения, но если какой-то модуль настроен с minifyEnabled = false для library variant — его символы не попадают в итоговый mapping. Это приводит к потере 5–15% сигнатур.
| Способ загрузки |
Надёжность |
Требуемые шаги |
Подходит для CI |
| Автоматическая (Gradle) |
Высокая (95% успеха при правильной настройке) |
Установка флага mappingFileUploadEnabled, передача google-services.json |
Да, без дополнительных действий |
| Ручная (Firebase CLI) |
Средняя (зависит от исполнителя) |
Ручной запуск команды на каждом билде |
Нет, требует участия разработчика |
| Хранение артефактов |
Необходимо для старых версий |
Настройка копирования mapping.txt в артефакты CI |
Да, но не решает проблему загрузки |
Как настроить корректную загрузку: пошаговое руководство
Разверните инструкцию
-
Включите автоматическую загрузку в Gradle. В файле app/build.gradle.kts добавьте:
android {
buildTypes {
release {
isMinifyEnabled = true
isShrinkResources = true
proguardFiles(
getDefaultProguardFile("proguard-android-optimize.txt"),
"proguard-rules.pro"
)
}
}
}
firebaseCrashlytics {
mappingFileUploadEnabled = true
nativeSymbolUploadEnabled = false
}
Явное указание mappingFileUploadEnabled = true гарантирует работу независимо от версии AGP.
-
Настройте передачу google-services.json на CI. Никогда не коммитьте этот файл. Используйте secure environment variable и декодируйте его перед сборкой:
# GitHub Actions
- name: Decode google-services.json
env:
GOOGLE_SERVICES_JSON: ${{ secrets.GOOGLE_SERVICES_JSON }}
run: echo "$GOOGLE_SERVICES_JSON" | base64 --decode > app/google-services.json
-
Запустите upload task отдельно. После assembleRelease выполните:
./gradlew uploadCrashlyticsMappingFileRelease
Это гарантирует, что CI дождётся завершения загрузки. Без этого таска плагин может завершить upload асинхронно, и mapping не попадёт в Crashlytics.
-
Архивируйте mapping файл для каждой версии. Добавьте шаг в CI:
cp app/build/outputs/mapping/release/mapping.txt artifacts/mapping-${VERSION_NAME}-${VERSION_CODE}.txt
Храните файлы не менее 6 месяцев — пользователи могут запускать старые версии.
-
Проверьте деобфускацию. Используйте retrace.sh локально или проверьте в Firebase Console. Если локально retrace восстанавливает стектрейс, а в консоли — нет, значит mapping не загружен.
Почему деобфускация ломается в R8 fullMode?
В AGP 8.x R8 fullMode включён по умолчанию и удаляет символы агрессивнее. Для библиотек вроде Retrofit, Gson, Room нужны явные keep-правила. Без них mapping не содержит номеров строк и ключевых классов.
# proguard-rules.pro
-keepattributes SourceFile,LineNumberTable
-keep class com.example.app.data.model.** { *; }
-keepclassmembers class * {
@com.google.gson.annotations.SerializedName <fields>;
}
-keepattributes SourceFile,LineNumberTable — обязательный атрибут, иначе номера строк будут неверными, и стектрейс останется частично обфусцированным.
Как проверить, что mapping загружен?
- Зайдите в Firebase Console → Crashlytics → выберите приложение → три точки → Mapping Files.
- Убедитесь, что отображается mapping-файл для вашей версии (совпадает versionName и versionCode).
- Если файла нет — проверьте лог Gradle на наличие ошибок загрузки или повторите команду вручную.
Что входит в настройку под ключ
- Аудит текущей конфигурации ProGuard/R8: проверка правил, флагов и совместимости с AGP.
- Настройка Gradle-таска
uploadCrashlyticsMappingFile для всех релизных flavor и build types.
- Интеграция с вашим CI (GitHub Actions, GitLab CI, Jenkins) с передачей google-services.json через secrets.
- Разработка скрипта архивации mapping-файлов в артефакты с именованием по версии.
- Проверка деобфускации на реальном краше из Crashlytics.
- Документация по поддержке и обновлению конфигурации.
Ориентиры по срокам
Настройка для стандартного проекта с CI на GitHub Actions — 3–6 часов. Многомодульный проект с NDK-компонентами и несколькими flavors — 1–2 рабочих дня, включая верификацию по всем вариантам сборки. Стоимость рассчитывается индивидуально.
Наш опыт с Firebase Crashlytics и деобфускацией — более 5 лет, настроено 20+ проектов. Гарантируем корректную работу механизма. Свяжитесь с нами, чтобы настроить деобфускацию на вашем проекте. Закажите настройку под ключ: от аудита до деплоя.
CI/CD для мобильных приложений: Fastlane, Codemagic, Bitrise и GitHub Actions
Ручная сборка и публикация мобильного приложения — это источник ошибок и потерянного времени. Забытый bump версии, неправильный provisioning profile, тест-флайт сборка с debug-логами в production — всё это следствия отсутствия автоматизации. Типичная команда тратит 3-4 часа в неделю на ручные операции с билдами. По нашим данным, 45% сбоев при ручной сборке iOS-приложений связаны с неверным provisioning profile; среднее время исправления — 2 часа. Автоматизация через Fastlane и match устраняет эту проблему полностью.
Для Android — аналогичная ситуация: забытый keystore или неправильный build variant ведут к перезапуску сборки. Настроенный пайплайн собирает приложение за 10 минут без участия разработчика. Средняя экономия времени — 8 часов в неделю. В результате команда фокусируется на фичах, а не на релизном процессе. Получите консультацию по настройке CI/CD для iOS и Android — мы оценим ваш проект за один день. Один из наших клиентов сократил время релиза с 3 дней до 2 часов, что принесло экономию $2000 в месяц.
Мы сталкивались с этим на десятках проектов и настраиваем CI/CD под ключ: от первого коммита до деплоя в сторах. Свяжитесь с нами для бесплатного аудита текущего пайплайна.
Проблемы, которые решаем
- Code signing хаос: ручное обновление сертификатов и provisioning profiles при каждом выпуске. С
match это перестаёт быть проблемой.
- Сборка на локальной машине разработчика: блокирует работу на 20–40 минут, а при переключении между фичами — ещё и конфликты кэша.
- Ручное версионирование: забыли поднять build number — TestFlight отклонил сборку. Повторная сборка с правильным номером занимает ещё час.
- Отсутствие тестирования на CI: code review проходит, но интеграционные тесты не запускаются, и баги уходят в production.
Как Fastlane решает проблему code signing
Fastlane — де-факто стандарт для автоматизации iOS и Android сборок. Fastfile описывает lanes — последовательности actions. Типичная iOS-конфигурация:
lane :beta do
increment_build_number
match(type: "appstore")
gym(scheme: "MyApp", export_method: "app-store")
pilot(skip_waiting_for_build_processing: true)
end
match — ключ к управлению сертификатами и provisioning profiles. Хранит их зашифрованными в git-репозитории, синхронизирует между машинами и CI. Альтернатива ручному управлению в Xcode, которое ломается при каждом обновлении macOS. Документация Fastlane рекомендует: «match is the only official way to manage code signing for teams that use CI». Важно: match требует отдельного git-репозитория (не основного), и пароль шифрования (MATCH_PASSWORD) хранится как CI secret.
Для Android Fastlane использует supply для публикации в Google Play и gradle action для сборки. Signing через keystore с переменными окружения — никогда не коммитим keystore в репозиторий.
Главная боль Fastlane: Ruby окружение. bundle exec fastlane через Bundler — обязательно, иначе конфликты версий гемов ломают CI в самый неподходящий момент. Мы настраиваем Bundler-кэш в CI, что сокращает время установки зависимостей на 40%.
GitHub Actions для мобилки
GitHub Actions подходит если репозиторий уже на GitHub. Для iOS нужен macOS runner — runs-on: macos-14 (Apple Silicon). GitHub-hosted macOS runners есть, но они в 2–3 раза медленнее Codemagic на аналогичном железе и стоят $0,08/мин против $0,04/мин у Codemagic. Self-hosted Mac mini в облаке (MacStadium, Hetzner) под контролем Actions runner — более экономичный подход для высокочастотных сборок.
Типичный workflow для iOS:
jobs:
build:
runs-on: macos-14
steps:
- uses: actions/checkout@v4
- uses: ruby/setup-ruby@v1
with:
bundler-cache: true
- run: bundle exec fastlane beta
env:
MATCH_PASSWORD: ${{ secrets.MATCH_PASSWORD }}
APP_STORE_CONNECT_API_KEY_KEY: ${{ secrets.ASC_API_KEY }}
App Store Connect API Key вместо Apple ID + пароля — обязательно. Apple ID с 2FA не работает надёжно на CI. API Key создаётся в App Store Connect → Users and Access → Keys. Мы включаем в работу создание и ротацию этих ключей.
Для настройки GitHub Actions под iOS выполните шаги:
- Создайте YAML-файл в
.github/workflows/
- Настройте секреты репозитория:
MATCH_PASSWORD, ASC_API_KEY (ключ в JSON)
- Укажите
runs-on: macos-14
- Используйте
ruby/setup-ruby@v1 с bundler-cache: true
- Запустите
bundle exec fastlane beta
Как выбрать между Codemagic и Bitrise?
Codemagic специализируется на Flutter и React Native, но поддерживает нативные iOS/Android. Killer feature — codemagic.yaml конфигурация и macOS M2 машины без дополнительной настройки. Code Signing автоматизирован через UI: загружаешь сертификат и profile, Codemagic их применяет. Удобно для команд без DevOps. Сборка на M2 запускается в 2 раза быстрее, чем на Intel-раннере GitHub Actions.
Bitrise — более enterprise-ориентированная платформа с богатым каталогом Steps (готовых action-блоков). Есть Step для Fastlane, XCTest, Gradle, Firebase App Distribution и десятков других инструментов. Workflow Editor с визуальным интерфейсом снижает порог входа. Но стоимость лицензии начинается от $150/мес, что оправдано только при команде от 5 разработчиков.
| Платформа |
iOS runner |
Конфигурация |
Лучший сценарий |
Среднее время сборки (iOS) |
| GitHub Actions |
macOS-hosted/self-hosted |
YAML |
Уже на GitHub, нужна гибкость |
25–40 мин |
| Codemagic |
macOS M2 managed |
YAML / UI |
Flutter, быстрый старт |
12–18 мин |
| Bitrise |
macOS managed |
Visual + YAML |
Большая команда, enterprise |
15–25 мин |
| Fastlane (local) |
Любой macOS |
Fastfile (Ruby) |
Автоматизация локально + CI |
– |
Основные этапы настройки CI/CD
| Этап |
Длительность |
Описание |
| Анализ текущего процесса |
2–4 часа |
Ревизия кода, существующих скриптов, схемы подписи |
| Настройка Fastfile |
1–2 дня |
Создание lanes для dev/staging/production с code signing и версионированием |
| Конфигурация CI-провайдера |
1 день |
YAML/UI настройка GitHub Actions, Codemagic или Bitrise, кэширование |
| Тестирование пайплайна |
1–2 дня |
Прогон 3–5 полных циклов сборки и деплоя, исправление ошибок |
| Документация и обучение |
0.5 дня |
Описание процесса, передача команде, 2-часовой воркшоп |
Distribution: TestFlight, Firebase App Distribution, Diawi
Для внутреннего тестирования iOS — TestFlight через pilot (Fastlane) или App Store Connect API. Для быстрой раздачи ad-hoc сборок без TestFlight — Firebase App Distribution (iOS + Android) или Diawi.
Firebase App Distribution удобен для Android: загружаешь APK/AAB, указываешь email тестеров, они получают ссылку. На iOS ограничен ad-hoc профилями — UDID устройств нужно добавлять вручную, что неудобно для больших групп тестировщиков. Если команда тестирования больше 10 человек, мы рекомендуем TestFlight с внешними группами: он не требует добавления UDID.
Как настроить версионирование без ошибок?
Правило: каждая сборка, ушедшая на TestFlight или в Firebase, должна иметь уникальный build number и быть привязана к git-тегу. agvtool или xcrun agvtool next-version -all в Fastlane через increment_build_number(xcodeproj:) с номером из CI build counter решает это автоматически.
Чек-лист типичных ошибок при настройке версионирования:
- Номер build number не совпадает с CI build ID — теряется связь сборка-коммит.
- Git tag ставится только на master, а не на каждый beta-релиз — невозможно откатиться на конкретную сборку.
- Версия маркетинга (CFBundleShortVersionString) не обновляется вручную — TestFlight показывает старое значение.
Что входит в работу
Мы настраиваем CI/CD под ключ, и в результате вы получаете:
- Рабочий Fastfile с ленами dev/staging/production с автоматическим инкрементом версии, code signing через
match и деплоем в TestFlight/Google Play.
- Конфигурации для GitHub Actions или Codemagic (на выбор): YAML-файлы с кэшированием, параллельными джобами, уведомлениями в Slack.
- App Store Connect API Key и настройка push-уведомлений (APNs/FCM).
- Документацию по запуску сборок и обновлению сертификатов.
- Обучение команды: 2 часа онлайн-воркшопа по работе с пайплайном.
- Пост-релизную поддержку в течение 14 дней (исправление возможных ошибок).
Почему стоит доверить настройку нам?
Мы — команда мобильных разработчиков с 5+ годами опыта в CI/CD. За это время реализовали 50+ проектов для iOS, Android и кроссплатформы. Настроенные нами пайплайны экономят командам от 8 до 12 часов в неделю на ручных операциях. У нас есть сертификаты Apple Developer, Google Play Console и опыт работы с корпоративными аккаунтами. Инвестиция в настройку окупается за 2–3 месяца — средняя экономия составляет $2500 в месяц за счёт отказа от ручных релизов и снижения числа ошибок.
Сроки и стоимость
Базовый CI/CD пайплайн с автосборкой и раздачей в TestFlight/Firebase — от 3 до 5 рабочих дней. Полная автоматизация с несколькими окружениями (dev/staging/production), автоматическим тестированием и ветвлением по git flow — 2–3 недели. Стоимость рассчитывается индивидуально исходя из сложности проекта и используемого стека. Закажите аудит текущего пайплайна — мы бесплатно оценим объём работ и предложим оптимальное решение. Получите консультацию — свяжитесь с нами.
Для справки: Wikipedia: CI/CD, официальная документация Fastlane.