Some version information first: I am talking about the module com.crashlytics.sdk.android:crashlytics:2.8.0 and the Gradle plugin io.fabric.tools:gradle:1.25.1.
I was excited to learn that Crashlytics can also log caught exceptions as nonfatal issues. But this doesn't seem to work the way I hoped it would.
Firstly, logException doesn't seem to trigger anything until the app is restarted after a crash. This renders the feature of logging nonfatal issues (app caught the exception and kept on running!) pretty useless.
Secondly, if there are two or more exceptions logged via logException before a crash, the last one wins and the others vanish into the eternal void. This is what I have observed during my experiments.
So what am I missing? Is there a way to tell Crashlytics that a logged exception should be sent out right away? Is this the way Crashlytics is intended to work, or is the implementation flawed? As it stands now, log und logException aren't of much use.
You're not missing anything, Crashlytics wasn't really designed with that use case in mind, which is related more to analytics than to crash reporting. You could instead use Answers APIs, also part of the Fabric platform. Note however, that there is no guarantee the logs will be sent right away, there is some delay before they appear in the dashboard.
Related
I had Firebase Crashlytics installed in my Android app, and the reporting is operational.
However, I found that some issues are very similar:
And it'd be helpful if I could treat them as the same issue when debugging or closing.
Is there any chances I can merge them into one?
It is not possible to merge these crashes. Crashlytics will group the issues based on the frame being blamed. In this case, even though they look similar, the frame is under a different line number.
You could file a feature request for this behavior.
Recently, I decided to migrate from Parse and use the lighter and easier tool, Crashlytics. I've been playing with the interface for a long time and it is already responding every developer needs except one thing:In addition to close an issue, Is it possible to permanently remove a crash from the crash list in dashboard?
In my case, I planted some force crashes (by throwing a simple RuntimeException) in order to test the performance and stability of Crashlytics, but now seeing them beside real crashes is completely on my nerve. Any idea on how to get rid of them?
You can't completely remove the crashes. You can, however, only show crashes that are open instead of showing all crashes as it sounds like you might be doing. You could also increment your app version, but that may not be of that much use to just hide crashes that you forced for testing.
You can close the issue, so it will not be shown again for the reported version.
I was wondering if it is possible to somehow view all the crashes (or non-fatals) for a particular issue from the Crashlytics dashboard. Even though the exception is logged in the same place in the code, the stack trace and exception type/message may be different. But since the exception is logged in the same place, Crashlytics treats it as the same issue.
As far as I can tell, you can only view the latest crash or non-fatal. Is there a way?
Or alternatively, are there Crashlytics SDK calls that would allow me to differentiate the crashes?
Yes you can. To view all crashes for a particular issue follow this
Select the particular issue
In Next Screen you can use Arrow mark to see all crashes for a particular issue
Here I have two crashes for the same Issue #4 with different date.
Obviously with code, errors can occur anywhere. So without having try/catch blocks all over the place (which as I understand it is major overhead) how do I allow errors to bubble up to the application level and then handle them there? Or at the very least, record the error somehow for troubleshooting? I found information on an product called ACRA, but the setup instructions are geared for Eclipse projects. I am using Mono for Android in Visual Studio 2010.
That's a bit of an "It depends" question.
The appropriate handling of an errors is going to depend on what the recovery strategy needs to be, how much information you want the user to see etc.
I wouldn't worry how many Try/Catch blocks you use - just use them wherever you need to handle an error that gets thrown - if they're everywhere, your strategy is probably wrong.
It terms of logging and later interrogation, you can log caught errors using the Android.Util.Log class.
These can be interrogated (provided you're debugging on your own device) using Logcat.
There's some more info on logging and Logcat here.
Found this project that writes crash info to google docs. Android Crasher
Why and when should I use the android Logging? Should it be used only for debugging purposes? It seems to me that if kept in a production application, it would slow it down considerably.
One key part of my question, is WHEN it should be used...in what cases should I need it? Are there any 'best practices' for using this?
This may be a very stupid or amateur question, but I've never understood the need or felt compelled to use it. I may be missing something.
http://developer.android.com/reference/android/util/Log.html
Also - I already know that logging for errors/verbose/info/etc are different, and some are discarded when not debugging. Please don't reiterate the information that's in the class overview without giving me an explanation why. Thanks!
I agree with you, I never really used it either. I much prefer debugging over log reading (and unit-testing over debugging), when trying to figure out what's happening and getting an error.
Some people argue it can be useful to log "additional details" when your application crashes and get an exception, but I usually reply to them that the exception itself should hold that additional details when necessary, and expose them in its getMessage. Thus, the default stack trace that's included in the LogCat is more than enough to see what's going on.
But anyway, it's always nice to have the possibility to log something, even though I haven't found it really useful so far, you never know when it might help :)
Regarding my comment, see Preparing for Release. (Showing logging should be removed before release, hence not being used in production).
Turn off logging and debugging
Make sure you deactivate logging and disable the debugging option before you build your
application for release. You can deactivate logging by removing calls to Log methods
in your source files.
I used logging the other day, I fired off another thread to do some work but I needed to check some data being produced in the thread, without logging or displaying Toast's, how could I get the values? I'm tried debugging/stepping through code in Eclipse before and just run into several problems.
With logging, I can log each value, view the logcat and know exactly what my code is doing.
You usually debug only when you know there is something wrong. (And when you know, you might write additional test cases.)
With logging (at the INFO level, for example), you can add some additional information to trace the data in the app. This allows you to find out that there is something wrong.
Thus, it adds a higher-level overview.
Additionally, it can be easily disabled, does not slow the app down significantly (if done right), and might thus offer another avenue of approach to see if everything works correctly, with few disadvantages and some advantages. (See also Logging vs. Debugging, especially the links in #smonff's answer.)