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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Вы включили обмен данными для Google Analytics . Узнайте больше об этой настройке в разделе Управление настройками обмена данными 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 или watchdog. Этот 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+)
  • Плагин Gradle Crashlytics v2.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 отправляет данные ANR после возникновения ANR.

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

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

LLVM и GNU toolchains имеют различные значения по умолчанию и обработки для сегмента только для чтения двоичных файлов вашего приложения, что может привести к несогласованным трассировкам стека в консоли 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 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 получает еще один отчет о проблеме «A» после того, как вы ее закрыли.
   • Если отчет получен из версии приложения, о которой Crashlytics знал, когда вы закрыли проблему (то есть, версия отправила отчет о сбое для любого сбоя вообще), то Crashlytics не будет считать проблему регрессивной. Проблема останется закрытой.
   • Если отчет получен из версии приложения, о которой Crashlytics не знал, когда вы закрыли проблему (это означает, что версия вообще никогда не отправляла никаких отчетов о сбоях), то Crashlytics посчитает проблему регрессировавшей и откроет ее повторно.

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

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

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

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

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