Startup-related Podcast Episodes - Personal Recommendations

Sasha Strauss interview on Mixergy, archived.
Avinash Kaushik interview on Mixergy, archived.
Peter Voogd interview on Mixergy, archived.

Error reporting in Android applications

Why reporting?
Android application developers are well aware that their target devices are taking over the world. A vast number of them is already out there, and many more are yet to come. For an incomplete ever-growing list check out the Wikipedia article here: Comparison of Android devices. It’s starting to look like a flood and we have to be ready.

So many OS versions, so many display resolutions, different available sensors, different locales and language settings, different … it is obvious that you will not be able to test your application on all those variations, even if you wanted to do so. However, error conditions will happen and your bugs will slip through after the application is published …

Embrace the inevitable, in these cases your users will often be the first who’ll get hit. So let’s make things less painful for all of us.

When sh*t (i.e. error condition) happens we should do the following - show a polite error message to user, obtain a full stack trace for ourselves. Regarding the polite error message - avoid any kind of technical jibberish, these devices are complex enough for all non-geeks already. You do not need to make things even more confusing. And regarding the full stack trace - welcome to the craft of silent error logging.

What the logging should look like?
Here is the list of nice-to-have features:

• Log data is sent real-time back to us

When application crashes / reaches unwanted state, we want to know it immediately. Fix might be trivial, we might publish the new app version right away and leave better impression on users.

• If Internet connection is not available, log data is cashed and sent when possible
• Application user can turn logging off

In fact, logging should be invisible to users. However, if for some reason user wants to turn the logging of, he should be able to do so.

• Logging is turned off while application is in debug mode 

There is no point in collecting data while logs are displayed on our screen right away.

• Application crashes and freezes are reported as well

Not all your users have Android 2.2+ devices that have crash & freeze reporting and not all your users have downloaded application from Android Market.

• Easy to integrate
• Preferably Open Source Software

What should be reported?
Here is the list of mandatory things:

• Caught exception or custom message
• OS version
• Device type
• Package name
• Application version
• ...

How it should be reported?
Here are the possibilities:

• Via HTTP to your server
• Via HTTP to Google Docs
• Via email

What are the error reporting libraries available out there?
First, my recommendation - ACRA (Application Crash Report for Android). You should check the URL, it really has more or less all of the mentioned features and it is really easy to integrate / use.

Other available libraries are:

• Flurry
• android-remote-stacktrace (not updated since Dec 10, 2009)
• android-log-collector (not updated since Nov 14, 2009)
• microlog4android (not updated since Sep 12, 2010)

Also, some blog posts that you might be interested in:

• http://jyro.blogspot.com/2009/09/crash-report-for-android-app.html
• http://androidblogger.blogspot.com/2009/12/how-to-improve-your-application-crash.html
• http://androidblogger.blogspot.com/2010/03/crash-reporter-for-android-slight.html

And relevant Q&A on Stack Overflow:

• http://stackoverflow.com/questions/601503/how-do-i-obtain-crash-data-from-my-android-application

Happy coding!