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.
Related
I remember to have seen that Android started to restart apps when these crash for the first time. But I can't find this statement in the documentation or release notes.
Do you know since which OS/SDK version this happen? Maybe I was dreaming?
I've tested with 4 different model devices and the behaviour seems to vary on device rather than android version.
Auto starting after a crash is not a standard behavior of Android. More commonly after an app crash, you are shown a dialog with an option to open the app again if you choose to do so. You can see the dialog in the following document.
Reference: https://developer.android.com/games/optimize/crash
Also, I think auto-restart of an app after a crash is not a good feature. If there is something wrong with the app causing a crash when you launch the app, then there is a good chance it may crash again with the auto relaunch. Why have the user see the crash again unnecessarily.
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.
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'm developing an app using Android Studio. Now I'm facing a bug where the app crashes when I do the following:
Press the home button.
Use the device for some 10 minutes (i.e. wait).
Run the app again. Crash!
There is no easier way to reproduce the crash (nothing in onResume). As you can imagine, this is kind of hard to debug. In an ideal world, the OS (Android 5.0) would let me send a bug report to myself. The app is not published yet, so I don't see how I could get hold of the crash dump. Is it saved somewhere on the device?
I did try to debug the app from Developer Options, using the wait for debugger setting and then attaching to the process from within Android Studio. This, however, seems to make the bug go away. (The app is probably restarted.)
Q: How do I find the cause of the crash given these circumstances?
My intuition tells me that you are using some 'static' variables/fields in your application.
When your app goes to background and it is not used, system could drop process (because of memory management) of this application from memory. When you come back, Application object and all application proces in system is recreated, so all static variables are cleared/reinitialized.
Am i right?
Try looking into your logcat and if that is not an option for you. try some crash analytic like the following.
https://mint.splunk.com/
Integrate it in your app just with a single line and whenever your app get crashed you will receive a mail of your crash logs..
it will easily help you to determine your crash scenario..
And just out of curiosity are you using any singlton class in your Activity.?
I found the crash using adb as described here. Never realized that logcat keeps logs from previous executions. Nice!
I am trying to use the bug reporting tool of android (the one you can use via power tool shortcut). When should I take the bug report? I have a service crashing and it's reproducible. Should I get the bug report before it happens (which means the tool collects data starting from that point and stops collecting when an error happens) or immediately after the service crashes (which means the error logs are hold in some cache or something like that and the tool gets the last report).
Use the tool after the crash happens. What it does is read out the logs, so the error must have occurred already, otherwise it won't be there.