I have Crashlytics properly configured in my app. I can see crash reports.
I tried to add a custom log to the crash reports but I do not see anything in the report.
I tried to move the log out of the uncaughtException handler and in that case I see the logs.
So if I log while the application is running properly then I see the logs in the crash report when the application crashes but if I try to add a log in my uncaughtException handler these logs are not shown.
is this the proper behaviour?
I'm on Android.
To log I just use:
Crashlytics.log(myLog);
myLog is a non-null non-empty string (I checked it)
You are right you need to move the Crashlitycs.start before registering your uncaughtException handler.
I thought that an explanation could be that the logs are sent to the server asynchronously and if the application gets killed before they are sent you don't see them in the crash report. I checked and that is not the case: even if you wait for a while before calling the default handler nothing happen.
The only explanation for now is that Crashlitycs uncaughtException handler is called before mine.
So to fix the issue it is enough to register the handler after calling Crashlytics.start
Related
Can it possible to get the logs before it print into terminal? Or I want to know how the crash crashlytics takes logs.
Crashlytics doesn't have anything to do with the log system. It hooks the top level exception handler, so that exceptions that are not handled by the program normally are handled by the library.
H, I miss a lot the old time when users could comment on crashes in Android.
Now I realise that the best way to reproduce something like this would be if the app could detect when it was open for the first time right after a Fatal error, so I/the app can advise the user to send a personalised comment on how the crash happened.
Is there a way, using Firebase/Crashlytics, to know that the app crashed previously, when opening an app?
If there is an uncaught exception in an activity (or service) the activity is forcably closed and the previos activity of the app is shown. If the last Activity causes the crash the app is closed.
What you can do to detect this situation is to register a global-uncaught-exception-handler that writes `firebaseException=true" to a file/app-settings if the exception comes from firebase before calling the previous global-uncaught-exception-handler.
In every Activity-s onCreate you can load firebaseException and act according (do not forget to write firebaseException=false after.
I have never worked with Crashlytics but i assume that it also hooks into uncaught-exception-handler so it is important that Crashlytics is initialized before you set your own handler and that your handler calls the previous uncaught-exception-handler when done
You may use custom Crashlytics webhooks to notify your service about crashes and reach back next time is opened.
I'm writing a chat application on Android using the Parse SDK (1.5.1) in which i use obj.saveInBackground(SaveCallback) to create a new chat message on the cloud. The problem is that sometimes the SaveCallback never get called (I put a log inside the callback and that log never be printed out).
This usually occurs when i continuously send out about 20-30 chat messages, for each message, i use saveInBackground to create it, but the callback just be called for the first messages (for example, it was ok to create message 1 to 30, but for message 30-40, the callbacks were not called and they couldn't be created).
It seems that when the problem occurs, all the "ParseRequest.NETWORK_EXECUTOR-thread-xx" threads are in the Wait status (maybe they are waiting for results sent back from server?).
Please take a look at the application's threads snapshot when this problem occurs.
Is there anyone encountered a similar problem before? Could you please give me advices how to deal with it?
Thanks!
I faced similar problem in case of files, so I used recursion function. may be you have to call recursion method of saving messages until all messages are saved to parse...
What is the usual way on Android to stop my application if it has reached an unrecoverable error.
finish() will not do it, since it wont stop any running services or threads. Furthermore I would like to inform the user what has happend and please him to send an error log.
As far as I googled, it seems like there is no way to close my application and open a special crashreport activity or something else to show the user whats going on or send a crash log.
I think you should throw unhandled runtime exception. In such case android will kill all your process. Also I suggest you to use ACRA. This library will help you to get crash report (via email, google docs, etс.) and it can show customizable error dialog to a user.
You should check this out. This could be your solution.
ACRA
Check the basic setup guide to start using the library. ACRA - Basic Setup
While ACRA is an okay solution, if you want to implement your own logging of unhandled exceptions try Thread.setDefaultUncaughtExceptionHandler(). That way you can get any exceptions that are thrown and not caught, and log them the way you like. You need to implement Thread.UncaughtExceptionHandler and pass it to that method.
With an Activity, it would look something like this in onCreate():
getMainLooper().getThread().setUncaughtExceptionHandler(new MyUncaughtExceptionHandler());
I use ACRA in my android application. It's very useful but sometimes boring.
Sometimes, there are several asynchronous tasks running in the background. And for season, all of them failed(e.g. can't connect to internet). ACRA will show the toast message again and again, and refused to exit.
Is it able to let ACRA just catch the first exception? Or just show the toast message once?
Update
add a demo: https://github.com/freewind/android-acra-multi-reports
There are 4 activities in this project. The last one will throw exception and each previous activity will throw exception in onActivityResult. You can see ACRA will report many times before exiting.
That sounds to me like you should actually catch some exceptions and don't let all of them bubble up.
ACRA registers a Thread.UncaughtExceptionHandler on the main thread. Here all uncaught exceptions (as the handler's name suggests) get processed. Usually that means that the application is about to crash and ACRA will do its reporting magic. ACRA uses several Threads itself to do its work and will wait until everything is finished before it actually kills the application's process. So I'd guess that if there are coming a lot of exceptions, ACRA is just so busy to process them that it won't come to the point were it would kill the process.
You could register your own implementation of UncaughtExceptionHandler to catch exceptions and decide when to hand them through to ACRA and when to do something else. If I'm not mistaken, ACRA will call through to the UncaughtExceptionHandler that has been registered before the ACRA init. So you could also try to chain those handlers.