Эта страница переведена с помощью Cloud Translation API.

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

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

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

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

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

Различия между отчетами 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 , чтобы указать путь к исполняемому файлу.

Вы можете указать путь к бинарному файлу генератора символов 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

Если вы видите следующее исключение, скорее всего, вы используете версию 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
```

Почему я вижу сбои из-за файлов `.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 Analytics.

1 - ( CRASHED_USERS / ALL_USERS )

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

Вы можете просмотреть количество событий app_exception для вашего приложения на панели управления Analytics. Обратите внимание, что из-за незначительных различий в том, как обрабатываются сбои, число app_exception , отображаемое на панели управления Analytics, может иногда отличаться от числа, используемого при подсчете пользователей без сбоев.

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

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

	Понедельник	Вторник	Среда
Пользователи, взаимодействовавшие с вашим приложением	А, Б, С	А, Б, С	А, Б
Пользователь, у которого произошел сбой	С	Б	А

В среду процент безаварийных пользователей составляет 50% (у 1 из 2 пользователей не было сбоев).
Двое ваших пользователей взаимодействовали с вашим приложением в среду, но только у одного из них (Пользователь Б) не было сбоев.
За последние 2 дня процент пользователей, у которых не было сбоев, составляет 33,3% (у 1 из 3 пользователей не было сбоев).
Трое из ваших пользователей взаимодействовали с вашим приложением за последние два дня, но только у одного из них (пользователь C) не было сбоев.
За последние 3 дня процент пользователей, у которых не было сбоев, составляет 0 % (у 0 из 3 пользователей не было сбоев).
Трое пользователей взаимодействовали с вашим приложением за последние три дня, но ни у одного из них не было сбоев.

Интеграции

Приложение также использует 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 классифицирует проблему как регрессию:

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

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

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

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

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

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

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

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