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

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

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

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

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

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

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

Вот что изменится:

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

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

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

• Более информативные оповещения и сигналы
  Новая проблема – это новая ошибка.

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

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

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

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

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

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

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

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

• Вы включили передачу данных для Google Analytics. Подробнее об этой настройке можно узнать в статье Как управлять настройками доступа к данным в Аналитике.

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

• Вы используете последние версии 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

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

  • Читатель, Читатель Firebase, Читатель данных о качестве, Читатель Crashlytics

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

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

Ниже приведен пример того, как Crashlytics может классифицировать проблему как регрессию.

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

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

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

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

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

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

Файлы dSYM отсутствуют или не загружаются

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

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

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

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

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

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

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

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

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

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

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

• Если вы видите несколько фреймов (Missing) для библиотеки приложения, проверьте, указаны ли в качестве отсутствующих необязательные файлы dSYM (для затронутой версии приложения) на вкладке Crashlytics dSYM в консоли Firebase. Если это так, выполните инструкции по устранению неполадок, приведенные в разделе Часто задаваемые вопросы об отсутствии или невозможности загрузки файлов 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.

Почему ошибки 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 версии 18.3.5 или более поздней (Firebase BoM версии 31.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 Console

Количество ошибок ANR в Google Play и Crashlytics может различаться. Это связано с различиями в механизмах сбора и предоставления данных об ошибках. 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

Как перейти на плагин Gradle версии 3.Crashlytics?

Последний выпуск плагина Gradle Crashlytics – это основная версия (3.0.0), в которой SDK был модернизирован за счет прекращения поддержки более ранних версий Gradle и плагина Android Gradle. Кроме того, изменения в этом выпуске устраняют проблемы с AGP версии 8.1 и выше и улучшают поддержку нативных приложений и специальных сборок.

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

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

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

• Плагин Firebase google-services Gradle 4.4.1 или более поздней версии
  Чтобы обновить плагин, укажите последнюю версию в файле сборки Gradle проекта , как показано ниже:

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

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

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

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

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

• Удалено устаревшее поле 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 двоичного переопределения.

Пример обновления расширения

        buildTypes {
          release {
            configure<CrashlyticsExtension> {
              // ...
              symbolGenerator(
                closureOf<SymbolGenerator> {
                  symbolGeneratorType = "breakpad"
                  breakpadBinary = file("/PATH/TO/BREAKPAD/DUMP_SYMS")
                }
              )
            }
          }
        }
      

        buildTypes {
          release {
            configure<CrashlyticsExtension> {
              // ...
              symbolGeneratorType = "breakpad"
              breakpadBinary = file("/PATH/TO/BREAKPAD/DUMP_SYMS")
            }
          }
        }
      

        buildTypes {
          release {
            firebaseCrashlytics {
              // ...
              symbolGenerator {
                breakpad {
                  binary file("/PATH/TO/BREAKPAD/DUMP_SYMS")
                }
              }
            }
          }
        }
      

        buildTypes {
          release {
            firebaseCrashlytics {
              // ...
              symbolGeneratorType "breakpad"
              breakpadBinary file("/PATH/TO/BREAKPAD/DUMP_SYMS")
            }
          }
        }
      

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

Указать путь к исполняемому файлу генератора файлов символов 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 properties

  Чтобы указать путь к исполняемому файлу, используйте свойство 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.

В личном кабинете 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. Убедитесь, что вы используете Crashlytics Unity SDK версии 8.6.0 или более поздней.

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

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

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

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

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

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

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

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

Чтобы 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 вместе с SDK Google Mobile Ads, то, скорее всего, регистраторы сбоев мешают друг другу при регистрации обработчиков исключений. Чтобы устранить проблему, отключите отчеты о сбоях в SDK Mobile Ads, вызвав функцию disableSDKCrashReporting.

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

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

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

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

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

Проблемы после перехода на новую инфраструктуру экспорта для BigQuery

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

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

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

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

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

Как снизить риск сбоев

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

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

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

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

  1. В Firebaseконсоли найдите идентификатор приложения Firebase (например, 1:1234567890:ios:321abc456def7890), у которого не совпадают название таблицы и идентификатор пакета, и запишите его.
     Перейдите в settings Настройки проекта и найдите карточку Ваши приложения, на которой перечислены все ваши приложения 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 (обычно это название устаревшей таблицы, в которую приложение записывало данные с помощью устаревшей инфраструктуры экспорта).

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

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

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