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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Не вижу хлебных крошек

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

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

• Вы включили обмен данными для Google Analytics . Подробнее об этой настройке см. в разделе «Управление настройками обмена данными 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 только от пользователей, которые явно дали согласие на сбор данных. Таким образом, точность метрик без сбоев пострадает, поскольку 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 получает ещё один отчёт по вопросу "A".
   • Если сообщение о сбое относится к версии приложения, о которой 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: Воспользуйтесь функцией «Перетаскивание» в консоли на вкладке dSYM , чтобы загрузить ZIP-архив, содержащий недостающие файлы dSYM.
     • Вариант 2: Используйте скрипт upload-symbols для загрузки отсутствующих файлов dSYM, используя указанные UUID на вкладке dSYM .

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

Аварии плохо символизируются.

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

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

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

Можно ли использовать Crashlytics на macOS или tvOS?

Да, вы можете интегрировать Crashlytics в проекты macOS и tvOS. Убедитесь, что вы включили версию 8.9.0+ Firebase SDK для Google Analytics , чтобы при возникновении сбоев был доступ к метрикам, собираемым 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 версии 2.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, несовместимую с SDK Firebase Crashlytics :

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

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

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

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")
        }
      }
    }
  }

  Он Задача 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 имеют разные настройки по умолчанию и способы обработки сегмента только для чтения в бинарных файлах вашего приложения, что может привести к несогласованным трассировкам стека в консоли 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 версии 3.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

В панели Crashlytics отображаются несимволические трассировки стека для приложений Android.

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

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

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

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

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

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

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

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

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

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

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

Сообщение о необработанных исключениях как о критических ошибках.

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

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

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

Обратите внимание, что если вы начнете сообщать о критических ошибках, процент пользователей без сбоев (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
    //
}

---

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

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

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

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

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

• Это относится как к набору данных Crashlytics , так и к набору данных сессий Firebase (если экспорт данных о сессиях включен).

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

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

Возникли проблемы после обновления до новой инфраструктуры экспорта для BigQuery ?

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

С 2 марта 2026 года все проекты Firebase были автоматически обновлены до новой инфраструктуры пакетного экспорта.

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

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

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

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

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

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

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

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

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

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

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

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

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

Разберитесь, как инфраструктура экспорта использует идентификаторы для записи данных в таблицы 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, то новая инфраструктура экспорта не создаст новую таблицу. Вместо этого она будет поддерживать эту таблицу и начнет записывать в нее данные для всех приложений.}

Варианты смягчения последствий сбоев

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

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

  1. В консоли Google Cloud скопируйте все данные из вашей старой таблицы в новую таблицу, созданную во время обновления инфраструктуры.

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

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

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

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

  2. В консоли 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. Сохраните изменения в конфигурации.

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

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