Устранение неполадок и часто задаваемые вопросы о 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+ – 6.3.1 или более поздняя (8.9.0 или более поздняя для macOS и tvOS) | Android – 17.2.3 или более поздняя (BoM 24.7.1 или более поздняя).

Не приходят оповещения о скорости

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

Показатели работы без сбоев не отображаются или отображаются некорректно

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

• Убедитесь, что вы используете:

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

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

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

Как рассчитывается доля пользователей, у которых не было сбоев

Подробнее о показателях работы без сбоев…

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

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

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

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

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

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

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

  • Читатель проекта, читатель Firebase, читатель Quality или читатель Crashlytics

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

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

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

1. Crashlytics впервые получает отчет о сбое "А". 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, вероятно, инструмент запуска скрипта зависает при загрузке dSYM. В этом случае попробуйте сделать следующее:

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

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

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

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

Символы в отчетах о сбоях добавлены неправильно

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

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

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

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

Да, вы можете реализовать Crashlytics в проектах для macOS и tvOS. Обязательно включите Firebase SDK версии 8.9.0 или более поздней для Google Analytics, чтобы при сбоях у вас был доступ к показателям, собранным 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 или более поздней)
  • Плагин Gradle Crashlytics версии 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 может не совпадать. Это связано с различиями в механизмах сбора и передачи данных об ошибках ANR. Crashlytics сообщает об ошибках ANR при следующем запуске приложения, а Android Vitals отправляет данные сразу после возникновения ошибки.

Кроме того, в 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 Crashlytics версии 3?

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

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

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

• Плагин 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 плагина Crashlytics Gradle в расширении 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.

• Поле closure 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. Убедитесь, что вы используете Crashlytics Unity SDK версии 8.6.1 или более поздней.

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

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

Можно ли использовать Crashlytics с приложениями, в которых применяется IL2CPP?

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

1. Убедитесь, что вы используете SDK Crashlytics Unity версии 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 Project settings (Настройки проекта), а затем на карточку Your apps (Ваши приложения), чтобы посмотреть все приложения Firebase и информацию о них.

  2. В консоли Google Cloud измените новую конфигурацию передачи данных, созданную при обновлении инфраструктуры, чтобы данные записывались в старую таблицу.

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

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