BuildingDroidsSo, 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.

Note: Select outbound links may include affiliate tracking codes and AndroidGuys may receive compensation for purchases. Read our policy. As an Amazon Associate we earn from qualifying purchases.


  1. One comment I would add: take heart that, as you fix issues, you can immediately roll out the fixes to your users via the Android Market. No waiting 12 weeks for an intermediary to review your application, while users trash your application for bugs you may have released!

  2. Thanks Mark, great and useful info as usual! I tried Flurry and it detected NullPointerException and … gave me not a shred of a stack trace. What tool is least intrusive and gives a better info? Any "gut feeling", experience, opinion? The idea is great – I was thinking actually about implementing something similar myself but it's great that there are already built solutions

    • I used Flurry on one consulting engagement, at the customer's request, and they were happy with it. I have not had an opportunity to try the others as yet. Sorry I don't have more concrete experience to share.

Comments are closed.