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

iOS+ Android Flutter Unity

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

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

Просмотр разных форматов (а иногда и «вариантов») для некоторых задач в таблице «Проблемы» .

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Не вижу журналы навигации

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

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

• Вы включили обмен данными для Google Analytics . Подробнее об этом параметре читайте в разделе «Управление настройками общего доступа к данным Google Analytics».

• У тебя естьдобавлен Firebase SDK для Google Analyticsв ваше приложение. Этот SDK необходимо добавить в дополнение к Crashlytics SDK.

• Вы используетепоследние версии Firebase SDKдля всех продуктов, которые вы используете в своем приложении.

  Особенно убедитесь, что вы используете как минимум следующую версию Firebase SDK для Google Analytics :
  Android — v17.2.3+ ( BoM v24.7.1+).

Не вижу оповещений о скорости

Если вы не видите оповещения о скорости, убедитесь, что вы используетеCrashlytics SDK v18.6.0+ (или Firebase BoM v32.6.0+).

Отсутствие показателей отсутствия сбоев (или наблюдение ненадежных показателей)

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

• Убедитесь, что вы используетеCrashlytics SDK v18.6.0+ (или Firebase BoM v32.6.0+).

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

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

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

Как рассчитываются пользователи без сбоев?

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

Почему сообщения об ошибках ANR сообщаются только для Android 11+?

Crashlytics поддерживает отчеты ANR для приложений Android с устройств под управлением Android 11 и более поздних версий. Базовый API, который мы используем для сбора ошибок ANR ( getHistoricalProcessExitReasons ), более надежен, чем SIGQUIT или подходы на основе сторожевого таймера. Этот API доступен только на устройствах Android 11+.

Почему в некоторых ANR отсутствуют свои BuildId ?

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

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

  Если вам не хватает BuildId для Android 11 и некоторых ANR Android 12, то, скорее всего, вы используете устаревший SDK, плагин Gradle или и то, и другое. Чтобы правильно собирать BuildId для этих ANR, вам необходимо использовать следующие версии:

  • Crashlytics Android SDK v18.3.5+ ( Firebase BoM v31.2.2+)
  • Плагин Crashlytics Gradle v2.9.4+

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

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

• Убедитесь, что вы не удаляете BuildId во время процесса сборки.

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

  • Проверьте, существуют ли BuildId , запустив readelf -n в ваших двоичных файлах. Если BuildId отсутствуют, добавьте -Wl,--build-id к флагам вашей системы сборки.

  • Убедитесь, что вы случайно не удаляете BuildId , пытаясь уменьшить размер APK.

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

Различия между отчетами ANR на панели управления Crashlytics и в консоли Google Play

Между количеством ошибок ANR в Google Play и Crashlytics может быть несоответствие. Это ожидаемо из-за разницы в механизме сбора и предоставления данных ANR. Crashlytics сообщает об ошибках ANR при следующем запуске приложения, тогда как Android Vitals отправляет данные ANR после возникновения ошибки ANR.

Кроме того, Crashlytics отображает только ошибки ANR, возникающие на устройствах под управлением Android 11+, в отличие от Google Play, который отображает ошибки ANR с устройств со службами Google Play и принятым согласием на сбор данных.

Различия между трассировками стека NDK в информационной панели Crashlytics и logcat

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

• Если вы используете компоновщик lld из цепочки инструментов LLVM, добавьте:

  -Wl,--no-rosegment

• Если вы используете компоновщик ld.gold из набора инструментов GNU, добавьте:

  -Wl,--rosegment

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

-fno-omit-frame-pointer

Как использовать собственный двоичный файл генератора файлов символов Breakpad для NDK?

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

Примечание. Для двоичных файлов Android требуется версия генератора файлов символов Breakpad для Linux.

Вы можете указать путь к двоичному файлу генератора символов Breakpad одним из двух способов:

• Вариант 1. Укажите путь через расширение firebaseCrashlytics в файле build.gradle

  Добавьте следующее в файл build.gradle.kts уровня приложения:

  Плагин Gradle v3.0.0+

  android {
    buildTypes {
      release {
        configure<CrashlyticsExtension> {
          nativeSymbolUploadEnabled = true
          // Add these optional fields to specify the path to the executable
          symbolGeneratorType = "breakpad"
          breakpadBinary = file("/PATH/TO/BREAKPAD/DUMP_SYMS")
        }
      }
    }
  }

  более низкие версии плагина

  android {
    // ...
    buildTypes {
      // ...
      release {
        // ...
        firebaseCrashlytics {
          // existing; required for either symbol file generator
          nativeSymbolUploadEnabled true
          // Add this optional new block to specify the path to the executable
          symbolGenerator {
            breakpad {
              binary file("/PATH/TO/BREAKPAD/DUMP_SYMS")
            }
          }
        }
     }
  }

• Вариант 2. Укажите путь через строку свойства в файле свойств Gradle.

  Вы можете использовать свойство com.google.firebase.crashlytics.breakpadBinary , чтобы указать путь к исполняемому файлу.

  Вы можете вручную обновить файл свойств Gradle или обновить файл через командную строку. Например, чтобы указать путь через командную строку, используйте следующую команду:

  ./gradlew -Pcom.google.firebase.crashlytics.symbolGenerator=breakpad \
    -Pcom.google.firebase.crashlytics.breakpadBinary=/PATH/TO/BREAKPAD/DUMP_SYMS \
    app:assembleRelease app:uploadCrashlyticsSymbolFileRelease
  

Отсутствие сбоев при использовании Dexguard

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

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

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

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

2. Если вы не хотите менять версию DexGuard, попробуйте добавить следующую строку в правила обфускации (в файле конфигурации DexGuard):

   -keepresourcexmlelements manifest/application/service/meta-data@value=cct

Почему я вижу сбои из-за файлов .kt , помеченных как проблемы .java ?

Когда приложение использует обфускатор, который не раскрывает расширение файла, Crashlytics по умолчанию генерирует каждую проблему с расширением файла .java .

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

• Использует Android Gradle 4.2.0 или выше.
• Использует R8 с включенной обфускацией. Чтобы обновить приложение до R8, следуйте этой документации .

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

Почему я вижу проблемы .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 .

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

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

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

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

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

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

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

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

Интеграции

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

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

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

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

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

Поддерживает ли Crashlytics Armeabi?

Firebase Crashlytics NDK не поддерживает ARMv5 (armeabi). Поддержка этого ABI была удалена начиная с NDK r17.

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

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

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

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

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

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

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

Почему я наблюдаю регрессирующие проблемы в старых версиях приложений?

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

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

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

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

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