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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Если вы не видите оповещения о скорости, убедитесь, что вы используетеCrashlytics SDK v10.8.0+.

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

  • Убедитесь, что вы используетеCrashlytics SDK v10.8.0+.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Интеграции

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

После того как вы свяжете Crashlytics с BigQuery, новые создаваемые вами наборы данных автоматически располагаются в США, независимо от местоположения вашего проекта Firebase.

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

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

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

Регрессирующие проблемы

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

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

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

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

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

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

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

,


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Если вы не видите оповещения о скорости, убедитесь, что вы используетеCrashlytics SDK v10.8.0+.

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

  • Убедитесь, что вы используетеCrashlytics SDK v10.8.0+.

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

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

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

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

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

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

  2. Если вы видите предупреждение «отсутствующее DSYM» в консоли Firebase , проверьте Xcode, чтобы убедиться, что он правильно производит DSYMS для сборки.

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

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

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

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

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

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

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

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

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

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

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

Интеграции

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

После того, как вы связываете Crashlytics с BigQuery, новые наборы данных, которые вы создаете, автоматически расположены в Соединенных Штатах, независимо от места вашего проекта Firebase.

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

Да, вы можете реализовать Crashlytics в MacOS и проектах TVOS. Обязательно включите V8.9.0+ Firebase SDK для Google Analytics , чтобы сбои имели доступ к метрикам, собранным Google Analytics (бесплатные пользователи, последний выпуск, оповещения о скорости и журналы хлебной крошки).

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

Регрессивные проблемы

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

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

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

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

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

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

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

,


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

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

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

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

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

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

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

Вот что вы испытаете с этими улучшениями:

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

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

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

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

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

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

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

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

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

Если вы не видите журналов Breadcrumb , мы рекомендуем проверить конфигурацию вашего приложения для Google Analytics . Убедитесь, что вы выполнили следующие требования:

Если вы не видите оповещения о скорости, убедитесь, что вы используетеCrashlytics SDK V10.8.0+.

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

  • Убедитесь, что вы используетеCrashlytics SDK V10.8.0+.

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

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

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

См. Понятно, без сбоев метрик .

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

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

  2. Если вы видите предупреждение «отсутствующее DSYM» в консоли Firebase , проверьте Xcode, чтобы убедиться, что он правильно производит DSYMS для сборки.

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

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

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

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

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

If your stack traces seem to be poorly symbolicated, check the following:

  • If frames from your app's library lack references to your app's code, make sure that -fomit-frame-pointer is not set as a compilation flag.

  • If you see several (Missing) frames for your app's library, check if there are optional dSYMs listed as missing (for the affected app version) in the Crashlytics dSYMs tab of the Firebase console. If so, follow the "Missing dSYM alert" troubleshooting step in the dSYMs are missing/not uploading FAQ on this page. Note that uploading these dSYMs will not symbolicate crashes that have already occurred, but this will help ensure symbolication for future crashes.

Notes allow project members to comment on specific issues with questions, status updates, etc.

When a project member posts a note, it's labeled with the email of their Google account. This email address is visible, along with the note, to all project members with access to view the note.

The following describes the access required to view, write, and delete notes:

Интеграции

If your project uses Crashlytics alongside the Google Mobile Ads SDK, it's likely that the crash reporters are interfering when registering exception handlers. To fix the issue, turn off crash reporting in the Mobile Ads SDK by calling disableSDKCrashReporting .

After you link Crashlytics to BigQuery, new datasets you create are automatically located in the United States, regardless of the location of your Firebase project.

Platform support

Yes, you can implement Crashlytics in macOS and tvOS projects. Make sure to include v8.9.0+ of the Firebase SDK for Google Analytics so that crashes will have access to metrics collected by Google Analytics (crash-free users, latest release, velocity alerts, and breadcrumb logs).

You can now report crashes for multiple apps in a single Firebase project, even when the apps are built for different Apple platforms (eg, iOS, tvOS, and Mac Catalyst). Previously, you needed to separate the apps into individual Firebase projects if they contained the same bundle ID.

Regressed issues

An issue has had a regression when you've previously closed the issue but Crashlytics gets a new report that the issue has re-occurred. Crashlytics automatically re-opens these regressed issues so that you can address them as appropriate for your app.

Here's an example scenario that explains how Crashlytics categorizes an issue as a regression:

  1. For the first time ever, Crashlytics gets a crash report about Crash "A". Crashlytics opens a corresponding issue for that crash (Issue "A").
  2. You fix this bug quickly, close Issue "A", and then release a new version of your app.
  3. Crashlytics gets another report about Issue "A" after you've closed the issue.
    • If the report is from an app version that Crashlytics knew about when you closed the issue (meaning that the version had sent a crash report for any crash at all), then Crashlytics won't consider the issue as regressed. The issue will remain closed.
    • If the report is from an app version that Crashlytics did not know about when you closed the issue (meaning that the version had never sent any crash report for any crash at all), then Crashlytics considers the issue regressed and will re-open the issue.

When an issue regresses, we send a regression detection alert and add a regression signal to the issue to let you know that Crashlytics has re-opened the issue. If you do not want an issue to re-open due to our regression algorithm, "mute" the issue instead of closing it.

If a report is from an old app version that had never sent any crash reports at all when you closed the issue, then Crashlytics considers the issue regressed and will re-open the issue.

This situation can happen in the following situation: You've fixed a bug and released a new version of your app, but you still have users on older versions without the bug fix. If, by chance, one of those older versions had never sent any crash reports at all when you closed the issue, and those users start encountering the bug, then those crash reports would trigger a regressed issue.

If you do not want an issue to re-open due to our regression algorithm, "mute" the issue instead of closing it.

,


This page provides troubleshooting help and answers to frequently-asked questions about using Crashlytics . If you can't find what you're looking for or need additional help, contact Firebase support .

General troubleshooting/FAQ

You might notice two different formats for issues listed in your Issues table in the Firebase console. And you might also notice a feature called "variants" within some of your issues. Вот почему!

In early 2023, we rolled out an improved analysis engine for grouping events as well as an updated design and some advanced features for new issues (like variants!). Check out our recent blog post for all the details, but you can read below for the highlights.

Crashlytics analyzes all the events from your app (like crashes, non-fatals, and ANRs) and creates groups of events called issues — all events in an issue have a common point of failure.

To group events into these issues, the improved analysis engine now looks at many aspects of the event, including the frames in the stack trace, the exception message, the error code, and other platform or error type characteristics.

However, within this group of events, the stack traces leading to the failure might be different. A different stack trace could mean a different root cause. To represent this possible difference within an issue, we now create variants within issues - each variant is a sub-group of events in an issue that have the same failure point and a similar stack trace. With variants, you can debug the most common stack traces within an issue and determine if different root causes are leading to the failure.

Here's what you'll experience with these improvements:

  • Revamped metadata displayed within the issue row
    It's now easier to understand and triage issues in your app.

  • Fewer duplicate issues
    A line number change doesn't result in a new issue.

  • Easier debugging of complex issues with various root causes
    Use variants to debug the most common stack traces within an issue.

  • More meaningful alerts and signals
    A new issue actually represents a new bug.

  • More powerful search
    Each issue contains more searchable metadata, like exception type and package name.

Here's how these improvements are rolling out:

  • When we get new events from your app, we'll check if they match to an existing issue.

  • If there's no match, we'll automatically apply our smarter event-grouping algorithm to the event and create a new issue with the revamped metadata design.

This is the first big update that we're making to our event grouping. If you have feedback or encounter any issues, please let us know by filing a report.

If you're not seeing breadcrumb logs , we recommend checking your app's configuration for Google Analytics . Make sure you meet the following requirements:

If you're not seeing velocity alerts, make sure that you're using theCrashlytics SDK v10.8.0+.

If you're not seeing crash-free metrics (like crash-free users and sessions) or seeing unreliable metrics, check the following:

  • Make sure that you're using theCrashlytics SDK v10.8.0+.

  • Make sure that your data collection settings aren't impacting the quality of your crash-free metrics:

    • If you enable opt-in reporting by disabling automatic crash reporting, crash information can only be sent to Crashlytics from users who have explicitly opted into data collection. Thus, the accuracy of crash-free metrics will be affected since Crashlytics only has crash information from these opted-in users (rather than all your users). This means that your crash-free metrics may be less reliable and less reflective of the overall stability of your app.

    • If you have automatic data collection disabled, you can use sendUnsentReports to send on-device cached reports to Crashlytics . Using this method will send crash data to Crashlytics , but not sessions data which causes the console charts to show low or zero values for crash-free metrics.

See Understand crash-free metrics .

To upload your project's dSYMs and get verbose output, check the following:

  1. Make sure your project's build phase contains the Crashlytics run script, which allows Xcode to upload your project's dSYMs at build time (read Initializing Crashlytics for instructions on adding the script). After updating your project, force a crash and confirm that the crash appears in the Crashlytics dashboard.

  2. If you see a "Missing dSYM" alert in the Firebase console, check Xcode to make sure it's properly producing dSYMs for the build.

  3. If Xcode is properly producing dSYMs, and you're still seeing missing dSYMs, it's likely the run script tool is getting stuck while uploading the dSYMs. In this case, try each of the following:

    • Make sure you're using the latest version of Crashlytics .

    • Upload the missing dSYM files manually:

      • Option 1: Use the console-based "Drag and Drop" option in the dSYMs tab to upload a zip archive containing the missing dSYM files.
      • Option 2: Use the upload-symbols script to upload the missing dSYM files, for the provided UUIDs in the dSYMs tab.

  4. If you continue to see missing dSYMs, or uploads are still unsuccessful, contact Firebase Support and be sure to include your logs.

If your stack traces seem to be poorly symbolicated, check the following:

  • If frames from your app's library lack references to your app's code, make sure that -fomit-frame-pointer is not set as a compilation flag.

  • If you see several (Missing) frames for your app's library, check if there are optional dSYMs listed as missing (for the affected app version) in the Crashlytics dSYMs tab of the Firebase console. If so, follow the "Missing dSYM alert" troubleshooting step in the dSYMs are missing/not uploading FAQ on this page. Note that uploading these dSYMs will not symbolicate crashes that have already occurred, but this will help ensure symbolication for future crashes.

Notes allow project members to comment on specific issues with questions, status updates, etc.

When a project member posts a note, it's labeled with the email of their Google account. This email address is visible, along with the note, to all project members with access to view the note.

The following describes the access required to view, write, and delete notes:

Интеграции

If your project uses Crashlytics alongside the Google Mobile Ads SDK, it's likely that the crash reporters are interfering when registering exception handlers. To fix the issue, turn off crash reporting in the Mobile Ads SDK by calling disableSDKCrashReporting .

After you link Crashlytics to BigQuery, new datasets you create are automatically located in the United States, regardless of the location of your Firebase project.

Platform support

Yes, you can implement Crashlytics in macOS and tvOS projects. Make sure to include v8.9.0+ of the Firebase SDK for Google Analytics so that crashes will have access to metrics collected by Google Analytics (crash-free users, latest release, velocity alerts, and breadcrumb logs).

You can now report crashes for multiple apps in a single Firebase project, even when the apps are built for different Apple platforms (eg, iOS, tvOS, and Mac Catalyst). Previously, you needed to separate the apps into individual Firebase projects if they contained the same bundle ID.

Regressed issues

An issue has had a regression when you've previously closed the issue but Crashlytics gets a new report that the issue has re-occurred. Crashlytics automatically re-opens these regressed issues so that you can address them as appropriate for your app.

Here's an example scenario that explains how Crashlytics categorizes an issue as a regression:

  1. For the first time ever, Crashlytics gets a crash report about Crash "A". Crashlytics opens a corresponding issue for that crash (Issue "A").
  2. You fix this bug quickly, close Issue "A", and then release a new version of your app.
  3. Crashlytics gets another report about Issue "A" after you've closed the issue.
    • If the report is from an app version that Crashlytics knew about when you closed the issue (meaning that the version had sent a crash report for any crash at all), then Crashlytics won't consider the issue as regressed. The issue will remain closed.
    • If the report is from an app version that Crashlytics did not know about when you closed the issue (meaning that the version had never sent any crash report for any crash at all), then Crashlytics considers the issue regressed and will re-open the issue.

When an issue regresses, we send a regression detection alert and add a regression signal to the issue to let you know that Crashlytics has re-opened the issue. If you do not want an issue to re-open due to our regression algorithm, "mute" the issue instead of closing it.

If a report is from an old app version that had never sent any crash reports at all when you closed the issue, then Crashlytics considers the issue regressed and will re-open the issue.

This situation can happen in the following situation: You've fixed a bug and released a new version of your app, but you still have users on older versions without the bug fix. If, by chance, one of those older versions had never sent any crash reports at all when you closed the issue, and those users start encountering the bug, then those crash reports would trigger a regressed issue.

If you do not want an issue to re-open due to our regression algorithm, "mute" the issue instead of closing it.