Diagnosing Sporadic Errors
So, you wrote an app and released it to the world, perhaps via the Android Market, perhaps via other venues. People are starting to use your application…and your app is blowing up. It works fine when you test it, though, and so you are only getting limited comments as to what may be wrong.
This, of course, sucks.
It is more likely than ever on Android, since there is a plethora…nay, a veritable cornucopia of available devices, each with their own ROMs and their own problems. While the vast majority of functionality will remain the same across all Android devices, there will be corner cases where there are flaws. Those flaws might be in your code, where you made assumptions that just do not hold up well in practice. Those flaws might be with specific devices, where OEM twiddling with Android has broken your app.
Here are some tips for how to get to the bottom of the problem:
First, gather concrete data. Relying simply on Market comments and the like is not going to get you far. Instead, you need to get at the Java stack trace of the crashes in the field. Fortunately, there are multiple tools to help collect that data, from Flurry to DroidDrop.
Then, analyze those stack traces. It may be that a single stack trace will be enough to cause you to smack your forehead as you realize some place where you went wrong. Or, it may be that you have to “keep score” of the various crashes, their locations, and their devices, so you can determine a pattern (e.g., when users do X on Y device, things go wrong, but otherwise doing X seems to be OK).
If you come up with a device-specific pattern, you will need to do more testing involving that device. That could be finding some fans of yours who have access to that device and can run some test code on your behalf. That could be using a service like DeviceAnywhere, so you can test that device yourself. It could be that you need the help of a consultancy like Duarlander. Or, you might be able to pick up a device on eBay or something, so you can test it in person.
If you narrow down the cause, and the cause is where a device clearly violates the documented Android APIs, try to contact that device manufacturer’s developer support group. Some manufacturers have a rich support environment, others less so. Give them the full details, including a sample project that demonstrates the problem, where possible. That may help them resolve the problem for future builds, while you determine ways to deal with the problem in the here and now, like blocking certain functionality for certain devices. You can use the android.os.Build class to determine what device your code is running on.
Of course, if what you find is clearly a bug in Android itself, post an issue, with sample code demonstrating the problem.
Perhaps you will be lucky, and your code will work perfectly from the outset. After all, when you wrote it, I am sure you intended it to work. If it fails, though, do not panic â€” gather and analyze data, then cast blame where blame lies.
You might also like
U.S. Cellular has added the Samsung Galaxy Axiom to its portfolio of Android smartphones. Powered by Android 4.0 Ice Cream Sandwich, the handset features a 4.0-inch WVGA display, a 1.2GHz
When tablets were introduced, experts predicted that soon tablet will replace laptop, but still today laptop/notebook is highly demanded, because it is the best form of personal computer there is.
The Verizon Wireless version of the LG G3 finally is receiving an update to Android Lollipop, according to a press release on its site. In an attached PDF, Verizon has