ProGuard/R8 mapping: деобфускация Android крашей

TRUETECH занимается разработкой, поддержкой и обслуживанием мобильных приложений iOS, Android, PWA. Имеем большой опыт и экспертизу для публикации мобильных приложений в популярные маркеты Google Play, App Store, Amazon, AppGallery и другие.

Разработка и поддержка любых видов мобильных приложений:

Информационные и развлекательные мобильные приложения
Новостные приложения, игры, справочники, онлайн-каталоги, погодные, фитнес и здоровье, туристические, образовательные, социальные сети и мессенджеры, квиз, блоги и подкасты, форумы, агрегаторы
Мобильные приложения электронной коммерции
Интернет-магазины, B2B-приложения, маркетплейсы, онлайн-обменники, кэшбэк-сервисы, биржи, дропшиппинг-платформы, программы лояльности, доставка еды и товаров, платежные системы
Мобильные приложения для управления бизнес-процессами
CRM-системы, ERP-системы, управление проектами, инструменты для команды продаж, учет финансов, управление производством, логистика и доставка, управление персоналом, системы мониторинга данных
Мобильные приложения электронных услуг
Доски объявлений, онлайн-школы, онлайн-кинотеатры, платформы предоставления электронных услуг, платформы кешбека, видеохостинги, тематические порталы, платформы онлайн-бронирования и записи, платформы онлайн-торговли

Это лишь некоторые из типы мобильных приложений, с которыми мы работаем, и каждый из них может иметь свои специфические особенности и функциональность, а также быть адаптированным под конкретные потребности и цели клиента.

Услуги, которые мы предлагаем
Показано 1 из 1Все 1734 услуг
ProGuard/R8 mapping: деобфускация Android крашей
Средний
от 4 часов до 2 дней
Часто задаваемые вопросы

Наши компетенции:

Этапы разработки

Последние работы

  • image_mobile-applications_feedme_467_0.webp
    Разработка мобильного приложения для компании FEEDME
    858
  • image_mobile-applications_xoomer_471_0.webp
    Разработка мобильного приложения для компании XOOMER
    743
  • image_mobile-applications_rhl_428_0.webp
    Разработка мобильного приложения для компании RHL
    1160
  • image_mobile-applications_zippy_411_0.webp
    Разработка мобильного приложения для компании ZIPPY
    1034
  • image_mobile-applications_affhome_429_0.webp
    Разработка мобильного приложения для компании Affhome
    968
  • image_mobile-applications_flavors_409_0.webp
    Разработка мобильного приложения для компании FLAVORS
    562

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 Да, но не решает проблему загрузки

Как настроить корректную загрузку: пошаговое руководство

Разверните инструкцию
  1. Включите автоматическую загрузку в 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.

  2. Настройте передачу 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
    
  3. Запустите upload task отдельно. После assembleRelease выполните:

    ./gradlew uploadCrashlyticsMappingFileRelease
    

    Это гарантирует, что CI дождётся завершения загрузки. Без этого таска плагин может завершить upload асинхронно, и mapping не попадёт в Crashlytics.

  4. Архивируйте mapping файл для каждой версии. Добавьте шаг в CI:

    cp app/build/outputs/mapping/release/mapping.txt artifacts/mapping-${VERSION_NAME}-${VERSION_CODE}.txt
    

    Храните файлы не менее 6 месяцев — пользователи могут запускать старые версии.

  5. Проверьте деобфускацию. Используйте 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 загружен?

  1. Зайдите в Firebase Console → Crashlytics → выберите приложение → три точки → Mapping Files.
  2. Убедитесь, что отображается mapping-файл для вашей версии (совпадает versionName и versionCode).
  3. Если файла нет — проверьте лог 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 выполните шаги:

  1. Создайте YAML-файл в .github/workflows/
  2. Настройте секреты репозитория: MATCH_PASSWORD, ASC_API_KEY (ключ в JSON)
  3. Укажите runs-on: macos-14
  4. Используйте ruby/setup-ruby@v1 с bundler-cache: true
  5. Запустите 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.