Ответ 1
Вот он: Crashlytics.getInstance().core.logException(e);
Кто-нибудь знает вызов замены в Crashlytics для logException(), который, как представляется, устарел с 2.2.4? Моя проблема в том, что у меня есть исключения, которые я поймаю, но я подозреваю, что они приводят к дальнейшим ошибкам, которые затем приводят к сбою приложения. Я хочу также регистрировать все обработанные исключения и видеть их в одном месте. Использовал Flurry, но, похоже, не сделал этого трюка, где Crashlytics выглядит более надежным. Я хочу, чтобы все они были в одном и том же инструменте, так как в тысячу раз легче сочетать исключения только в одном месте, а не связывать их вместе с LogEntries, Flurry и Crashlytics. Как только я получу основные элементы аварийной ситуации, я медленно удалю вызовы logException() и просто ищут реальные жесткие сбои.
спасибо!
Вот он: Crashlytics.getInstance().core.logException(e);
Crashlytics обновлено до 2.3.2. Если вы посмотрите на эту документацию, она устарела. Ознакомьтесь с новым методом исключения здесь
Документация Crashlytics и документация Fabric.io не очень понятны, поэтому просто чтобы быть ясным:
если вы компилируете с com.crashlytics.sdk.android:crashlytics:[email protected]
или старше, используйте этот метод:
Crashlytics.logException(e);
если вы используете com.crashlytics.sdk.android:crashlytics:[email protected]
, используйте этот метод:
Crashlytics.getInstance().core.logException(e);
Если вы используете com.crashlytics.sdk.android:crashlytics:[email protected]aar
, вы можете использовать любой метод:
Crashlytics.getInstance().core.logException(e);
CrashlyticsCore.getInstance().logException(e);
Crashlytics.logException(e);
Включение: если вы хотите положиться на документацию Fabric.io, убедитесь, что вы не компилируете с помощью crashlytics v2.3.xxx