На этой странице представлена помощь по устранению неполадок и ответы на часто задаваемые вопросы об использовании 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, возможно, не сможет найти связанныеBuildId
s. Мы рекомендуем вам рассмотреть возможность использования стандартного расположения общих библиотек.Убедитесь, что вы не удаляете
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, несовместимую с Firebase Crashlytics SDK:
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.
Процент пользователей без сбоев представляет собой совокупность с течением времени , а не среднее значение.
Например, представьте, что в вашем приложении три пользователя; мы будем называть их «Пользователь А», «Пользователь Б» и «Пользователь С». В следующей таблице показано, какие пользователи ежедневно взаимодействовали с вашим приложением и у каких из этих пользователей в тот день произошел сбой:
Понедельник | Вторник | Среда | |
---|---|---|---|
Пользователи, которые взаимодействовали с вашим приложением | А, Б, С | А, Б, С | А, Б |
Пользователь, у которого произошел сбой | С | Б | А |
В среду ваш процент пользователей без сбоев составил 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 получает отчет о сбое Crash «A». Crashlytics открывает соответствующую проблему для этого сбоя (проблема «A»).
- Вы быстро исправляете эту ошибку, закрываете проблему «А», а затем выпускаете новую версию своего приложения.
- Crashlytics получит еще один отчет о проблеме «А» после того, как вы ее закроете.
- Если отчет относится к версии приложения, о которой Crashlytics знал, когда вы закрыли проблему (это означает, что версия вообще отправила отчет о сбое при любом сбое), то Crashlytics не будет считать проблему регрессированной. Вопрос останется закрытым.
- Если отчет относится к версии приложения, о которой Crashlytics не знала, когда вы закрыли проблему (это означает, что версия вообще никогда не отправляла отчет о сбое для какого-либо сбоя), то Crashlytics считает, что проблема регрессировала, и повторно откроет проблему. .
Когда проблема регрессирует, мы отправляем предупреждение об обнаружении регрессии и добавляем к проблеме сигнал регрессии, чтобы вы знали, что Crashlytics повторно открыла проблему. Если вы не хотите, чтобы проблема открывалась повторно из-за нашего алгоритма регрессии, «приглушите» проблему, а не закрывайте ее.
Если отчет относится к старой версии приложения, которая вообще не отправляла никаких отчетов о сбоях, когда вы закрыли проблему, Crashlytics считает, что проблема регрессировала, и повторно откроет проблему.
Такая ситуация может возникнуть в следующей ситуации: вы исправили ошибку и выпустили новую версию своего приложения, но у вас все еще есть пользователи более старых версий без исправления ошибки. Если случайно одна из этих старых версий вообще не отправила никаких отчетов о сбоях, когда вы закрыли проблему, и эти пользователи начали сталкиваться с ошибкой, то эти отчеты о сбоях вызовут регрессирующую проблему.
Если вы не хотите, чтобы проблема открывалась повторно из-за нашего алгоритма регрессии, «приглушите» проблему, а не закрывайте ее.
,На этой странице представлена помощь по устранению неполадок и ответы на часто задаваемые вопросы об использовании 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, возможно, не сможет найти связанныеBuildId
s. Мы рекомендуем вам рассмотреть возможность использования стандартного расположения общих библиотек.Убедитесь, что вы не удаляете
BuildId
во время процесса сборки.Обратите внимание, что следующие советы по устранению неполадок применимы как к ошибкам ANR, так и к собственным сбоям.
Проверьте, существуют ли
BuildId
, запустивreadelf -n
в ваших двоичных файлах. ЕслиBuildId
отсутствуют, добавьте-Wl,--build-id
к флагам вашей системы сборки.Убедитесь, что вы случайно не удаляете
BuildId
, пытаясь уменьшить размер APK.Если вы храните удаленные и неразделенные версии библиотеки, обязательно укажите правильную версию в своем коде.
Может быть несоответствие между подсчетом ANRS между Google Play и Crashlytics. Это ожидается из -за разницы в механизме сбора и сообщения данных ANR. Crashlytics сообщает ANRS, когда приложение дальше начинается, тогда как 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 (например, если вы предпочитаете создавать все собственные исполняемые файлы в вашей цепочке сборки из источника), используйте необязательное свойство расширения symbolGeneratorBinary
, чтобы указать путь к исполняемому файлу.
Вы можете указать путь к двонатору генератора файлов Symbole 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, которая несовместима с Firebase Crashlytics SDK:
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 теперь может определить, записан ли каждый класс в приложении в котлине, и включать правильное имя файла в подписи выпуска. Сборы теперь правильно приписываются файлам .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 Dashboard.
Процент без сбоев пользователей-это агрегация с течением времени , а не среднее значение.
Например, представьте, что в вашем приложении есть три пользователя; Мы назовем их пользователем A, пользователем B и пользователем C. Следующая таблица показывает, какие пользователи занимаются вашим приложением каждый день, и у кого из этих пользователей был сбой в тот день:
Понедельник | Вторник | Среда | |
---|---|---|---|
Пользователи, которые занимались вашим приложением | А, Б, С | А, Б, С | А, Б |
Пользователь, у которого был сбой | С | Б | А |
В среду ваш процент без сбоев пользователей составляет 50% (1 из 2 пользователей был без сбоев).
В среду двое из ваших пользователей занимались вашим приложением, но только один из них (пользователь B) не имел сбоев.В течение последних 2 дней ваш процент без сбоев пользователей составляет 33,3% (1 из 3 пользователей был без сбоев).
Три из ваших пользователей, занимающихся вашим приложением за последние два дня, но только один из них (пользователь C) не имел сбоев.В течение последних 3 дней ваш процент без сбоев пользователей составляет 0% (0 из 3 пользователей были без сбоев).
Три из ваших пользователей занимались вашим приложением за последние три дня, но ноль из них не имел сбоев.
Значение пользователей без сбоев не следует сравнивать в течение разных периодов времени. Вероятность того, что один пользователь испытывает аварию, увеличивается больше раз, когда он использует ваше приложение, поэтому ценность пользователей без сбоев, вероятно, будет меньше в течение более длительных периодов времени.
Примечания позволяют участникам проекта комментировать конкретные вопросы с вопросами, обновлениями статуса и т. Д.
Когда участник проекта публикует заметку, она помечена электронной почтой их учетной записи Google. Этот адрес электронной почты видна, наряду с примечанием для всех участников проекта с доступом для просмотра примечания.
Следующее описывает доступ, необходимый для просмотра, записи и удаления примечаний:
Члены проекта с любой из следующих ролей могут просмотреть и удалять существующие заметки и писать новые заметки по вопросу.
Члены проекта с любыми из следующих ролей могут просмотреть заметки, опубликованные по вопросу, но они не могут удалить или написать заметку.
- Зритель проекта, зритель Firebase , качественный просмотр или Crashlytics Viewer
Интеграции
Если ваш проект использует Crashlytics вместе с SDK Google Mobile Ads, вполне вероятно, что репортеры с аварией вмешиваются при регистрации обработчиков исключений. Чтобы решить проблему, отключите отчеты о сбоях в мобильной рекламе SDK, позвонив disableSDKCrashReporting
.
После того, как вы связываете Crashlytics с BigQuery, новые наборы данных, которые вы создаете, автоматически расположены в Соединенных Штатах, независимо от места вашего проекта Firebase.
Поддержка платформы
Firebase Crashlytics NDK не поддерживает ARMV5 (Armeabi). Поддержка этого ABI была удалена с NDK R17.
Регрессивные проблемы
Вопрос возникла регрессия, когда вы ранее закрыли проблему, но Crashlytics получает новый отчет о том, что проблема повторно зарегистрировалась. Crashlytics автоматически вновь открывает эти регрессивные проблемы, чтобы вы могли решать их как необходимые для вашего приложения.
Вот пример сценария, в котором объясняется, как Crashlytics классифицирует проблему как регрессию:
- Впервые Crashlytics получает отчет о аварии о Crash "A". Crashlytics открывает соответствующую проблему для этого сбоя (выпуск «a»).
- Вы быстро исправляете эту ошибку, закрываете проблему «A», а затем выпускаете новую версию вашего приложения.
- Crashlytics получает еще один отчет о выпуске «A» после того, как вы закрыли проблему.
- Если отчет взят из версии приложения, о которой Crashlytics знал, когда вы закрыли проблему (это означает, что версия отправила отчет о сбое для любого сбоя), то Crashlytics не рассматривает эту проблему как регрессированную. Проблема останется закрытой.
- Если отчет взят из версии приложения, о которой Crashlytics не знал о том, когда вы закрыли проблему (это означает, что версия никогда не отправляла никакого отчета о сбое для какого-либо сбоя), то Crashlytics рассматривает вопрос об регрессивности и повторно откроет проблему .
Когда проблема регрессирует, мы посылаем оповещение о обнаружении регрессии и добавляем сигнал регрессии в проблему, чтобы вы знали, что Crashlytics вновь открыла проблему. Если вы не хотите, чтобы проблема была вновь открыта из-за нашего алгоритма регрессии, «отключить» проблему вместо того, чтобы закрыть ее.
Если отчет взят из старой версии приложения, которая вообще никогда не отправляла отчеты о сбоях, когда вы закрыли проблему, то Crashlytics рассматривает проблему, регрессирующая и вновь откроет проблему.
Эта ситуация может произойти в следующей ситуации: вы исправили ошибку и выпустили новую версию вашего приложения, но у вас все еще есть пользователи на старых версиях без исправления ошибки. Если случайно одна из этих старых версий никогда не отправляла никаких отчетов о сбоях вообще, когда вы закрыли проблему, и эти пользователи начинают встречаться с ошибкой, то эти отчеты об аварии вызывают регрессивную проблему.
Если вы не хотите, чтобы проблема была вновь открыта из-за нашего алгоритма регрессии, «отключить» проблему вместо того, чтобы закрыть ее.