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.
Related
So I have an android application that has a myriad of activities (intents?) which all do their own thing. We were wanting to create a sort of debug log though, one where you can see what the user has been through and error that occurs. You may have had to send one before if you've run into a bug with a program you've used.
My initial thoughts are to just create a class where I can send information/data to and it just writes it onto a text file. It would need to be accessible across all the activities so that I can easily write to it and re-use it.
I do wonder whether that's a good way to go through, noted that it doesn't really save any actual errors but only data I tell it to. And I'm not sure if its a great idea to be constantly opening->writing->closing a file for a debug log.
Is there a smarter way? Or a common pattern that would be good to use?
Thanks so much!
Sentry's Android SDK, will automatically report errors and exceptions in your application.
The Sentry SDK catches the exception right before the crash and builds a crash report that will persist to the disk. The SDK will try to send the report right after the crash, but since the environment may be unstable at the crash time, the report is guaranteed to send once the application is started again.
You can see full documentation here
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.
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!
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