I use a combination of my own default uncaught exception handler and flurry's.
When an uncaught exception occurs, I grab all the device, firmware and app version etc info and relevant lines from the stacktrace and put them in a Map (max 10 entries, but you can just fire off multiple events) which is then reported as an event using Flurry. Then I trigger Flurry's default uncaught exception handing. The problem with Flurry's default mechanism is it doesn't link the exception to the "user paths" so you are limited to the stacktrace to know the context of the exception (not always enough). Also, the amount of information it includes when reporting an uncaught exception, is fairly limited. Using this technique I have received valuable instant feedback of bugs in my code. Sometimes device specific, but usually gaps in my testing! A couple of times I've been able to release quick (emergency) bug fixes before 95%+ of my users had a chance to update the buggy version. I think I wouldn't have known about most (if not all) of these bugs had it not been for the analytics. I've not received a single bug report from users yet even though I know full well they've experienced several! -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
