I have been writing a simple Android application (one Activity).
I would really like to gather crash reports from actual user sessions. I know there are some nice 3rd-party libraries. I also read that Google Play Console (Android vitals) should be providing some basic telemetry including crash reports. I was thinking that, to keep things simple, I would stick with the Android vitals for now.
I was wondering whether there is anything I need to do on the Application side to get the crash reports. Or should I just simply let the App crash?
I handle exception that can be handled, but there is always a possibility that one makes it to, say, onCreate. 'onCreate' does not allow throwing checked exceptions though. If I cannot handle it, should I just wrap it in Runtime exception and throw that instead?
Thanks.
Here's an article for a similar approach, https://proandroiddev.com/hide-your-crashes-gracefully-and-still-report-them-9b1c85b25875 However it does not rely on the Android OS crash reporting process; i.e. I don't think you would see the crashes in Android Vitals if you follow the steps described in the article.
You might be able to adapt it though, mainly in terms of restarting the app after the crash occurs.
Related
I have been running into a problem with my application, which I have no idea why. The following is:
the application is a large, commercial project, which makes several connections to the database, with a login system and everything else
I noticed that if I leave the app in the background for about 10 minutes, for example, it terminates my connection and restarts everything again, forcing me to log in again.
The only guarantee I can give is that they are not connection problems with my server, as in my tests it never failed.
Anyone who might have any idea why?
(I know that the explanation of the problem was a little vague, but the situation is very vague even for me)
How did I find my problem?
The user of my application was using a bluetooth barcode reader, which was programmed to automatically turn off after a period of inactivity. I noticed that whenever the bluetooth device turned off, my application would lose its previous state if it was in the background. Using the LogCat tool, I realized that my process was being killed by the system itself. The messages always looked like these:
W/ActivityManager: Force finishing activity
my.project/.view.activities.MyActivity
I/ActivityManager: Process my.project (pid 12984) has died
After much research, I found that the Android system interprets some external events as configuration changes, eg screen rotation change, Bluetooth device connection/disconnection, etc.
When such a change happens, Android, by default, kills your app's process and restarts it completely again, so that the app adapts to the new behavior. In my case, there was a NullPointerException in the code, which I hadn't handled correctly, so the application went back to the beginning, losing its state data.
However, in other application screens the mentioned Exception didn't occur (so it doesn't go back to login when starting), but even so I lost some screen data, like something that was typed in an EditText, for example.
How did I solve it?
On researching again, I found that you can let Android handle these configuration changes itself, telling it not to restart its process. To do this, just add in your Manifest, in the desired activity, the line:
android: configChanges = "keyboard | keyboardHidden | navigation"
As in my case the problem was with a bluetooth keyboard, I added these options keyboard | keyboardHidden; some keyboard models, for some reason, also change Android navigation, so I added navigation. After this change, done! No more problems!
P.S. 1: Unfortunately, not everything always works out. Adding android: configChanges won't work if your activity has fragments (I'm still trying to figure out how to solve this).
P.S. 2: This is not a good practice, I need to make that clear to you. For me, it's okay to do it this way, as my application responds well to changes. After all, my app is simple. Only use this feature that I explained if it is your last option or, if like me, your application is not so complex. Remember: this is not a magic solution to problems; in my specific case it worked fine, but for you, it might break your application.
P.S. 3: I recommend taking a look at https://developer.android.com/guide/topics/manifest/activity-element#config, in the android subtopic: configChanges. Listed are all the configuration changes a device can make.
What I Have
I have CrashAnaytics setup for my app and it works flawlessly so far. I also have disabled it for my debug build and is only enabled for my release builds.
Crashlytics crashlyticsKit = new Crashlytics.Builder()
.core(new CrashlyticsCore.Builder().disabled(BuildConfig.DEBUG).build())
.build();
Fabric.with(this, crashlyticsKit);
What I Want
In my app, I sometimes deliberately need to throw an exception and crash the app. You can consider it as a feature where the user can force close or crash the app if they want to.
throw new FakeCrashException();
Now, the problem is that I am getting plenty of these crashes reported in CrashAnalytics as well. I know that these are not real crashes and there is no point in logging them in CrashAnalytics.
Is there a way I can exclude this specific exception from being reported by CrashAnalytics?
Mike from Fabric here.
Have you thought about logging these as Caught Exceptions instead of FakeCrashes?
Using: Crashlytics.logException(e); may accomplish what you're looking for as this would not be considered crashes and wouldn't affect your crash-free statistics. More information within the documentation.
This is not really a programming question but more of a debuging question.
I have an app that works fine, however, it is a bit unreliable when we try to resume the app.
What happens is, if we background/ minimize it, and than try to resume the app by clicking the app's icon. It sometimes crashes and it sometimes doesn't. It is unreliable that we can not trace what is the issue and why it occurs.
Any possible solution or places we can start tracing for the issue, please advise me :)
Cheers
Not a programming question but it is a development question. It is extremely inconsistent didn't know how to even find the stack-trace
How I solved it was wrapped everything with a bunch of try catch and print the error stacktrace to the screen(or email the developer), finally found out the error was with one of the 3rd party LocationService library I was using.
Note: Location Service is not very reliable, please be caution in how you want to use that feature Android Devs!
I'm having quite tough problem while developing a testing framework for android apps. The text got a bit long so the actual question is in bold for those that don't want to read the context.
Basically, what I'd like to achieve right now is to trace user activity while he's using the application as one of the features. There's my app that manages context data all the time and developer's app - the one being tested. My idea to do this was to get coordinates where user touched the screen along with taking a screenshot simultaneously. Then I'd use the coordinates to mark the spot on the screenshot to get the idea of what user was doing the whole time with the app. Take hints on user experience and trace crashes.
Non-system apps cannot take a screenshot for security reasons, but application itself can take a screenshot of its Activities without much trouble for non-rooted users, e.g. like here. My only hope here is to interfere with developers' code to implement the functionality of doing so while my testing app is running. Each Activity then would have to extend my overridden Activity instead of regular one, implement an interface, implement broadcast receiver etc.
I am going to write a library for developer who would like his app to be tested with my framework. I'd like it to do the job for me and be as non-intrusive as it's possible for him to use. How to achieve that the best way?
Ideal case would assume linking the library to project with maybe a small addition in manifest that'd get the job done and after just unlinking, removing that bit of xml in manifest for production.
That's an open question. I don't expect any bits of code, but some nifty Java trick, Android OS functionality or even completely other approach that'd solve my problem
I tried to be as clear as possible with the question, but that's a quite tough matter for me to describe so that could have turned out contrary. Don't hesitate to ask me for more details, to speak my mind more clearly or even rewrite the question. Thank you all very much for help!
My app is crashing randomly and I dont know why.
I saw that there are apps that when there is a force close, you can choose between force close and report.
How can I add it to my application?
Thank you
Ron
I think the best approach in your case is to have the crashes reported automatically in the background as soon as one occurs.
This is achievable through integrating a product like Instabug.
It offers you a plenty of details regarding every crash including the crash stack trace, all network/console logs, an environment snapshot, and visual reproduction steps.
For full disclosure, I work at Instabug. I'm glad to help if you have any questions.
That will be shown to users automatically when your app is delivered via Android market. Although personally, I ACRA because it gives you more information and you can use it regardless of whether the app is distributed via market or not e.g. for beta testing.
http://code.google.com/p/acra/
My favorite is BugSense. Good user interface, good report details, open source client library or use with ACRA.
http://bugsense.com/
I think that comes automatically when you've uploaded your app to the market.
If one of your users decide to report it instead of choosing force close you should get a report in your admin panel (https://market.android.com/publish/Home) Next to the price of the app in question you should find a link called something like error(X) where X is the number of different error reports sent to you.
You could also look into this:
http://code.google.com/p/android-remote-stacktrace/
It's something you can add to your app that makes it sent the stack trace to your server. I find this one use full sometimes!
//André
Although the question is a little old, I guess it’s useful to refresh the information. ACRA is good, but I would also recommend you to try Crashlytics. It has a very simple interface. Thanks to the simplicity, you can easily install and use this tool. It allows not only making ordinary crash reports but also catching NDK crashes.
Here is a comprehensive review of different helpful bug and crash reporting tools for those who are curious in details: http://cases.azoft.com/report-bugs-effectively-mobile-app-testing-tools/