Устранение неполадок Crashlytics и часто задаваемые вопросы

Эта страница содержит помощь по устранению неполадок и ответы на часто задаваемые вопросы об использовании Crashlytics . Если вы не нашли то, что искали, или вам нужна дополнительная помощь, обратитесь в службу поддержки Firebase .

На этой странице вы найдете информацию по следующим темам:

• Общая помощь в устранении неполадок , включая вопросы, касающиеся отображения данных или работы с данными в консоли Firebase , а также вопросы, касающиеся проблем, которые были решены ранее.

• Поддержка по конкретным платформам , включая вопросы, касающиеся платформ Apple , Android и Unity .

• Поддержка по вопросам интеграции , включая вопросы о BigQuery .

Общие вопросы по устранению неполадок/FAQ

Отображение различных форматов (а иногда и «вариантов») для некоторых выпусков в таблице «Выпуски»

Вы могли заметить два разных формата для задач, перечисленных в таблице «Проблемы» в консоли Firebase . Кроме того, в некоторых задачах вы могли заметить функцию под названием «варианты». Вот почему!

В начале 2023 года мы внедрили улучшенный аналитический механизм для группировки событий, а также обновили дизайн и добавили ряд расширенных функций для новых выпусков (например, варианты!). Подробности читайте в нашем недавнем блоге , а ниже вы найдёте самые важные моменты.

Crashlytics анализирует все события вашего приложения (например, сбои, нефатальные ошибки и ANR) и создает группы событий, называемые проблемами . Все события в проблеме имеют общую точку отказа.

Чтобы сгруппировать события по этим проблемам, улучшенный механизм анализа теперь учитывает множество аспектов события, включая кадры в трассировке стека, сообщение об исключении, код ошибки и другие характеристики платформы или типа ошибки.

Однако внутри этой группы событий трассировки стека, приводящие к сбою, могут различаться. Различная трассировка стека может указывать на иную первопричину. Чтобы отразить это возможное различие внутри проблемы, мы теперь создаём варианты внутри проблем: каждый вариант представляет собой подгруппу событий в проблеме, имеющих одну и ту же точку сбоя и схожую трассировку стека. С помощью вариантов можно отладить наиболее распространённые трассировки стека внутри проблемы и определить, приводят ли разные первопричины к сбою.

Вот что вы ощутите благодаря этим улучшениям:

• Обновленные метаданные, отображаемые в строке выпуска
  Теперь стало проще понимать и решать проблемы в вашем приложении.

• Меньше повторяющихся проблем
  Изменение номера строки не приводит к возникновению новой проблемы.

• Более простая отладка сложных проблем с различными корневыми причинами
  Используйте варианты для отладки наиболее распространенных трассировок стека в рамках проблемы.

• Более значимые оповещения и сигналы
  Новая проблема фактически представляет собой новую ошибку.

• Более мощный поиск
  Каждая проблема содержит больше доступных для поиска метаданных, таких как тип исключения и имя пакета.

Вот как реализуются эти улучшения:

• Когда мы получим новые события из вашего приложения, мы проверим, соответствуют ли они существующей проблеме.

• Если совпадений нет, мы автоматически применим к событию наш более интеллектуальный алгоритм группировки событий и создадим новую задачу с обновленным дизайном метаданных.

Это первое крупное обновление нашей группы мероприятий. Если у вас есть отзывы или вы столкнулись с какими-либо проблемами, сообщите нам об этом, отправив отчёт.

Журналы навигации не отображаются

Если вы не видите журналы навигации ( iOS+ | Android | Flutter | Unity ), рекомендуем проверить конфигурацию вашего приложения для Google Analytics . Убедитесь, что оно соответствует следующим требованиям:

• Вы включили Google Analytics в своем проекте Firebase.

• Вы включили совместное использование данных для Google Analytics . Подробнее об этом параметре читайте в статье «Управление настройками совместного использования данных Google Analytics».

• Вы добавили в свое приложение Firebase SDK для Google Analytics : iOS+ | Android | Flutter | Unity .
  Этот SDK необходимо добавить в дополнение к Crashlytics SDK.

• Вы используете последние версии Firebase SDK для всех продуктов, которые вы используете в своем приложении ( iOS+ | Android | Flutter | Unity ).

  Для платформ Apple и приложений Android особенно важно убедиться, что вы используете как минимум следующую версию Firebase SDK для Google Analytics : iOS+ — v6.3.1+ (v8.9.0+ для macOS и tvOS) | Android — v17.2.3+ ( BoM v24.7.1+).

Не вижу оповещений о превышении скорости

Если вы не видите оповещений о скорости, убедитесь, что вы используетеCrashlytics SDK v18.6.0+ (или Firebase BoM v32.6.0+).

Отсутствие метрик без сбоев (или наличие ненадежных метрик)

Если вы не видите показателей без сбоев (например, количество пользователей и сеансов без сбоев) или видите ненадежные показатели, проверьте следующее:

• Убедитесь, что вы используетеCrashlytics SDK v18.6.0+ (или Firebase BoM v32.6.0+).

• Убедитесь, что настройки сбора данных не влияют на качество ваших показателей безотказности:

  • Если вы включите отправку отчётов по подписке, отключив автоматическую отправку отчётов о сбоях, информация о сбоях будет отправляться в Crashlytics только от пользователей, которые явно согласились на сбор данных. Это повлияет на точность показателей отсутствия сбоев, поскольку Crashlytics получает информацию только от этих пользователей, подписавшихся на рассылку (а не от всех ваших пользователей). Это означает, что ваши показатели отсутствия сбоев могут быть менее надёжными и хуже отражать общую стабильность вашего приложения.

  • Если у вас отключен автоматический сбор данных, вы можете использовать sendUnsentReports для отправки кэшированных на устройстве отчётов в Crashlytics . Этот метод отправит в Crashlytics данные о сбоях , но не данные о сеансах , из-за чего на диаграммах консоли будут отображаться низкие или нулевые значения для метрик без сбоев.

Как подсчитывается количество пользователей, не болеющих сбоями?

См. раздел Понимание показателей отсутствия сбоев .

Кто может просматривать, писать и удалять заметки по проблеме?

Заметки позволяют участникам проекта комментировать конкретные проблемы с помощью вопросов, обновлений статуса и т. д.

Когда участник проекта публикует заметку, она помечается адресом электронной почты его учётной записи Google. Этот адрес электронной почты виден всем участникам проекта, имеющим доступ к просмотру заметки.

Ниже описан доступ, необходимый для просмотра, написания и удаления заметок:

• Участники проекта с любой из следующих ролей могут просматривать и удалять существующие заметки, а также писать новые заметки по проблеме.

  • Владелец или редактор проекта, администратор Firebase , администратор качества или администратор Crashlytics

• Участники проекта с любой из следующих ролей могут просматривать заметки, опубликованные по проблеме, но не могут удалять или писать заметки.

  • Project Viewer , Firebase Viewer , Quality Viewer или Crashlytics Viewer

Что такое регрессивная проблема?

Проблема была решена повторно, и вы уже закрыли её, но Crashlytics получает новый отчёт о её повторном возникновении. Crashlytics автоматически открывает эти регрессивные проблемы, чтобы вы могли устранить их в соответствии с требованиями вашего приложения.

Вот пример сценария, который объясняет, как Crashlytics классифицирует проблему как регрессию:

1. Впервые в истории Crashlytics получает отчёт о сбое под номером «A». Crashlytics открывает соответствующую задачу для этой задачи (задача «A»).
2. Вы быстро исправляете эту ошибку, закрываете проблему «А», а затем выпускаете новую версию своего приложения.
3. Crashlytics получает еще один отчет по проблеме «А» после того, как вы ее закрыли.
   • Если отчёт относится к версии приложения, о которой Crashlytics было известно на момент закрытия вами проблемы (то есть эта версия отправила отчёт о любом сбое), то Crashlytics не будет считать проблему регрессивной. Проблема останется закрытой.
   • Если отчет получен из версии приложения, о которой Crashlytics не знала на момент закрытия вами вопроса (это означает, что версия вообще не отправляла никаких отчетов об ошибках), то Crashlytics считает проблему регрессировавшей и повторно откроет ее.

Примечание: До февраля 2022 года Crashlytics классифицировал проблему как регрессию, если она возникала повторно в любой версии приложения, даже в тех версиях, о которых нам было известно на момент закрытия вами проблемы. Это приводило к тому, что Crashlytics иногда неточно определял регрессии. Теперь мы используем описанную выше систему обозначений.

Когда проблема регрессирует, мы отправляем оповещение об обнаружении регрессии и добавляем к проблеме сигнал регрессии, чтобы вы знали, что Crashlytics повторно открыл её. Если вы не хотите, чтобы проблема была повторно открыта из-за нашего алгоритма регрессии, «заглушите» проблему вместо её закрытия.

Почему я вижу регрессивные проблемы в старых версиях приложения?

Если отчет получен из старой версии приложения, которая не отправляла никаких отчетов о сбоях до момента закрытия вами проблемы, то Crashlytics посчитает проблему регрессировавшей и откроет ее повторно.

Такая ситуация может возникнуть в следующей ситуации: вы исправили ошибку и выпустили новую версию приложения, но у вас всё ещё есть пользователи более ранних версий без исправления ошибки. Если по какой-то причине одна из этих более ранних версий вообще не отправляла отчёты о сбоях на момент закрытия проблемы, и эти пользователи начнут сталкиваться с ошибкой, то эти отчёты о сбоях приведут к регрессивной проблеме.

Если вы не хотите, чтобы проблема была повторно открыта из-за нашего регрессионного алгоритма, «отключите» проблему вместо ее закрытия.

Примечание: До февраля 2022 года Crashlytics классифицировал проблему как регрессию, если она возникала повторно в любой версии приложения, даже в тех версиях, о которых нам было известно на момент закрытия вами проблемы. Это приводило к тому, что Crashlytics иногда неточно определял регрессии. Теперь мы используем описанную выше систему обозначений.

Если вы видите много неправильно идентифицированных регрессий, относящихся к периоду до февраля 2022 года, вы можете повторно закрыть их, чтобы предотвратить их повторное открытие.

---

Поддержка платформ

В следующих разделах содержится информация об устранении неполадок, характерных для конкретных платформ, а также ответы на часто задаваемые вопросы: iOS+ | Android | Unity .

Поддержка платформ Apple

dSYM-файлы отсутствуют/не загружаются

Чтобы загрузить файлы dSYM вашего проекта и получить подробный вывод, проверьте следующее:

1. Убедитесь, что фаза сборки вашего проекта содержит скрипт запуска Crashlytics , который позволяет Xcode загружать файлы dSYM вашего проекта во время сборки (инструкции по добавлению скрипта см. в разделе «Инициализация Crashlytics »). После обновления проекта принудительно запустите сбой и убедитесь, что информация о сбое отображается на панели управления Crashlytics .

2. Если в консоли Firebase вы видите предупреждение «Отсутствует dSYM», проверьте Xcode, чтобы убедиться, что он правильно создает dSYM-файлы для сборки.

3. Если Xcode корректно создаёт dSYM-файлы, но вы всё ещё видите их отсутствие, вероятно, инструмент запуска скрипта зависает при загрузке dSYM-файлов. В этом случае попробуйте выполнить следующие действия:

   • Убедитесь, что вы используете последнюю версию Crashlytics .

   • Загрузите отсутствующие файлы dSYM вручную:

     • Вариант 1: используйте консольную функцию «Перетаскивание» на вкладке dSYMs , чтобы загрузить zip-архив, содержащий отсутствующие файлы dSYM.
     • Вариант 2: используйте скрипт upload-symbols для загрузки отсутствующих файлов dSYM для предоставленных UUID на вкладке dSYMs .

4. Если вы по-прежнему видите отсутствующие dSYM-файлы или загрузки по-прежнему не удаются, обратитесь в службу поддержки Firebase и обязательно приложите свои журналы.

Сбои плохо символизированы

Если вам кажется, что ваши трассировки стека неправильно символизированы, проверьте следующее:

• Если кадры из библиотеки вашего приложения не содержат ссылок на код вашего приложения, убедитесь, что -fomit-frame-pointer не установлен как флаг компиляции.

• Если вы видите несколько (Missing) фреймов для библиотеки вашего приложения, проверьте, нет ли необязательных dSYM-файлов, указанных как отсутствующие (для затронутой версии приложения) на вкладке dSYM-файлы Crashlytics в консоли Firebase . В этом случае выполните действия по устранению неполадок, описанные в разделе «Уведомление об отсутствующем dSYM» в разделе « Часто задаваемые вопросы об отсутствии/незагрузке dSYM-файлов» на этой странице. Обратите внимание, что загрузка этих dSYM-файлов не будет отображать уже произошедшие сбои, но поможет обеспечить отображение символики для будущих сбоев.

Могу ли я использовать Crashlytics для macOS или tvOS?

Да, вы можете внедрить Crashlytics в проекты macOS и tvOS. Обязательно включите Firebase SDK для Google Analytics версии 8.9.0 и выше, чтобы данные о сбоях имели доступ к метрикам, собираемым Google Analytics (пользователи без сбоев, последний выпуск, оповещения о скорости и журналы навигации).

Могу ли я использовать Crashlytics в проекте Firebase с несколькими приложениями на разных платформах Apple?

Теперь вы можете сообщать о сбоях нескольких приложений в одном проекте Firebase, даже если эти приложения разработаны для разных платформ Apple (например, iOS, tvOS и Mac Catalyst). Раньше приходилось разделять приложения по отдельным проектам Firebase, если они содержали одинаковый идентификатор бандла.

---

поддержка Android

Почему ошибки ANR регистрируются только для Android 11+?

Crashlytics поддерживает отправку сообщений об ошибках ANR для приложений Android на устройствах с Android 11 и более поздними версиями. Базовый API, который мы используем для сбора сообщений об ошибках ANR ( getHistoricalProcessExitReasons ), более надёжен, чем подходы, основанные на SIGQUIT или сторожевых таймерах. Этот API доступен только на устройствах Android 11 и более поздних версий.

Почему в некоторых ANR отсутствуют BuildId ?

Если в некоторых из ваших ANR отсутствуют BuildId , выполните следующие действия для устранения неполадок:

• Убедитесь, что вы используете актуальную версию Crashlytics Android SDK и плагина Crashlytics Gradle.

  Если у вас отсутствуют BuildId для Android 11 и некоторых ANR для Android 12, вероятно, вы используете устаревший SDK, плагин Gradle или и то, и другое. Для корректного сбора BuildId для этих ANR необходимо использовать следующие версии:

  • Crashlytics Android SDK v18.3.5+ ( Firebase BoM v31.2.2+)
  • Плагин Crashlytics Gradle v2.9.4+

• Проверьте, не используете ли вы нестандартное расположение для общих библиотек.

  Если отсутствуют только BuildId для общих библиотек вашего приложения, вероятно, вы не используете стандартное расположение по умолчанию для общих библиотек. В этом случае Crashlytics может не найти соответствующие BuildId . Мы рекомендуем вам рассмотреть возможность использования стандартного расположения для общих библиотек.

• Убедитесь, что вы не удаляете BuildId в процессе сборки.

  Обратите внимание, что следующие советы по устранению неполадок применимы как к ошибкам ANR, так и к собственным сбоям.

  • Проверьте наличие BuildId , выполнив readelf -n для ваших исполняемых файлов. Если BuildId отсутствуют, добавьте -Wl,--build-id к флагам вашей системы сборки.

  • Проверьте, не удаляете ли вы случайно BuildId в попытке уменьшить размер APK.

  • Если вы храните урезанные и неурезанные версии библиотеки, обязательно укажите в коде правильную версию.

Различия между отчетами ANR на панели управления Crashlytics и в консоли Google Play

Количество ошибок ANR в Google Play и Crashlytics может не совпадать. Это ожидаемо из-за разницы в механизмах сбора и передачи данных об ошибках ANR. Crashlytics сообщает об ошибках ANR при следующем запуске приложения, тогда как Android Vitals отправляет данные об ошибках ANR после их возникновения.

Кроме того, Crashlytics отображает только ошибки ANR, возникающие на устройствах под управлением Android 11+, в то время как Google Play отображает ошибки ANR с устройств с сервисами Google Play и принятым согласием на сбор данных.

Почему я вижу сбои из-за файлов .kt , помеченные как проблемы .java ?

Когда приложение использует обфускатор, который не раскрывает расширение файла, Crashlytics по умолчанию генерирует каждую проблему с расширением файла .java .

Чтобы Crashlytics мог генерировать проблемы с правильным расширением файла, убедитесь, что ваше приложение использует следующую настройку:

• Использует Android Gradle 4.2.0 или выше.
• Использует R8 с включённой обфускацией. Чтобы обновить приложение до R8, следуйте этой документации .

Обратите внимание, что после обновления до описанной выше конфигурации вы можете столкнуться с новыми проблемами с .kt , дублирующими существующие проблемы с .java . Подробнее об этом см. в разделе часто задаваемых вопросов .

Почему я вижу проблемы .kt , которые являются дубликатами существующих проблем .java ?

Начиная с середины декабря 2021 года Crashlytics улучшила поддержку приложений, использующих Kotlin.

До недавнего времени доступные обфускаторы не раскрывали расширение файла, поэтому Crashlytics по умолчанию генерировал каждую ошибку с расширением .java . Однако, начиная с Android Gradle 4.2.0, R8 поддерживает расширения файлов.

Благодаря этому обновлению Crashlytics теперь может определять, написан ли каждый класс, используемый в приложении, на Kotlin, и добавлять правильное имя файла в сигнатуру проблемы. Сбои теперь корректно приписываются файлам .kt (при необходимости), если ваше приложение настроено следующим образом:

• Ваше приложение использует Android Gradle 4.2.0 или выше.
• Ваше приложение использует R8 с включенной обфускацией.

Поскольку новые сбои теперь содержат правильное расширение файла в сигнатурах проблем, вы можете столкнуться с новыми проблемами с расширением .kt , которые на самом деле являются просто дубликатами существующих проблем с расширением .java . В консоли Firebase мы стараемся определить, является ли новая проблема с расширением .kt возможным дубликатом существующей проблемы с расширением .java , и сообщить вам об этом.

Не возникает сбоев при использовании Dexguard

Если вы видите следующее исключение, скорее всего, вы используете версию DexGuard, несовместимую с Firebase Crashlytics SDK:

java.lang.IllegalArgumentException: Transport backend 'cct' is not registered

Это исключение не приводит к сбою вашего приложения, но блокирует отправку отчётов о сбоях. Чтобы исправить это:

1. Убедитесь, что вы используете последнюю версию DexGuard 8.x. Последняя версия содержит правила, необходимые для Firebase Crashlytics SDK.

2. Если вы не хотите менять версию DexGuard, попробуйте добавить следующую строку в правила обфускации (в файле конфигурации DexGuard):

   -keepresourcexmlelements manifest/application/service/meta-data@value=cct

Как обновить плагин Crashlytics Gradle до версии 3?

Последняя версия плагина Crashlytics для Gradle — это основная версия (v3.0.0), которая модернизирует SDK, исключая поддержку более старых версий Gradle и плагина Android Gradle. Кроме того, изменения в этом релизе устраняют проблемы с AGP v8.1+ и улучшают поддержку нативных приложений и пользовательских сборок.

Минимальные требования

Для работы плагина Crashlytics Gradle версии 3 требуются следующие минимальные параметры:

• Плагин Android Gradle 8.1+
  Обновите этот плагин с помощью плагина Android Gradle Upgrade Assistant в последней версии Android Studio.

• Плагин google-services для Firebase (версия Gradle 4.4.1+)
  Для обновления этого плагина укажите последнюю версию в файле сборки Gradle вашего проекта следующим образом:

Kotlin

plugins {
  id("com.android.application") version "8.1.4" apply false
  id("com.google.gms.google-services") version "4.4.4" apply false
  ...
}

Groovy

plugins {
  id 'com.android.application' version '8.1.4' apply false
  id 'com.google.gms.google-services' version '4.4.4' apply false
  ...
}

Изменения в расширении Crashlytics

В версии 3 плагина Crashlytics для Gradle в расширении Crashlytics произошли следующие изменения, нарушающие совместимость:

• Расширение удалено из блока android defaultConfig . Вместо этого следует настраивать каждый вариант отдельно.

• Удалено устаревшее поле mappingFile . Вместо него теперь автоматически предоставляется объединенный файл сопоставления.

• Удалено устаревшее поле strippedNativeLibsDir . Вместо него следует использовать unstrippedNativeLibsDir для всех нативных библиотек.

• Изменено значение поля unstrippedNativeLibsDir на кумулятивное.

  Посмотреть пример с несколькими каталогами

  buildTypes {
    release {
      configure<CrashlyticsExtension> {
        nativeSymbolUploadEnabled = true
        unstrippedNativeLibsDir = file("MY/NATIVE/LIBS")
      }
    }
    productFlavors {
      flavorDimensions += "feature"
      create("basic") {
        dimension = "feature"
        // ...
      }
      create("featureX") {
        dimension = "feature"
        configure<CrashlyticsExtension> {
          unstrippedNativeLibsDir = file("MY/FEATURE_X/LIBS")
        }
      }
    }
  }

  The Задача uploadCrashlyticsSymbolFilesBasicRelease загрузит символы только из папки MY/NATIVE/LIBS , но uploadCrashlyticsSymbolFilesFeatureXRelease загрузит символы как в папку MY/NATIVE/LIBS так и в MY/FEATURE_X/LIBS .

• Заменено поле замыкания symbolGenerator двумя новыми полями верхнего уровня:

  • symbolGeneratorType строка, содержащая либо "breakpad" (по умолчанию), либо "csym" .
  • breakpadBinary — файл, содержащий локальный исполняемый файл dump_syms предназначенный для переопределения.

Пример того, как обновить расширение.

Kotlin

До	buildTypes { release { configure<CrashlyticsExtension> { // ... symbolGenerator( closureOf<SymbolGenerator> { symbolGeneratorType = "breakpad" breakpadBinary = file("/PATH/TO/BREAKPAD/DUMP_SYMS") } ) } } }
Теперь в версии 3.	buildTypes { release { configure<CrashlyticsExtension> { // ... symbolGeneratorType = "breakpad" breakpadBinary = file("/PATH/TO/BREAKPAD/DUMP_SYMS") } } }

Groovy

До	buildTypes { release { firebaseCrashlytics { // ... symbolGenerator { breakpad { binary file("/PATH/TO/BREAKPAD/DUMP_SYMS") } } } } }
Теперь в версии 3.	buildTypes { release { firebaseCrashlytics { // ... symbolGeneratorType "breakpad" breakpadBinary file("/PATH/TO/BREAKPAD/DUMP_SYMS") } } }

Специфическая поддержка Android-NDK

Различия между трассировками стека NDK на панели управления Crashlytics и в logcat

У LLVM и GNU toolchains есть разные значения по умолчанию и способы обработки для сегмента «только для чтения» двоичных файлов вашего приложения, что может приводить к некорректным трассировкам стека в консоли Firebase . Чтобы снизить эту проблему, добавьте следующие флаги компоновщика в процесс сборки:

• Если вы используете lld линкер из набора инструментов LLVM, добавьте:

  -Wl,--no-rosegment

• Если вы используете компоновщик ld.gold из набора инструментов GNU, добавьте:

  -Wl,--rosegment

Если вы по-прежнему видите несоответствия в трассировке стека (или ни один из флагов не относится к вашей цепочке инструментов), попробуйте добавить в процесс сборки следующее:

-fno-omit-frame-pointer

Как использовать собственный двоичный файл генератора символов Breakpad для NDK?

Плагин Crashlytics включает в себя настраиваемый генератор файлов символов Breakpad . Если вы предпочитаете использовать собственный исполняемый файл для генерации файлов символов Breakpad (например, если вы предпочитаете собирать все исполняемые файлы в цепочке сборки из исходного кода), используйте необязательное свойство расширения symbolGeneratorBinary чтобы указать путь к исполняемому файлу.

Примечание: для двоичных файлов Android требуется версия генератора файлов символов Breakpad для Linux.

Путь к двоичному файлу генератора символов Breakpad можно указать двумя способами:

• Вариант 1 : укажите путь через расширение firebaseCrashlytics в файле build.gradle

  Добавьте следующее в файл build.gradle.kts уровня приложения:

  Плагин Gradle v3.0.0+

  android {
    buildTypes {
      release {
        configure<CrashlyticsExtension> {
          nativeSymbolUploadEnabled = true
          // Add these optional fields to specify the path to the executable
          symbolGeneratorType = "breakpad"
          breakpadBinary = file("/PATH/TO/BREAKPAD/DUMP_SYMS")
        }
      }
    }
  }

  более низкие версии плагинов

  android {
    // ...
    buildTypes {
      // ...
      release {
        // ...
        firebaseCrashlytics {
          // existing; required for either symbol file generator
          nativeSymbolUploadEnabled true
          // Add this optional new block to specify the path to the executable
          symbolGenerator {
            breakpad {
              binary file("/PATH/TO/BREAKPAD/DUMP_SYMS")
            }
          }
        }
     }
  }

• Вариант 2 : укажите путь через строку свойств в файле свойств Gradle.

  Для указания пути к исполняемому файлу можно использовать свойство com.google.firebase.crashlytics.breakpadBinary .

  Вы можете обновить файл свойств Gradle вручную или через командную строку. Например, чтобы указать путь через командную строку, используйте следующую команду:

  ./gradlew -Pcom.google.firebase.crashlytics.symbolGenerator=breakpad \
    -Pcom.google.firebase.crashlytics.breakpadBinary=/PATH/TO/BREAKPAD/DUMP_SYMS \
    app:assembleRelease app:uploadCrashlyticsSymbolFileRelease
  

Поддерживает ли Crashlytics armeabi?

Firebase Crashlytics NDK не поддерживает ARMv5 (armeabi). Поддержка этого ABI прекращена в версии NDK r17.

---

Поддержка Unity

Просмотр несимволизированных трассировок стека для приложений Android на панели управления Crashlytics

Если вы используете Unity IL2CPP и видите несимволизированные трассировки стека, попробуйте сделать следующее:

1. Убедитесь, что вы используете версию Crashlytics Unity SDK 8.6.1 или выше.

2. Убедитесь, что вы настроили и запустили команду Firebase CLI crashlytics:symbols:upload для создания и загрузки файла символов.

   Эту команду CLI необходимо запускать каждый раз при создании сборки релиза или любой сборки, для которой вы хотите видеть символизированные трассировки стека в консоли Firebase . Подробнее см. в статье Получение читаемых отчётов о сбоях .

Можно ли использовать Crashlytics с приложениями, использующими IL2CPP?

Да, Crashlytics может отображать символьные трассировки стека для ваших приложений, использующих IL2CPP. Эта возможность доступна для приложений, выпущенных как на платформах Android, так и Apple. Вот что вам нужно сделать:

1. Убедитесь, что вы используете версию Crashlytics Unity SDK 8.6.0 или выше.

2. Выполните необходимые задачи для вашей платформы:

   • Для приложений на платформе Apple : никаких специальных действий не требуется. Для приложений на платформе Apple плагин Firebase Unity Editor автоматически настраивает ваш проект Xcode для загрузки символов.

   • Для приложений Android : убедитесь, что вы настроили и запустили команду Firebase CLI crashlytics:symbols:upload для создания и загрузки файла символов.

     Эту команду CLI необходимо запускать каждый раз при создании сборки релиза или любой сборки, для которой вы хотите видеть символизированные трассировки стека в консоли Firebase . Подробнее см. в статье Получение читаемых отчётов о сбоях .

Сообщение о неперехваченных исключениях как о фатальных

Crashlytics может сообщать о неперехваченных исключениях как о фатальных (начиная с версии Unity SDK 10.4.0 ). В следующих ответах на часто задаваемые вопросы объясняется смысл и рекомендации по использованию этой функции.

Почему приложение должно сообщать о неперехваченных исключениях как о фатальных?

Сообщая о неперехваченных исключениях как о фатальных, вы получаете более реалистичное представление о том, какие исключения могут привести к невозможности играть в игру — даже если приложение продолжает работать.

Обратите внимание, что если вы начнете сообщать о фатальных ошибках, процент пользователей, не терпевших сбои (CFU), скорее всего, снизится, но показатель CFU будет более репрезентативным для восприятия вашего приложения конечными пользователями.

Важно: Сообщения о неперехваченных исключениях как о фатальных ошибках не влияют на Android Vitals . Сообщения о фатальных ошибках в Crashlytics видны только вам, поэтому вы можете выявлять и устранять проблемы в своих приложениях и играх.

Какие исключения будут зарегистрированы как фатальные?

Чтобы Crashlytics сообщил о неперехваченном исключении как о фатальном, должны быть выполнены оба следующих условия:

• Во время инициализации вашего приложения свойство ReportUncaughtExceptionsAsFatal должно быть установлено в true .

• Ваше приложение (или подключенная библиотека) выдаёт исключение, которое не перехватывается. Исключение, которое создано, но не выброшено , не считается неперехваченным.

После включения функции отчётности о неперехваченных исключениях как о фатальных, у меня появилось много новых фатальных исключений. Как правильно обрабатывать эти исключения?

Когда вы начнете получать отчеты о неперехваченных исключениях как о фатальных, вот несколько вариантов обработки этих неперехваченных исключений:

• Подумайте, как можно начать перехватывать и обрабатывать эти неперехваченные исключения.
• Рассмотрите различные варианты регистрации исключений в консоли отладки Unity и в Crashlytics .

Перехват и обработка выданных исключений

Исключения создаются и генерируются для отражения непредвиденных или исключительных состояний . Решение проблем, вызванных выброшенным исключением, включает в себя возврат программы в известное состояние (процесс, известный как обработка исключений ).

Рекомендуется перехватывать и обрабатывать все предполагаемые исключения, за исключением случаев, когда программу невозможно вернуть в известное состояние.

Чтобы контролировать, какие типы исключений перехватываются и обрабатываются тем или иным кодом, заключите код, который может сгенерировать исключение, в блок try-catch . Убедитесь, что условия в операторах catch максимально узкие для корректной обработки конкретных исключений.

Регистрируйте исключения в Unity или Crashlytics

Существует несколько способов регистрации исключений в Unity или Crashlytics для облегчения отладки проблемы.

При использовании Crashlytics наиболее распространены и рекомендуются два варианта:

• Вариант 1: Распечатать в консоли Unity, но не отправлять отчет в Crashlytics во время разработки или устранения неполадок

  • Выведите на консоль Unity с помощью Debug.Log(exception) , Debug.LogWarning(exception) и Debug.LogError(exception) , которые выводят содержимое исключения на консоль Unity и не выдают исключение повторно.

• Вариант 2: Загрузка в Crashlytics для создания консолидированной отчетности на панели управления Crashlytics в следующих ситуациях:

  • Если исключение стоит регистрировать для отладки возможного последующего события Crashlytics , то используйте Crashlytics.Log(exception.ToString()) .
  • Если исключение все равно должно быть сообщено в Crashlytics несмотря на то, что оно было перехвачено и обработано, используйте Crashlytics.LogException(exception) , чтобы зарегистрировать его как нефатальное событие.

Однако, если вы хотите вручную сообщить о фатальном событии в Unity Cloud Diagnostics, можно использовать Debug.LogException . Этот вариант выводит исключение в консоль Unity, как и вариант 1, но также генерирует исключение (независимо от того, было ли оно уже сгенерировано или перехвачено). Ошибка генерируется нелокально. Это означает, что даже окружающее Debug.LogException(exception) блоками try-catch всё равно приведёт к неперехваченному исключению.

Поэтому вызывайте Debug.LogException только в том случае, если вы хотите выполнить все из следующего:

• Вывести исключение на консоль Unity.
• Загрузить исключение в Crashlytics как фатальное событие.
• Чтобы выдать исключение, заставьте его рассматриваться как неперехваченное исключение и сообщите о нем в Unity Cloud Diagnostics.

Обратите внимание: если вы хотите вывести перехваченное исключение на консоль Unity и загрузить его в Crashlytics как нефатальное событие, выполните следующие действия:

try
{
    methodThatThrowsMyCustomExceptionType();
}
catch(MyCustomExceptionType exception)
{
    // Print the exception to the Unity console at the error level.
    Debug.LogError(exception);
    // Upload the exception to Crashlytics as a non-fatal event.
    Crashlytics.LogException(exception); // not Debug.LogException
    //
    // Code that handles the exception
    //
}

---

Поддержка интеграций

Приложение также использует Google Mobile Ads SDK, но не вызывает сбоев.

Если ваш проект использует Crashlytics вместе с Google Mobile Ads SDK, вероятно, что средства отправки отчётов о сбоях мешают регистрации обработчиков исключений. Чтобы устранить эту проблему, отключите отправку отчётов о сбоях в Mobile Ads SDK, вызвав метод disableSDKCrashReporting .

Где находится мой набор данных BigQuery?

Firebase экспортирует данные в расположение набора данных, которое вы выбрали при настройке экспорта данных в BigQuery .

• Это расположение применяется как к набору данных Crashlytics , так и к набору данных сеансов Firebase (если данные сеансов разрешены для экспорта).

• Это расположение применимо только к данным, экспортированным в BigQuery , и не влияет на расположение данных, хранящихся для использования на панели управления Crashlytics консоли Firebase или в Android Studio.

• После создания набора данных его местоположение изменить нельзя, но вы можете скопировать набор данных в другое место или вручную переместить (создать заново). Подробнее см. в статье Изменение местоположения для существующих экспортов .

Примечание: возможность выбора и изменения места экспорта данных доступна только в том случае, если вы включили экспорт после середины октября 2024 года или перешли на новую инфраструктуру экспорта .

Как перейти на новую инфраструктуру экспорта для BigQuery ?

В середине октября 2024 года Crashlytics запустила новую инфраструктуру для пакетного экспорта данных Crashlytics в BigQuery .

• Если вы включили пакетный экспорт после октября 2024 года , то ваш проект Firebase автоматически использует новую инфраструктуру экспорта. Никаких действий не требуется.

• Если вы включили пакетный экспорт до или во время октября 2024 года , ознакомьтесь с информацией в этом разделе часто задаваемых вопросов, чтобы определить, нужно ли вам предпринимать какие-либо действия.

Все проекты Firebase будут автоматически обновлены до новой инфраструктуры пакетного экспорта уже 9 января 2026 года. Вы можете обновиться и раньше, но убедитесь, что ваши таблицы BigQuery , обрабатываемые пакетным способом, соответствуют предварительным требованиям для обновления.

Вы можете перейти на новую инфраструктуру, но убедитесь, что ваши таблицы BigQuery для пакетной обработки соответствуют предварительным требованиям для обновления.

Примечание: Данное обновление инфраструктуры применяется только к пакетному экспорту данных Crashlytics и не распространяется на экспорт сессий.

Определите, используете ли вы новую инфраструктуру.

Если вы включили пакетный экспорт в середине октября 2024 года или позже, то ваш проект Firebase автоматически использует новую инфраструктуру экспорта.

Вы можете проверить, какую инфраструктуру использует ваш проект: перейдите в консоль Google Cloud , и если в разделе «Конфигурация передачи данных» указано Firebase Crashlytics with Multi-Region Support », значит, ваш проект использует новую инфраструктуру экспорта.

Важные различия между старой и новой экспортной инфраструктурой.

• Новая инфраструктура поддерживает размещение наборов данных Crashlytics за пределами Соединенных Штатов.

  • Функция экспорта была включена до середины октября 2024 года и обновлена ​​до новой инфраструктуры экспорта — теперь вы можете по желанию изменить место экспорта данных .

  • Экспорт включен в середине октября 2024 года или позже — В процессе настройки вам было предложено выбрать место для экспорта данных.

• Новая инфраструктура не поддерживает заполнение данных, полученных до включения функции экспорта.

  • Старая инфраструктура поддерживала заполнение данных за период до 30 дней до даты включения экспорта.

  • Новая инфраструктура поддерживает заполнение данных за последние 30 дней или за самую последнюю дату, когда вы включили экспорт в BigQuery (в зависимости от того, какая дата является самой последней).

• В новой инфраструктуре таблицы пакетной обработки BigQuery именуются с использованием идентификаторов, заданных для ваших приложений Firebase в вашем проекте Firebase.

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

  • Новая инфраструктура записывает данные в пакетные таблицы с именами, основанными на идентификаторах пакетов или именах пакетов , заданных для зарегистрированных приложений Firebase в вашем проекте Firebase .

  Важно: Если вы включили пакетный экспорт до середины октября 2024 года, убедитесь, что ваши существующие таблицы пакетного экспорта соответствуют предварительным требованиям, касающимся идентификаторов пакетов и имен пакетов, прежде чем вручную обновлять инфраструктуру экспорта или до 9 января 2026 года (когда планируется автоматическое обновление всех проектов).

Шаг 1 : Необходимые условия для обновления

1. Убедитесь, что существующие таблицы BigQuery для пакетной обработки используют идентификаторы, совпадающие с идентификаторами пакетов или именами пакетов , указанными для зарегистрированных приложений Firebase в вашем проекте Firebase . Если они не совпадают, это может привести к сбоям в экспорте данных пакетной обработки. Большинство проектов будут находиться в корректном и совместимом состоянии, но важно проверить это перед обновлением.

   • Все приложения Firebase, зарегистрированные в вашем проекте Firebase, можно найти в консоли Firebase : перейдите в проекта , затем прокрутите до карточки «Ваши приложения», чтобы увидеть все ваши приложения Firebase и информацию о них.

   • Все таблицы BigQuery доступные в пакетном режиме, можно найти на странице BigQuery в консоли Google Cloud .

   Примечание: потоковые таблицы BigQuery , заканчивающиеся на REALTIME , не затрагиваются новой инфраструктурой экспорта и могут игнорироваться.

   Например, вот идеальные условия, при которых у вас не возникнет проблем с обновлением:

   • У вас есть таблица пакетов с именем com_yourcompany_yourproject_IOS и приложение Firebase iOS+ с идентификатором пакета com.yourcompany.yourproject , зарегистрированное в вашем проекте Firebase.

   • У вас есть таблица пакетов с именем com_yourcompany_yourproject_ANDROID и приложение Firebase для Android с именем пакета com.yourcompany.yourproject , зарегистрированное в вашем проекте Firebase.

2. Если имена таблиц в пакетном режиме не соответствуют идентификаторам, установленным для зарегистрированных приложений Firebase, следуйте инструкциям, приведенным далее на этой странице , прежде чем выполнять обновление вручную или до 9 января 2026 года, чтобы избежать сбоев в экспорте пакетных файлов.

Шаг 2 : Выполните обновление инфраструктуры вручную.

Если вы включили пакетный экспорт до середины октября 2024 года, то можете вручную обновить инфраструктуру, просто отключив, а затем снова включив экспорт данных Crashlytics в консоли Firebase .

Вот подробная последовательность действий:

1. В консоли Firebase перейдите на страницу «Интеграции» .

2. В карточке BigQuery нажмите «Управление» .

3. Чтобы отключить экспорт, переведите ползунок Crashlytics в положение «скрыто». При появлении запроса подтвердите, что хотите остановить экспорт данных.

4. Немедленно снова включите ползунок Crashlytics , чтобы возобновить экспорт. При появлении запроса подтвердите, что хотите экспортировать данные.

   Теперь для экспорта данных Crashlytics в BigQuery используется новая инфраструктура экспорта.

Имя вашей существующей таблицы пакетной обработки не соответствует идентификатору вашего приложения Firebase.

Если имя вашей существующей таблицы пакетных файлов не совпадает с идентификатором пакета или именем пакета, установленным для вашего зарегистрированного приложения Firebase, разверните этот раздел и реализуйте один из вариантов, чтобы избежать сбоев в экспортированных данных пакетных файлов.

Если у вас есть существующие пакетные таблицы BigQuery в таком состоянии, это означает, что они несовместимы с новой инфраструктурой пакетного экспорта Firebase в BigQuery . Обратите внимание, что все проекты Firebase будут автоматически перенесены на новую инфраструктуру экспорта уже 9 января 2026 года.

Перед ручным обновлением или до 9 января 2026 года следуйте инструкциям в этом разделе, чтобы избежать сбоев в пакетном экспорте данных Crashlytics в BigQuery .

Перейдите к инструкциям, чтобы узнать о способах предотвращения сбоев.

Разберитесь, как инфраструктура экспорта использует идентификаторы для записи данных в таблицы BigQuery

Вот как две инфраструктуры экспорта записывают данные Crashlytics в пакетные таблицы BigQuery :

• Устаревшая инфраструктура экспорта : записывает данные в таблицу с именем, основанным на идентификаторе пакета или имени пакета в исполняемом файле вашего приложения .

• Новая инфраструктура экспорта : записывает данные в таблицу с именем, основанным на идентификаторе пакета или имени пакета , заданном для вашего зарегистрированного приложения Firebase в вашем проекте Firebase .

К сожалению, иногда идентификатор пакета или имя пакета в исполняемом файле вашего приложения не совпадают с идентификатором пакета или именем пакета , указанным для зарегистрированного приложения Firebase в вашем проекте Firebase . Обычно это происходит, если кто-то не указал фактический идентификатор при регистрации приложения.

Что произойдет, если это не будет исправлено до обновления?

Если идентификаторы в этих двух местах не совпадают, то после обновления до новой экспортной инфраструктуры произойдет следующее:

• Ваши данные Crashlytics начнут записываться в новую таблицу BigQuery для пакетной обработки — то есть в новую таблицу, имя которой будет основано на идентификаторе пакета или имени пакета , заданном для вашего зарегистрированного приложения Firebase в вашем проекте Firebase .

• В любую существующую "устаревшую" таблицу, имя которой основано на идентификаторе в исполняемом файле вашего приложения, больше не будут записываться данные.

Примеры сценариев несоответствия идентификаторов

Обратите внимание, что к именам таблиц в пакетном режиме BigQuery автоматически добавляется _IOS или _ANDROID для указания платформы приложения.

Идентификатор(ы) в исполняемом файле вашего приложения	Идентификатор(ы), заданные для вашего(их) приложения(й) Firebase.	Поведение, унаследованное от прошлого	Поведение после обновления к новой экспортной инфраструктуре	Решение
foo	bar	Записывает данные в единственную таблицу, названную по идентификатору в исполняемом файле приложения ( foo ).	Создает, а затем записывает данные в единую таблицу, названную в соответствии с идентификатором, установленным для приложения Firebase ( bar ).	Реализуйте один из вариантов 1 или 2, описанных ниже.
foo	bar , qux и т. д.	Записывает данные в единственную таблицу, названную по идентификатору в исполняемом файле приложения ( foo ).	Создает* таблицу, а затем записывает данные в несколько таблиц, названных в соответствии с идентификаторами, заданными для приложений Firebase ( bar , qux и т. д.).	Реализуйте вариант 2, описанный ниже.
foo , baz и т. д.	bar	Выполняется запись в несколько таблиц, названных по различным идентификаторам в исполняемом файле приложения ( foo , baz и т. д.).	Затем функция Creates** записывает данные каждого приложения в единую таблицу, названную в соответствии с идентификатором, установленным для приложения Firebase ( bar ).	Ни один из вариантов не может быть реализован. Вы по-прежнему можете различать данные из каждого приложения в рамках одной таблицы, используя идентификатор пакета приложения bundle_identifier , который экспортируется вместе с данными.

^{* Если идентификатор в исполняемом файле вашего приложения совпадает с одним из идентификаторов, установленных для приложения Firebase, то новая инфраструктура экспорта не будет создавать новую таблицу для этого идентификатора. Вместо этого она продолжит запись данных для этого конкретного приложения в эту таблицу. Данные для всех остальных приложений будут записываться в новые таблицы.}

^{** Если один из идентификаторов в исполняемом файле вашего приложения совпадает с идентификатором, установленным для приложения Firebase, то новая инфраструктура экспорта не создаст новую таблицу. Вместо этого она будет поддерживать существующую таблицу и начнет записывать в нее данные для всех приложений.}

Варианты, позволяющие избежать сбоев

Во избежание сбоев, перед выполнением обновления вручную или до 9 января 2026 года следуйте инструкциям для одного из вариантов, описанных ниже.

Важно: Если у вас возникнут вопросы или вы не уверены в своих силах при использовании одного из этих вариантов, обратитесь в службу поддержки Firebase .

• ВАРИАНТ 1 :
  Используйте новую таблицу, созданную новой инфраструктурой экспорта. Вы скопируете данные из существующей таблицы в новую.

  1. В консоли Firebase выполните обновление до новой инфраструктуры экспорта , отключив, а затем снова включив экспорт для связанного приложения.

     Это действие создает новую таблицу пакетов с именем, основанным на идентификаторе пакета или имени пакета , заданном для вашего зарегистрированного приложения Firebase в вашем проекте Firebase .

  2. В консоли Google Cloud скопируйте все данные из вашей старой таблицы в только что созданную новую таблицу.

  3. Если у вас есть какие-либо зависимости, которые зависят от вашей таблицы пакетной обработки, измените их так, чтобы они использовали новую таблицу.

  Примечание: После обновления новые данные не будут записываться в вашу устаревшую таблицу. Любые ранее записанные данные в устаревшую таблицу не будут удалены.

• ВАРИАНТ 2 :
  Продолжайте запись в существующую таблицу. Для этого вам потребуется переопределить некоторые параметры по умолчанию в конфигурации BigQuery .

  1. В консоли Firebase найдите и запишите идентификатор приложения Firebase (например, 1:1234567890:ios:321abc456def7890 ), у которого не совпадают имя и идентификатор пакетной таблицы:
     Перейдите в проекта , затем в раздел «Ваши приложения », чтобы увидеть все ваши приложения Firebase и информацию о них.

  2. В консоли Firebase выполните обновление до новой инфраструктуры экспорта , отключив, а затем снова включив экспорт для связанного приложения.

     Это действие приводит к двум результатам:

     • Создает новую таблицу пакетов с именем, основанным на идентификаторе пакета или имени пакета , заданном для вашего зарегистрированного приложения Firebase в вашем проекте Firebase . (В конечном итоге вы удалите эту таблицу, но пока этого делать не следует .)

     • Создает конфигурацию передачи данных BigQuery с использованием Firebase Crashlytics with Multi-Region Support качестве источника.

  3. В консоли Google Cloud измените новую "конфигурацию передачи данных", чтобы данные продолжали записываться в вашу существующую таблицу:

     1. Перейдите в BigQuery > Передача данных , чтобы просмотреть конфигурацию передачи данных.

     2. Выберите конфигурацию, в которой в качестве источника используется Firebase Crashlytics with Multi-Region Support .

     3. Нажмите кнопку «Редактировать» в правом верхнем углу.

     4. В разделе « Подробные сведения об источнике данных » найдите список для gmp_app_id и список для client_namespace .

        В BigQuery идентификатор приложения Firebase называется gmp_app_id . По умолчанию значение client_namespace в BigQuery — это соответствующий уникальный идентификатор пакета/имя пакета приложения, но вы переопределите эту конфигурацию по умолчанию.

        BigQuery использует значение client_namespace в качестве имени пакетной таблицы, в которую каждое связанное приложение Firebase записывает данные.

     5. Найдите параметр gmp_app_id приложения Firebase, для которого вы хотите переопределить настройки по умолчанию. Измените значение параметра client_namespace на имя таблицы, в которую приложение Firebase должно записывать данные (обычно это имя устаревшей таблицы, в которую приложение записывало данные с помощью устаревшей инфраструктуры экспорта).

        Примечание: Если ранее вы записывали данные в одну таблицу, а после обновления у вас появилось несколько таблиц, вы можете использовать одно и то же client_namespace для каждого соответствующего gmp_app_id . BigQuery по сути объединит все таблицы и запишет все данные для всех приложений Firebase в одну таблицу.

     6. Сохраните изменения в конфигурации.

  4. Запланируйте заполнение пропущенных данных за те дни, когда в вашей существующей таблице отсутствуют данные.

  5. После завершения заполнения данных удалите новую таблицу , автоматически созданную новой инфраструктурой экспорта.