На этой странице представлена помощь по устранению неполадок и ответы на часто задаваемые вопросы об использовании Crashlytics. Если вы не можете найти то, что ищете, или вам нужна дополнительная помощь, обратитесь в службу поддержки Firebase .
Общие вопросы по устранению неполадок/часто задаваемые вопросы
Если вы не видите пользователей без сбоев, журналы навигации и/или оповещения о скорости, мы рекомендуем проверить конфигурацию вашего приложения для Google Analytics.
Убедитесь, что вы включили Google Analytics в своем проекте Firebase.
Убедитесь, что для Google Analytics включен обмен данными на странице «Интеграция» > «Google Analytics» консоли Firebase. Обратите внимание, что настройки обмена данными отображаются в консоли Firebase, но управляются в консоли Google Analytics.
В дополнение к Firebase Crashlytics SDK убедитесь, что вы добавили Firebase SDK для Google Analytics в свое приложение ( iOS+ | Android ).
Убедитесь, что вы используете последние версии всех своих Firebase SDK ( iOS+ | Android ).
В частности, убедитесь, что вы используете как минимум следующие версии Firebase SDK для Google Analytics: iOS+ — v6.3.1+ (v8.9.0+ для macOS и tvOS) | Android — v17.2.3+(BoM v24.7.1+) .
Вы можете заметить два разных формата проблем, перечисленных в таблице «Проблемы» в консоли Firebase. И вы также можете заметить функцию под названием «варианты» в некоторых из ваших задач. Вот почему!
В начале 2023 года мы выпустили улучшенный механизм анализа для группировки событий, а также обновленный дизайн и некоторые дополнительные функции для новых задач (например, вариантов!). Ознакомьтесь с нашим недавним сообщением в блоге , чтобы узнать все подробности, но вы можете прочитать ниже основные моменты.
Crashlytics анализирует все события вашего приложения (такие как сбои, нефатальные ошибки и ANR) и создает группы событий, называемые проблемами — все события в задаче имеют общую точку отказа.
Чтобы сгруппировать события по этим проблемам, улучшенный механизм анализа теперь рассматривает многие аспекты события, включая кадры в трассировке стека, сообщение об исключении, код ошибки и другие характеристики платформы или типа ошибки.
Однако в этой группе событий трассировка стека, приведшая к сбою, может быть другой. Другая трассировка стека может означать другую основную причину. Чтобы представить эту возможную разницу в задаче, мы теперь создаем варианты внутри задач — каждый вариант представляет собой подгруппу событий в задаче, которые имеют одну и ту же точку сбоя и аналогичную трассировку стека. С помощью вариантов вы можете отлаживать наиболее распространенные трассировки стека в рамках проблемы и определять, приводят ли различные основные причины к сбою.
Вот что вы почувствуете благодаря этим улучшениям:
Обновленные метаданные отображаются в строке задачи.
Теперь стало проще понимать и сортировать проблемы в вашем приложении.Меньше повторяющихся проблем
Изменение номера строки не приводит к возникновению новой проблемы.Более простая отладка сложных проблем с различными первопричинами
Используйте варианты для отладки наиболее распространенных трассировок стека в задаче.Более содержательные оповещения и сигналы
Новая проблема на самом деле представляет собой новую ошибку.Более мощный поиск
Каждая проблема содержит дополнительные метаданные с возможностью поиска, такие как тип исключения и имя пакета.
Вот как внедряются эти улучшения:
Когда мы получим новые события из вашего приложения, мы проверим, соответствуют ли они существующей проблеме.
Если совпадений нет, мы автоматически применим к событию наш более умный алгоритм группировки событий и создадим новую задачу с обновленным дизайном метаданных.
Это первое большое обновление, которое мы вносим в нашу группу событий. Если у вас есть отзывы или вы столкнулись с какими-либо проблемами, сообщите нам об этом, заполнив отчет.
Crashlytics поддерживает отчеты ANR для приложений Android с устройств под управлением Android 11 и выше. Базовый API, который мы используем для сбора ANR ( getHistoricalProcessExitReasons ), более надежен, чем подходы на основе SIGQUIT или сторожевого таймера. Этот API доступен только на устройствах Android 11+.
Если в некоторых ваших 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 может не найти связанныеBuildIds. Мы рекомендуем вам рассмотреть возможность использования стандартного расположения для общих библиотек.Убедитесь, что вы не удаляете
BuildIdв процессе сборки.Обратите внимание, что следующие советы по устранению неполадок применимы как к ошибкам ANR, так и к собственным сбоям.
Проверьте, существуют ли
BuildId, запустивreadelf -nдля ваших двоичных файлов. ЕслиBuildIdотсутствуют, добавьте-Wl,--build-idк флагам вашей системы сборки.Убедитесь, что вы случайно не удаляете идентификаторы
BuildId, чтобы уменьшить размер APK.Если вы храните разделенные и неразделенные версии библиотеки, убедитесь, что в вашем коде указана правильная версия.
Может быть несоответствие между количеством ошибок ANR в Google Play и Crashlytics. Это ожидается из-за различий в механизме сбора и представления данных ANR. Crashlytics сообщает об ANR при следующем запуске приложения, тогда как Android Vitals отправляет данные ANR после возникновения ANR.
Кроме того, Crashlytics отображает только ошибки ANR, возникающие на устройствах под управлением Android 11+, по сравнению с Google Play, который отображает ошибки ANR с устройств с принятыми службами Google Play и согласием на сбор данных.
Цепочки инструментов LLVM и GNU имеют разные значения по умолчанию и процедуры для сегмента двоичных файлов вашего приложения, предназначенного только для чтения, что может генерировать несогласованные трассировки стека в консоли Firebase. Чтобы избежать этого, добавьте в процесс сборки следующие флаги компоновщика:
Если вы используете компоновщик
lldиз цепочки инструментов LLVM, добавьте:-Wl,--no-rosegmentЕсли вы используете компоновщик
ld.goldиз цепочки инструментов GNU, добавьте:-Wl,--rosegment
Если вы по-прежнему видите несоответствия трассировки стека (или если ни один из флагов не относится к вашей цепочке инструментов), попробуйте вместо этого добавить следующее в процесс сборки:
-fno-omit-frame-pointer
Плагин Crashlytics включает в себя настраиваемый генератор файлов символов Breakpad . Если вы предпочитаете использовать свой собственный двоичный файл для создания файлов символов Breakpad (например, если вы предпочитаете создавать все собственные исполняемые файлы в вашей цепочке сборки из исходного кода), используйте необязательное свойство расширения symbolGeneratorBinary , чтобы указать путь к исполняемому файлу.
Вы можете указать путь к бинарному файлу генератора символов Breakpad одним из двух способов:
Вариант 1. Укажите путь через расширение
firebaseCrashlyticsв файлеbuild.gradle.Добавьте следующее в файл
build.gradleуровня приложения: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.symbolGeneratorBinary, чтобы указать путь к исполняемому файлу.Вы можете вручную обновить файл свойств Gradle или обновить файл через командную строку. Например, чтобы указать путь через командную строку, используйте следующую команду:
./gradlew -Pcom.google.firebase.crashlytics.symbolGenerator=breakpad \ -Pcom.google.firebase.crashlytics.symbolGeneratorBinary=/PATH/TO/BREAKPAD/DUMP_SYMS \ app:assembleRelease app:uploadCrashlyticsSymbolFileRelease
Если вы видите следующее исключение, скорее всего, вы используете версию DexGuard, несовместимую с SDK Firebase Crashlytics:
java.lang.IllegalArgumentException: Transport backend 'cct' is not registered
Это исключение не приводит к сбою вашего приложения, но не позволяет ему отправлять отчеты о сбоях. Чтобы исправить это:
Убедитесь, что вы используете последнюю версию DexGuard 8.x. Последняя версия содержит правила, необходимые для Firebase Crashlytics SDK.
Если вы не хотите менять версию DexGuard, попробуйте добавить следующую строку в правила обфускации (в конфигурационный файл DexGuard):
-keepresourcexmlelements manifest/application/service/meta-data@value=cct
Когда приложение использует обфускатор, который не раскрывает расширение файла, Crashlytics по умолчанию создает каждую проблему с расширением файла .java .
Чтобы Crashlytics мог создавать проблемы с правильным расширением файла, убедитесь, что ваше приложение использует следующую настройку:
- Использует Android Gradle 4.2.0 или выше
- Использует R8 с включенной обфускацией. Чтобы обновить приложение до R8, следуйте этой документации .
Обратите внимание, что после обновления до описанной выше настройки вы можете начать видеть новые проблемы .kt , которые являются дубликатами существующих проблем .java . См. FAQ , чтобы узнать больше об этом обстоятельстве.
Начиная с середины декабря 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 Analytics.
CRASH_FREE_USERS_PERCENTAGE = 1 - ( CRASHED_USERS / ALL_USERS ) x 100
Когда происходит сбой, Google Analytics отправляет событие типа
app_exception, а CRASHED_USERS представляет количество пользователей, связанных с этим типом события.ALL_USERS представляет собой общее количество пользователей, взаимодействовавших с вашим приложением за период времени, который вы выбрали в раскрывающемся меню в правом верхнем углу панели инструментов Crashlytics.
Процент пользователей, у которых не возникло сбоев, представляет собой совокупность данных по времени , а не среднее значение.
Например, представьте, что у вашего приложения три пользователя; мы будем называть их пользователем A, пользователем B и пользователем C. В следующей таблице показано, какие пользователи взаимодействуют с вашим приложением каждый день и у кого из этих пользователей в тот день произошел сбой:
| Понедельник | Вторник | Среда | |
|---|---|---|---|
| Пользователи, взаимодействовавшие с вашим приложением | А, Б, С | А, Б, С | А, Б |
| Пользователь, у которого произошел сбой | С | Б | А |
В среду процент безаварийных пользователей составляет 50% (у 1 из 2 пользователей не было сбоев).
Двое ваших пользователей взаимодействовали с вашим приложением в среду, но только у одного из них (Пользователь Б) не было сбоев.За последние 2 дня процент пользователей, у которых не было сбоев, составляет 33,3% (у 1 из 3 пользователей не было сбоев).
Трое из ваших пользователей взаимодействовали с вашим приложением за последние два дня, но только у одного из них (пользователь C) не было сбоев.За последние 3 дня процент пользователей, у которых не было сбоев, составляет 0 % (у 0 из 3 пользователей не было сбоев).
Трое пользователей взаимодействовали с вашим приложением за последние три дня, но ни у одного из них не было сбоев.
Заметки позволяют участникам проекта комментировать определенные проблемы с вопросами, обновлениями статуса и т. д.
Когда участник проекта публикует заметку, она помечается адресом электронной почты его учетной записи Google. Этот адрес электронной почты виден вместе с заметкой всем участникам проекта, имеющим доступ к просмотру заметки.
Ниже описаны права доступа, необходимые для просмотра, записи и удаления заметок:
Участники проекта с любой из следующих ролей могут просматривать и удалять существующие заметки, а также писать новые заметки по проблеме.
Участники проекта с любой из следующих ролей могут просматривать заметки, опубликованные по проблеме, но не могут удалять или писать заметки.
Интеграции
Если ваш проект использует Crashlytics вместе с Google Mobile Ads SDK, вполне вероятно, что отчеты о сбоях мешают регистрации обработчиков исключений. Чтобы устранить эту проблему, отключите отчеты о сбоях в Mobile Ads SDK, вызвав disableSDKCrashReporting .
После того как вы свяжете Crashlytics с BigQuery, новые наборы данных, которые вы создаете, автоматически размещаются в США, независимо от местоположения вашего проекта Firebase.
Поддержка платформы
Firebase Crashlytics NDK не поддерживает ARMv5 (armeabi). Поддержка этого ABI была удалена с NDK r17.
Регрессивные проблемы
У проблемы был регресс, когда вы ранее закрыли проблему, но Crashlytics получает новый отчет о повторном возникновении проблемы. Crashlytics автоматически повторно открывает эти регрессивные проблемы, чтобы вы могли решить их соответствующим образом для своего приложения.
Вот пример сценария, который объясняет, как Crashlytics классифицирует проблему как регрессию:
- Crashlytics впервые получает отчет об аварии «А». Crashlytics открывает соответствующую проблему для этого сбоя (проблема «A»).
- Вы быстро исправляете эту ошибку, закрываете проблему «А», а затем выпускаете новую версию своего приложения.
- Crashlytics получает еще один отчет о проблеме «А» после того, как вы закрыли проблему.
- Если отчет относится к версии приложения, о которой Crashlytics знал, когда вы закрыли проблему (это означает, что версия отправила отчет о сбое для любого сбоя вообще), Crashlytics не будет считать проблему регрессом. Вопрос останется закрытым.
- Если отчет относится к версии приложения, о которой Crashlytics не знал, когда вы закрыли проблему (это означает, что версия вообще никогда не отправляла отчеты о сбоях для каких-либо сбоев), тогда Crashlytics считает проблему регрессированной и повторно открывает проблему. .
Когда проблема регрессирует, мы отправляем предупреждение об обнаружении регрессии и добавляем к проблеме сигнал регрессии, чтобы вы знали, что Crashlytics повторно открыла проблему. Если вы не хотите, чтобы проблема снова открывалась из-за нашего алгоритма регрессии, «заглушите» проблему, а не закрывайте ее.
Если отчет относится к старой версии приложения, которая никогда не отправляла отчеты о сбоях, когда вы закрывали проблему, Crashlytics считает проблему регрессированной и повторно открывает ее.
Это может произойти в следующей ситуации: вы исправили ошибку и выпустили новую версию своего приложения, но у вас все еще есть пользователи старых версий без исправления ошибки. Если случайно одна из этих старых версий вообще не отправляла никаких отчетов о сбоях, когда вы закрыли проблему, и эти пользователи начали сталкиваться с ошибкой, то эти отчеты о сбоях вызовут регрессию проблемы.
Если вы не хотите, чтобы проблема снова открывалась из-за нашего алгоритма регрессии, «заглушите» проблему, а не закрывайте ее.