android - fabric io

Problemas con el registro de mis datos con crashlytics

Question

Estoy tratando de obtener registros con algunos datos de servicio con Crashlytics en mi aplicación de Android. Pero no veo mis registros en el panel de control. Utilicé esto:

String myLog = getServiceData(); //myLog is not null and non-empty
CrashLytics.log(myLog);

y esto:

String myLog = getServiceData(); //myLog is not null and non-empty
CrashLytics.log(Log.Error, getString(R.string.app_name), myLog);

Intenté generar una excepción en mi aplicación y manejarla, pero no tengo resultados:

try {
int a = 0;
a = 1/a;
}
catch (Exception e) {
CrashLytics.log(myLog);
}

También leí en el registro de Crashlytics no enviado . Necesito inicializar crashlytics antes del registro de datos. Puse Crashlytics.start (this) en el evento onStart () de mi actividad pero no volví a ver mis registros en el panel. Por fin, intenté colocar Crashlitycs.start (esto) directamente antes de registrar mis datos, pero aún no tengo registros en el panel.

Plase, dígame qué hago mal y cómo obtener mis registros personalizados en el panel de control de Crashlytics?

Answer 1

De acuerdo con la base de conocimientos de Crashlytics:

Los mensajes registrados están asociados con sus datos de fallos y son visibles en el panel de control de Crashlytics si observa el bloqueo específico en sí.

Y desde mi experiencia esto parece cierto. Sin embargo, no estoy seguro de qué determina qué registro está asociado con un informe de bloqueo. ¿Tal vez una ventana de tiempo (bloqueo temporal) o un número limitado de registros (antes del bloqueo) esté asociada con el informe de bloqueo?

Sin embargo, la base de conocimientos de Crashlytics dice que se pueden registrar excepciones:

Todas las excepciones registradas aparecerán como problemas "no fatales" en el panel de control de Crashlytics.

Así que si cambiaste tu try / catch a:

try {
int a = 0;
a = 1/a;
}
catch (Exception e) {
CrashLytics.logException(e);
}

entonces debería aparecer en el panel de control de Crashlytics.

Answer 2

En lugar de capturar la excepción y registrarla, puede usar RuntimeExceptions:

throw new RuntimeException("Test crash");

Android Studio no le pedirá que los detecte, por lo que la aplicación finaliza y carga el informe inmediatamente.

Answer 3

Tuve una situación similar. Con algunos experimentos, pude deducir las reglas del comportamiento de Crashlytics.

Estoy compartiendo mis aprendizajes aquí para que (con suerte) los demás no tengan que pasar por el arduo y lento proceso que hice para resolverlo.

Crashlytics solo cargará un informe de error "en el tablero" inmediatamente si se produce una excepción fatal. En otras palabras, cuando tu aplicación falla. Y nada se muestra en el panel a menos que y hasta que se cargue un informe de bloqueo.

Si registra una excepción no fatal, utilizando CrashLytics.logException(e) , no se cargará un informe de bloqueo hasta la próxima vez que se reinicie su aplicación. Por lo tanto, no verá la excepción en el panel de control de Crashlytics hasta que se reinicie una aplicación.

Puede saber cuándo se produce una carga porque verá este tipo de mensaje en LogCat:

07-17 19:30:41.477 18815-18906/com.foo.bar I/Crashlytics﹕ Crashlytics report upload complete: 55A9BA0C01D7-0001-462D-B8B4C49333333.cls

Un mensaje de registro de Crashlytics debe estar asociado con una excepción fatal o no fatal para aparecer en el panel de control.

Además, los mensajes de registro que no están asociados con una excepción no sobreviven al reinicio de la aplicación.

Entonces, si haces algo como registrar algunos mensajes, luego reinicia la aplicación, luego la aplicación lanza una excepción, o registra una excepción no fatal usando Crashlytics.logException() , los mensajes de registro se perderán . No aparecerán en el tablero de mandos.

Si desea registrar algunos mensajes sin una excepción grave, use una o más declaraciones Crashlytics.log() seguidas de Crashlytics.logException() .

Para verificar que funciona, haga que se ejecute el código y luego reinicie la aplicación. En el panel de control, debería ver los registros asociados con el problema creado para la excepción no fatal. En la naturaleza, solo tendrás que confiar en que tus usuarios reiniciarán la aplicación con cierta regularidad.