My application has been published for a while. I have never received any crash reports through Google play developer page. Then I integrated Flurry to see how the audience is behaving. On Flurry dashboard I saw that my application occasionally crashes. The crashes are irregular and produce very different stack traces. I cannot understand why the crashes appear and I cannot reproduce them on my devices and emulators - application just works perfectly. My problem is that it is difficult to fix something that really works for you :)
Flurry dashboard shows that the crash ratio is 1-2% of the sessions - not that big. So I was thinking just to accept that. But the crashes still bother me in the back of my head. I want your advice - should I accept this small crash ratio or really investigate the crashes? What crash ratios do you have for your applications ?
As for me, it's been impossible to get zero crashes for any app, so my suggestion is learning to live with it :)
You cannot test your app in all devices and android versions, and even if you would, there may be installed applications conflicting with yours. Imagine for instance you create an app that needs to use the camera, but there's another app installed that doesn't properly release the camera resources; that will surely mess with your app, and there's no much you can do to predict nor change it.
So, just make sure you test your app in as much devices as you can (low, mid and high range), focusing in the most popular devices/android versions (I guess Flurry reports which devices are your app installed in)
Related
a colleague of mine is working on a legacy ReactNative app. There is quite a lot of code both in JavaScript and Java land, the latter being related to HERE Maps SDK.
Two of our clients experience multiple crashes every day and we cannot figure out why as we have no error reports.
Bugsnag was installed early last year (circa jan 2020) and we have nothing on there to help us. Nothing to be found in Google Console either. App just stops.
To help us debug we've added a logging system which sends debug info to our backend via dedicated API calls.
It roughly consists of logging "start of function A", "end of function A" etc so we know what the app is doing. We don't always enable it as it tends to make the app even more unstable.
In parallel to that we managed to get an idea of when the app crashes via login events that are sent by Firebase Auth when user re-launches the app.
Looking at our logs around the time of crash doesn't help us as 1) they look the same as when it all works and 2) we haven't covered all method calls as there are way too many (in JS and Java).
Our users run the app on a Samsung Galaxy Active Tab 2 mounted in the cabin of a tractor. Some use a Galaxy Active Tab 3 and also have the issue.
We have run through various theories :
Could it be too hot in the cabin so Android shuts down? No, tablet is always on according to clients.
Could it be related to a change in voltage? When WE try to plug and unplug everything continues to work fine.
Could it be Android that decides the app is consuming too much battery or CPU (GPS is needed for our app) so it shuts it down? We've let our app in the foreground for hours with no problem.
We logged in with customers' credentials (they are aware) and could not replicate the issue.
Customers interest in helping us find the issue is slowly fading away so we can't keep on asking them to install a patched version every week.
First there was just one client but now we have at least 3 more users complaining about mysterious crashes.
We're a bit stomped as to what to do.
Has anyone any idea of an ultimate catch all library? Or a syslog on the tablet where we could get more info?
Thanks in advance for your help!
After much testing my colleagues managed to easily reproduce the error and found the root cause: poor memory management in one method in Java land.
Said method was responsible for changing markers orientation on the map but it duplicated markers when their orientation changed. It resulted in a high memory consumption and when it reached a certain point Android would just kill all running apps.
My colleague fixed the leak and we're good! Onto the next bug now. :)
The below reasoning is based on hardware failure. If your software hasn't drastically changed (the app or the operating system), then this is a likely scenario:
The Tab 2 was released in 2012, so we're talking about a device that is up to 9 years old. If the users all use the same hardware, and the software hasn't been changed for a while, it could be some kind of hardware failure. It could be related to the vibrations of the tractor, moisture over time, or just because they used the tablet more intensively than you use yours. There could be something (semi-)loose or the memory (SSD or RAM) could start becoming faulty.
It can be a software error too of course, but it's unlikely if you haven't updated in a long time - assuming the tablets haven't been updated either.
Could you perhaps swap your tablet with one of a customer. Preferrably a customer that has the issue most often. Then observe if the issue is resolved.
This way, you'll be able figure out if it is related to the tablet (being broken) or the environment (tractor) it is being used in.
If the issue persists after a tablet swap, it's either the environment or the software, but you'd have ruled out the hardware.
If the issue is resolved, you'll know for sure it's the hardware at fault.
I created an app and it’s live in Google Play. I constantly test it to eliminate bugs and crashes. The app is almost crash-free. But sometimes I receive bad reviews from my users (only Samsung devices users) (1-2% of Samsung devices). They say that the app opens but displays a screen with app title and gets stuck on it (I don’t even have such screen in my app).
I am not receiving any crash reports or ANR reports about something that can be related to this issue. I tested on all Samsung devices I could find (friends, relatives, hired people on Upwork) but everything just works fine.
Is there anything that can cause this issue?
Maybe somewhere in your code does not work on those devices or there is an exception you caught but forgot to log it.
Try analyzing your logs and use some services like Microsoft Appcenter to find out which part of your app does not work properly.
An app I published crashes on certain specific devices. I keep receiving messages from the users that just "can't open" the app. This of course lowers the rating on Google Play.
On Android Vitals there's no reference of these crashes, all crashes I receive are managed and happen after the app start, but if I filter for device model or Android version looking for those that tell me that the app didn't open, I find absolutely NOTHING.
I installed crashlytics, and I was astonished by the fact that I received completely different error communications, so Android Vitals seems just partial?
And anyway, still NOTHING about early crashes.
I tried to install the app on the official Samsung online emulator for some devices that are suspected to crash, and still... guess... NOTHING. So I can't even test it and I'm completely helpless.
How can I do to stop this bad app behaviour, that reduces the number of my happy users? I need a really reliable way to detect ALL crashes.
thank you.
Use a Crash Reporting Tool such as Firebase Crash Reporting. Everyone professional uses such tool
https://firebase.google.com/docs/crash/
As already mentioned, you can use a crash reporting tool/framework, additionally you should be aware, that offline crashed might not get reported and if the user doesn't allow you to use the internet, there is no way around that, as far as I'm aware.
In the meantime you could try excluding the devices that you suspect to produce crashed while you are trying to fix it (if you care about the rating).
I've an app in the market with a few crash reports of "java.lang.RuntimeException: native typeface cannot be made". This is covered elsewhere on SO and I know where in my code it is. That's not my problem - the problem is finding out which Android version and handset type is causing it. I've never seen this on any handsets the app is tested on, nor does any version of Android on the emulators raise it. The only crash errors I see are these and always on "Platforms OTHER". I'm assuming if a different crash was reported I'd get a better clue regarding the platform - I'd expect to see "8", "11" etc.
It's a paid app. It happens right on first run so the users are cancelling the purchase.
Does anyone know what this platform is please?
In my experience, the developer console reports very few of the crashes occurring in your app.
If your app already requests internet permission you can use an error reporting library.
I use ACRA in my app. It's very easy to integrate and you'll be amazed at the number of crashes that don't get reported in the market developer console.
The Platforms section displays the device the crash occurs on, not API level. However, as you've seen, it's very limited. The only values I've seen besides OTHER are
T-Mobile myTouch 3G
Nexus One
Droid
Anything else is lumped in with OTHER. Obviously, the list of devices it separates out is vastly incomplete and not very helpful. Until Google improves it, the Platforms sections is essentially useless and I recommend using a third party library to get better information.
I have recently published my second app on the Android Market. I've gotten a few e-mails about the app crashing on open, and all users were using the Motorola Backflip. It seems to work fine on all other devices. The app shows the background image, but crashes right after that.
Is there something different I have to do when coding for that device?
The strange thing is that it is very similar to my first app, which seems to work just fine for them. The major difference is that my second app is a paid app, and uses Android Licence Verification. My implementation should catch any license errors though, and I've tested this on my device.
Users have uninstalled and reinstalled the app without success. I'm stumped.
The other thing they're reporting is that the icon doesn't even show properly, but rather is a gear in a box, which makes me think that something goes awry very early in the installation process.
The solution was to have a user install aLogcat on their phone to send me the log.
It had to do with onCreateDialog. I was returning several dialogs, but one of them actually called .show(), which it's not supposed to do, of course. The thing is that this didn't cause an error on any phones except for the Backflip. The emulators also didn't error, or even warn me about it.
I have a motorola backflip and i can say that is not a good product....it's crashing for a lot of things....don't worry, your app is not wrong, the phone is wrong...