Crash reporting FAQ

Follow

Do you support metadata?

Yes, Countly Crash Reporting provides device info as in Analytics by default, in addition to crash related data. You can add custom logs only to be delivered in case of a crash, independent of custom events. Moreover, you can set custom segments to specify which external libraries and frameworks are included in your project and their versions.

Do you capture exceptions?

Yes, system signals (iOS) and uncaught exceptions (iOS & Android) are automatically handled by the Countly SDKs. You can also submit exceptions handled by yourself as well.

Do you catch out of memory (OOM) crashes?

As terminations due to low memory cannot be considered as regular exceptions neither in iOS, nor in Android, it is not possible to handle them correctly. We're working on a solution for ANR in Android.

How long does it take for a crash to appear on my dashboard?

Countly SDKs send crash reports as soon as possible, before the app is completely terminated. If report can not be sent at that time, it is stored to be sent on next app launch. This means that you can see crashes on your dashboard immediately assuming the user has an active internet connection when the crash occurs.

This method is different from other crash reporting tools, as they send crash reports when the application is opened again. However in this case, user may have never opened your application again so corresponding crash information is never sent.

Is there a quick way to force a crash?

Countly SDKs currently do not have any methods to force crashes, but it is really easy to do it in a few lines of code. For example on iOS you can copy & paste this snippet:

NSArray* array = @[@"one",@"two",@"three"]; 
NSString* crashHere = array[5];

and one for on Android:

String array[] = {"one", "two", "three"};
String crashHere = array[5];

How do I use custom logging?

On iOS you need to use crashLog: method:

[Countly.sharedInstance crashLog:@"custom crash log"];

On Android there is Countly.addCrashLog():

Countly.sharedInstance().addCrashLog("This is custom log example number " + 1);

What is a fatal and non-fatal crash?

Fatal crashes are your app's unhandled crashes, which made user to exit app. These are collected automatically and reported to Countly server, if you enable this option in SDK.

Non-fatal crashes are crashes that you handled yourself in the app (like through try and catch blocks) but still can optionally report to Countly server for later examination.

Are crashes grouped?

Yes, we have a method that groups crashes so similar crashes populate under the same group.

If I mark a crash as resolved and it reappears, what’s the status of the crash?

When you mark a crash as resolved, you mark it resolved for a specific version. If the crash happened on same version or lower, it still stays resolved. If the crash happens on a version that is higher, crash state is changed to "Reoccurred".

If I mark the status as hidden and it reappears, then do I see it again?

If you mark the crash as hidden, then it stays hidden no matter what.

If a crash happened before, and it reoccurs again with a different version, then would it be duplicated?

This depends. If code was changed a lot between versions, then it might be a new crash, however if code remained mostly the same and has similar stack trace, then it would be the same crash.

Is it possible to use Android SDK with another crash SDK?

It should be fine to use Countly together with another crash SDK. If you would like to track caught exception, you would just pass them to both SDK's. When catching uncaught exceptions with both, there are some uncertainties. Although in Android there can be only one uncaught exception handler, you can save the previous handler and when receiving a uncaught exception, pass it also to the saved one. We can't be certain how other SDK's are implemented or if the OS would give enough time to propagate the exception through all handlers. Therefore if you want to use Countly with another crash SDK, we advise to initialize Countly as the last one.

Is it possible to use iOS SDK with another crash SDK?

In iOS there can be only one uncaught exception handler. Even though it is possible to save the previous handler and pass the uncaught exception to the previous handler as well, it is not safe to assume that it will work in all cases. As we can't know how other SDKs are implemented or whether iOS will give enough time for all the handlers to do their work before terminating the app. So, we advise to use Countly as the only crash handler.

Was this article helpful?
0 out of 0 found this helpful

Looking for help?