На этой странице представлена помощь по устранению неполадок и ответы на часто задаваемые вопросы об использовании Crashlytics . Если вы не можете найти то, что ищете, или вам нужна дополнительная помощь, обратитесь в службу поддержки Firebase .
Общее устранение неполадок/часто задаваемые вопросы
Вы можете заметить два разных формата проблем, перечисленных в таблице «Проблемы» в консоли Firebase . И вы также можете заметить функцию под названием «варианты» в некоторых ваших задачах. Вот почему!
В начале 2023 года мы представили улучшенный механизм анализа для группировки событий, а также обновленный дизайн и некоторые расширенные функции для новых проблем (например, вариантов!). Подробности читайте в нашем недавнем сообщении в блоге , а основные моменты вы можете прочитать ниже.
Crashlytics анализирует все события вашего приложения (например, сбои, нефатальные ошибки и ошибки ANR) и создает группы событий, называемые проблемами — все события в проблеме имеют общую точку сбоя.
Чтобы сгруппировать события по этим проблемам, улучшенный механизм анализа теперь анализирует многие аспекты события, включая кадры в трассировке стека, сообщение об исключении, код ошибки и другие характеристики платформы или типа ошибки.
Однако в этой группе событий трассировки стека, приводящие к сбою, могут быть разными. Другая трассировка стека может означать другую основную причину. Чтобы представить эту возможную разницу внутри проблемы, мы теперь создаем варианты внутри задач — каждый вариант представляет собой подгруппу событий в задаче, которые имеют одну и ту же точку отказа и аналогичную трассировку стека. С помощью вариантов вы можете отладить наиболее распространенные трассировки стека внутри проблемы и определить, приводят ли к сбою различные основные причины.
Вот что вы получите благодаря этим улучшениям:
Обновленные метаданные, отображаемые в строке проблемы.
Теперь стало проще понимать и сортировать проблемы в вашем приложении.Меньше повторяющихся проблем
Изменение номера строки не приводит к возникновению новой проблемы.Упрощенная отладка сложных проблем с различными первопричинами.
Используйте варианты для отладки наиболее распространенных трассировок стека в задаче.Более содержательные оповещения и сигналы
Новая проблема на самом деле представляет собой новую ошибку.Более мощный поиск
Каждая проблема содержит больше метаданных, доступных для поиска, таких как тип исключения и имя пакета.
Вот как эти улучшения реализуются:
Когда мы получаем новые события из вашего приложения, мы проверяем, соответствуют ли они существующей проблеме.
Если совпадений нет, мы автоматически применим к событию наш более умный алгоритм группировки событий и создадим новую проблему с обновленным дизайном метаданных.
Это первое большое обновление, которое мы вносим в нашу группу событий. Если у вас есть отзывы или возникли какие-либо проблемы, сообщите нам об этом, отправив отчет.
Если вы не видите навигационные журналы , рекомендуем проверить конфигурацию вашего приложения для Google Analytics . Убедитесь, что вы соответствуете следующим требованиям:
Вы включили Google Analytics в своем проекте Firebase.
Вы включили обмен данными для Google Analytics . Подробнее об этом параметре читайте в разделе «Управление настройками общего доступа к данным Google Analytics».
У тебя естьв ваше приложение. Этот SDK необходимо добавить в дополнение к Crashlytics SDK.
Вы используетедля всех продуктов, которые вы используете в своем приложении.
Если вы не видите оповещения о скорости, убедитесь, что вы используете
Если вы не видите показателей отсутствия сбоев (например, пользователей и сеансов без сбоев) или видите ненадежные показатели, проверьте следующее:
Убедитесь, что вы используете
Убедитесь, что настройки сбора данных не влияют на качество показателей безотказности:
Если вы включите возможность создания отчетов о сбоях, отключив автоматические отчеты о сбоях, информация о сбоях может быть отправлена в Crashlytics только от пользователей, которые явно согласились на сбор данных. Таким образом, это повлияет на точность показателей отсутствия сбоев, поскольку Crashlytics собирает информацию о сбоях только от этих согласившихся пользователей (а не от всех ваших пользователей). Это означает, что ваши показатели отсутствия сбоев могут быть менее надежными и менее отражающими общую стабильность вашего приложения.
Если у вас отключен автоматический сбор данных, вы можете использовать
sendUnsentReportsдля отправки кэшированных отчетов на устройстве в Crashlytics . При использовании этого метода в Crashlytics будут отправляться данные о сбоях , но не данные сеансов , из-за чего на диаграммах консоли будут отображаться низкие или нулевые значения для показателей без сбоев.
См. раздел Общие сведения о показателях отсутствия сбоев .
Примечания позволяют участникам проекта комментировать конкретные проблемы с помощью вопросов, обновлений статуса и т. д.
Когда участник проекта публикует заметку, она помечается адресом электронной почты его учетной записи Google. Этот адрес электронной почты вместе с заметкой виден всем участникам проекта, имеющим доступ для просмотра заметки.
Ниже описан доступ, необходимый для просмотра, записи и удаления заметок:
Участники проекта с любой из следующих ролей могут просматривать и удалять существующие заметки, а также писать новые заметки по проблеме.
Участники проекта с любой из следующих ролей могут просматривать заметки, опубликованные по проблеме, но не могут удалять или писать заметки.
Интеграции
Если ваш проект использует Crashlytics вместе с Google Mobile Ads SDK, вполне вероятно, что генераторы отчетов о сбоях мешают регистрировать обработчики исключений. Чтобы устранить эту проблему, отключите отчеты о сбоях в Mobile Ads SDK, вызвав метод disableSDKCrashReporting .
После того как вы свяжете Crashlytics с BigQuery, новые создаваемые вами наборы данных автоматически располагаются в США, независимо от местоположения вашего проекта Firebase.
Поддержка платформы
Регрессирующие проблемы
Проблема была регрессирована, когда вы ранее закрыли ее, но Crashlytics получает новый отчет о том, что проблема повторилась. Crashlytics автоматически повторно открывает эти регрессировавшие проблемы, чтобы вы могли решить их соответствующим образом для вашего приложения.
Вот пример сценария, который объясняет, как Crashlytics классифицирует проблему как регрессию:
- Впервые Crashlytics получает отчет о сбое Crash «A». Crashlytics открывает соответствующую проблему для этого сбоя (проблема «A»).
- Вы быстро исправляете эту ошибку, закрываете проблему «А», а затем выпускаете новую версию своего приложения.
- Crashlytics получит еще один отчет о проблеме «А» после того, как вы ее закроете.
- Если отчет относится к версии приложения, о которой Crashlytics знал, когда вы закрыли проблему (это означает, что версия вообще отправила отчет о сбое при любом сбое), то Crashlytics не будет считать проблему регрессированной. Вопрос останется закрытым.
- Если отчет относится к версии приложения, о которой Crashlytics не знала, когда вы закрыли проблему (это означает, что версия вообще никогда не отправляла отчет о сбое ни при каком сбое), то Crashlytics считает, что проблема регрессировала, и повторно откроет проблему.
Когда проблема регрессирует, мы отправляем предупреждение об обнаружении регрессии и добавляем к проблеме сигнал регрессии, чтобы вы знали, что Crashlytics повторно открыла проблему. Если вы не хотите, чтобы проблема открывалась повторно из-за нашего алгоритма регрессии, «приглушите» проблему, а не закрывайте ее.
Если отчет исходит из старой версии приложения, которая вообще не отправляла никаких отчетов о сбоях, когда вы закрыли проблему, Crashlytics считает, что проблема регрессировала, и повторно откроет проблему.
Такая ситуация может возникнуть в следующей ситуации: вы исправили ошибку и выпустили новую версию своего приложения, но у вас все еще есть пользователи более старых версий без исправления ошибки. Если случайно одна из этих старых версий вообще не отправила никаких отчетов о сбоях, когда вы закрыли проблему, и эти пользователи начнут сталкиваться с ошибкой, то эти отчеты о сбоях вызовут регрессирующую проблему.
Если вы не хотите, чтобы проблема открывалась повторно из-за нашего алгоритма регрессии, «приглушите» проблему, а не закрывайте ее.
,На этой странице представлена помощь по устранению неполадок и ответы на часто задаваемые вопросы об использовании Crashlytics . Если вы не можете найти то, что ищете, или вам нужна дополнительная помощь, обратитесь в службу поддержки Firebase .
Общее устранение неполадок/часто задаваемые вопросы
Вы можете заметить два разных формата проблем, перечисленных в таблице «Проблемы» в консоли Firebase . И вы также можете заметить функцию под названием «варианты» в некоторых ваших задачах. Вот почему!
В начале 2023 года мы представили улучшенный механизм анализа для группировки событий, а также обновленный дизайн и некоторые расширенные функции для новых проблем (например, вариантов!). Подробности читайте в нашем недавнем сообщении в блоге , а основные моменты вы можете прочитать ниже.
Crashlytics анализирует все события вашего приложения (например, сбои, нефатальные события и ошибки ANR) и создает группы событий, называемые проблемами — все события в проблеме имеют общую точку сбоя.
Чтобы сгруппировать события по этим проблемам, улучшенный механизм анализа теперь анализирует многие аспекты события, включая кадры в трассировке стека, сообщение об исключении, код ошибки и другие характеристики платформы или типа ошибки.
Однако в этой группе событий трассировки стека, приводящие к сбою, могут быть разными. Другая трассировка стека может означать другую основную причину. Чтобы отобразить эту возможную разницу внутри проблемы, мы теперь создаем варианты внутри задач — каждый вариант представляет собой подгруппу событий в задаче, которые имеют одну и ту же точку отказа и аналогичную трассировку стека. С помощью вариантов вы можете отладить наиболее распространенные трассировки стека внутри проблемы и определить, приводят ли к сбою различные основные причины.
Вот что вы получите благодаря этим улучшениям:
Обновленные метаданные, отображаемые в строке проблемы.
Теперь стало проще понимать и сортировать проблемы в вашем приложении.Меньше повторяющихся проблем
Изменение номера строки не приводит к возникновению новой проблемы.Упрощенная отладка сложных проблем с различными первопричинами.
Используйте варианты для отладки наиболее распространенных трассировок стека в задаче.Более содержательные оповещения и сигналы
Новая проблема на самом деле представляет собой новую ошибку.Более мощный поиск
Каждая проблема содержит больше метаданных, доступных для поиска, таких как тип исключения и имя пакета.
Вот как эти улучшения реализуются:
Когда мы получаем новые события из вашего приложения, мы проверяем, соответствуют ли они существующей проблеме.
Если совпадений нет, мы автоматически применим к событию наш более умный алгоритм группировки событий и создадим новую проблему с обновленным дизайном метаданных.
Это первое большое обновление, которое мы вносим в нашу группу событий. Если у вас есть отзывы или возникли какие-либо проблемы, сообщите нам об этом, отправив отчет.
Если вы не видите навигационные журналы , рекомендуем проверить конфигурацию вашего приложения для Google Analytics . Убедитесь, что вы соответствуете следующим требованиям:
Вы включили Google Analytics в своем проекте Firebase.
Вы включили обмен данными для Google Analytics . Подробнее об этом параметре читайте в разделе «Управление настройками общего доступа к данным Google Analytics».
У тебя естьв ваше приложение. Этот SDK необходимо добавить в дополнение к Crashlytics SDK.
Вы используетедля всех продуктов, которые вы используете в своем приложении.
Если вы не видите оповещения о скорости, убедитесь, что вы используете
Если вы не видите показателей отсутствия сбоев (например, пользователей и сеансов без сбоев) или видите ненадежные показатели, проверьте следующее:
Убедитесь, что вы используете
Убедитесь, что настройки сбора данных не влияют на качество показателей безотказности:
Если вы включите возможность создания отчетов о сбоях, отключив автоматические отчеты о сбоях, информация о сбоях может быть отправлена в Crashlytics только от пользователей, которые явно согласились на сбор данных. Таким образом, это повлияет на точность показателей отсутствия сбоев, поскольку Crashlytics собирает информацию о сбоях только от этих согласившихся пользователей (а не от всех ваших пользователей). Это означает, что ваши показатели отсутствия сбоев могут быть менее надежными и менее отражающими общую стабильность вашего приложения.
Если у вас отключен автоматический сбор данных, вы можете использовать
sendUnsentReportsдля отправки кэшированных отчетов на устройстве в Crashlytics . При использовании этого метода в Crashlytics будут отправляться данные о сбоях , но не данные сеансов , из-за чего на диаграммах консоли будут отображаться низкие или нулевые значения для показателей без сбоев.
См. раздел Общие сведения о показателях отсутствия сбоев .
Примечания позволяют участникам проекта комментировать конкретные вопросы с вопросами, обновлениями статуса и т. Д.
Когда участник проекта публикует заметку, она помечена электронной почтой их учетной записи Google. Этот адрес электронной почты видна, наряду с примечанием для всех участников проекта с доступом для просмотра примечания.
Следующее описывает доступ, необходимый для просмотра, записи и удаления примечаний:
Члены проекта с любой из следующих ролей могут просмотреть и удалять существующие заметки и писать новые заметки по вопросу.
Члены проекта с любыми из следующих ролей могут просмотреть заметки, опубликованные по вопросу, но они не могут удалить или написать заметку.
- Зритель проекта, зритель Firebase , качественный просмотр или Crashlytics Viewer
Интеграции
Если ваш проект использует Crashlytics вместе с SDK Google Mobile Ads , вполне вероятно, что репортеры с аварией вмешиваются при регистрации обработчиков исключений. Чтобы решить проблему, отключите отчеты о сбоях в Mobile Ads SDK, позвонив в disableSDKCrashReporting .
После того, как вы связываете Crashlytics с BigQuery, новые наборы данных, которые вы создаете, автоматически расположены в Соединенных Штатах, независимо от места вашего проекта Firebase.
Поддержка платформы
Регрессивные проблемы
Вопрос возникла регрессия, когда вы ранее закрыли проблему, но Crashlytics получает новый отчет о том, что проблема повторно зарегистрировалась. Crashlytics автоматически вновь открывает эти регрессивные проблемы, чтобы вы могли решать их как необходимые для вашего приложения.
Вот пример сценария, в котором объясняется, как Crashlytics классифицирует проблему как регрессию:
- Впервые Crashlytics получает отчет о аварии о Crash "A". Crashlytics открывает соответствующую проблему для этого сбоя (выпуск «a»).
- Вы быстро исправляете эту ошибку, закрываете проблему «A», а затем выпускаете новую версию вашего приложения.
- Crashlytics получает еще один отчет о выпуске «A» после того, как вы закрыли проблему.
- Если отчет взят из версии приложения, о которой Crashlytics знал, когда вы закрыли проблему (это означает, что версия отправила отчет о сбое для любого сбоя), то Crashlytics не рассматривает эту проблему как регрессированную. Проблема останется закрытой.
- Если отчет взят из версии приложения, о которой Crashlytics не знал о том, когда вы закрыли проблему (это означает, что версия никогда не отправляла никакого отчета о сбое для какого-либо сбоя), то Crashlytics рассматривает вопрос об регрессивности и повторно откроет проблему.
Когда проблема регрессирует, мы посылаем оповещение о обнаружении регрессии и добавляем сигнал регрессии в проблему, чтобы вы знали, что Crashlytics вновь открыла проблему. Если вы не хотите, чтобы проблема была вновь открыта из-за нашего алгоритма регрессии, «отключить» проблему вместо того, чтобы закрыть ее.
Если отчет взят из старой версии приложения, которая вообще никогда не отправляла отчеты о сбоях, когда вы закрыли проблему, то Crashlytics рассматривает проблему, регрессирующая и вновь откроет проблему.
Эта ситуация может произойти в следующей ситуации: вы исправили ошибку и выпустили новую версию вашего приложения, но у вас все еще есть пользователи на старых версиях без исправления ошибки. Если случайно одна из этих старых версий никогда не отправляла никаких отчетов о сбоях вообще, когда вы закрыли проблему, и эти пользователи начинают встречаться с ошибкой, то эти отчеты об аварии вызывают регрессивную проблему.
Если вы не хотите, чтобы проблема была вновь открыта из-за нашего алгоритма регрессии, «отключить» проблему вместо того, чтобы закрыть ее.
,На этой странице предоставлена помощь и ответы на часто заданные вопросы об использовании Crashlytics . Если вы не можете найти то, что ищете, или нужна дополнительная помощь, свяжитесь с поддержкой Firebase .
Общие устранения неполадок/FAQ
Вы можете заметить два разных формата для проблем, перечисленных в вашей таблице проблем в консоли Firebase . И вы также можете заметить функцию, называемую «варианты» в некоторых ваших проблемах. Вот почему!
В начале 2023 года мы развернули улучшенный механизм анализа для группировки событий, а также обновленный дизайн и некоторые расширенные функции для новых проблем (например, варианты!). Проверьте наше недавнее сообщение в блоге для всех деталей, но вы можете прочитать ниже для основных моментов.
Crashlytics анализирует все события из вашего приложения (например, аварии, не жидкие и ANR) и создает группы событий, называемые вопросами -все события в проблеме имеют общую точку отказа.
Чтобы группировать события в эти проблемы, улучшенный механизм анализа теперь рассматривает многие аспекты события, включая кадры в трассировке стека, сообщение об исключении, код ошибки и другие характеристики типа ошибки.
Однако в рамках этой группы событий следы стека, ведущие к сбою, могут быть разными. Другой трассировку стека может означать другую основную причину. Чтобы представить эту возможную разницу в проблеме, мы теперь создаем варианты в рамках вопросов - каждый вариант является подгруппой событий в проблеме, которая имеет одинаковую точку отказа и аналогичную трассу стека. С вариантами вы можете отлаживать наиболее распространенные трассы стека в рамках проблемы и определить, приводят ли различные основные причины к сбое.
Вот что вы испытаете с этими улучшениями:
Обновленные метаданные, отображаемые в строке выпуска
Теперь в вашем приложении легче понять и сортировать проблемы.Меньше дубликатов проблем
Изменение номера строки не приводит к новой проблеме.Более легкая отладка сложных проблем с различными коренными причинами
Используйте варианты, чтобы отлаживать наиболее распространенные следы стека в рамках проблемы.Более значимые оповещения и сигналы
Новая проблема на самом деле представляет новую ошибку.Более мощный поиск
Каждый выпуск содержит больше метаданных для поиска, таких как тип исключения и имя пакета.
Вот как эти улучшения развернуты:
Когда мы получим новые события из вашего приложения, мы проверим, соответствуют ли они существующей проблеме.
Если нет совпадения, мы автоматически применим наш более умный алгоритм групп событий на мероприятие и создадим новую проблему с обновленным дизайном метаданных.
Это первое большое обновление, которое мы делаем для нашей группировки мероприятий. Если у вас есть обратная связь или столкнуться с какими -либо проблемами, сообщите нам об этом, подав отчет.
Если вы не видите журналов Breadcrumb , мы рекомендуем проверить конфигурацию вашего приложения для Google Analytics . Убедитесь, что вы выполнили следующие требования:
Вы включили Google Analytics в своем проекте Firebase.
Вы включили обмен данными для Google Analytics . Узнайте больше об этом настройке в управлении настройками обмена данными аналитики
У тебя естьк вашему приложению. Этот SDK должен быть добавлен в дополнение к Crashlytics SDK.
Вы используетеДля всех продуктов, которые вы используете в своем приложении.
Если вы не видите оповещения о скорости, убедитесь, что вы используете
Если вы не видите без сбоев метрик (например, пользователи и сеансы без сбоев) или видите ненадежные метрики, проверьте следующее:
Убедитесь, что вы используете
Убедитесь, что настройки сбора данных не влияют на качество ваших метрик без сбоев:
Если вы включите отчетность, отключив автоматическую отчетность по сбою, информация о сбое может быть отправлена только в Crashlytics от пользователей, которые явно выбрали сбор данных. Таким образом, на точность метриков без сбоев будет затронута, поскольку Crashlytics имеет информацию о сбоях от этих пользователей (а не всех ваших пользователей). Это означает, что ваши непревзойденные показатели могут быть менее надежными и менее отражающими общую стабильность вашего приложения.
Если у вас отключен автоматический сбор данных, вы можете использовать
sendUnsentReportsдля отправки Crashlytics отчетов на устройстве. Использование этого метода отправит данные о сбое в Crashlytics , но не данные о сеансах , которые приводят к тому, что консольные диаграммы показывают низкие или нулевые значения для метрик без сбоев.
См. Понятно, без сбоев метрик .
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:
Project members with any of the following roles can view and delete existing notes and write new notes on an issue.
- Project Owner or Editor , Firebase Admin , Quality Admin , or Crashlytics Admin
Project members with any of the following roles can view the notes posted on an issue, but they cannot delete or write a note.
- Project Viewer , Firebase Viewer , Quality Viewer , or Crashlytics Viewer
Интеграции
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
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:
- For the first time ever, Crashlytics gets a crash report about Crash "A". Crashlytics opens a corresponding issue for that crash (Issue "A").
- You fix this bug quickly, close Issue "A", and then release a new version of your app.
- 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:
You've enabled Google Analytics in your Firebase project.
You've enabled Data sharing for Google Analytics . Learn more about this setting in Manage your Analytics data sharing settings
У тебя естьto your app. This SDK must be added in addition to the Crashlytics SDK.
You're using thefor all the products that you use in your app.
If you're not seeing velocity alerts, make sure that you're using the
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 the
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
sendUnsentReportsto 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 .
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:
Project members with any of the following roles can view and delete existing notes and write new notes on an issue.
- Project Owner or Editor , Firebase Admin , Quality Admin , or Crashlytics Admin
Project members with any of the following roles can view the notes posted on an issue, but they cannot delete or write a note.
- Project Viewer , Firebase Viewer , Quality Viewer , or Crashlytics Viewer
Интеграции
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
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:
- For the first time ever, Crashlytics gets a crash report about Crash "A". Crashlytics opens a corresponding issue for that crash (Issue "A").
- You fix this bug quickly, close Issue "A", and then release a new version of your app.
- 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.