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).
Related
I have a Xamarin.Android app that has been in production and stable for several years, but is now exhibiting crashing, during startup, when running on a specific device type (Zebra TC21/TC26), but only after it has been unused for 3 or 4 days.
If the app is used regularly, it performs reliably, but when left idle for an extended period, it crashes, during restart, apparently because Android has recycled the Application object, perhaps as described here.
The strange thing is that neither a forced close of the app nor a reboot of the device resolves the problem. Only after uninstalling and reinstalling the app will it run again.
To make matters worse, I can't seem to get any useful log data from the app when it is running on Zebra devices. The app is extensively instrumented for logging (via Loggly) and it works reliably for all other Android device types that I have tested, but Zebra test runs yield no log events.
I apologize that this is a vague question, but I have spent a huge amount of time trying to diagnose this issue and I am at a loss for what to try next. Any suggestions would be very welcome and I am happy to post more details, if required.
UPDATE: As suggested by #Cheesebaron, I have examined the device log, retrieved from a Zebra, which shows that the crash is due to an NRE. I attribute this to a required dependency not being injected correctly, but I am not sure what that tells me about the root cause of the problem, which clearly doesn't occur during normal operation. I am not an expert in deciphering Android logs, and I am curious what I should be looking for to understand the specific OS event that tipped the app into a failing state. Just being able to reproduce the issue in real time would be a great step forward.
I am also puzzled why this issue is not cleared by restarting the device. Does this indicate a data/settings corruption or could there be some other explanation? Is there anything in the device log that I should be looking for to understand this?
I am happy to post the device logs (or excerpts) if anyone feels inclined to review them.
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.
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)
Debugging in Eclipse works excellent, however, my app causes my whole system to crash on unknown interval in under unknown situations. I have never been able to replicate this issue while having a connection with my computer and thus I can't find the issue.
Are there any other ideas on how to approach this type of issues?
A friend of mine used this Bootlog Uptime app to get crash logs from system crashes.
I never tested it but as far as I know you can get the log from the system crash as well. At least worth a try...
Assuming your application crashes before it takes down the device, a generic error reporting solution like ACRA (which you probably want as part of your application anyway) might get you the relevant bits of information to find the source of the problem (bits of the logcat, memory usage, etc).
If the app doesn't crash, you can set it up to periodically send out the same information. There might be a trend visible up to the point where it dies.
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.