> Even the big players are just catching onto this (as witnessed by the fact that there's no facility for this built into the phone).
It is built into later Android versions. The normal force close dialog has an extra button called "Report". That leads to a screen where extra information can be added which has buttons "Preview" and "Send", although the user can just hit back from there as well. There's also a long scrolling dialog full of legalese with "Accept" and "Decline" buttons that showed up the first time I went through this, but that might have been because the app that crashed was the Market app itself. That dialog didn't show up in subsequent crashes I observed, although those were for non-Google apps, although still distributed by the Market. So either it remembers your choice for the legalese step, or that only shows up for Google apps. Anyway, for normal developers, the information ends up on the Market developer console. There's a link called "Errors" you can click on next to each published app to see reported errors. Flurry, the free app metrics service, also has an uncaught exception handler that it sets, unless you specifically call the FlurryAgent.setCaptureUncaughtExceptions function to disable it. These errors are reported in the Flurry analytics for the app. So error reporting of this sort isn't rare at all. The official reporting does have flaws, however. It isn't available on older versions of Android. I assume it isn't active for non-Google, non-Market distributed apps. Also, hardly any users actually use it. I suspect it's just too much work for a user to go through this multiple opt-in every time. I think an opt-out for sending stack traces on upgrading or activating a phone with a version of Android that supports it would have been much more helpful to users and devs alike. Having hardly any errors reported just leads to lower quality apps for everyone, and stack traces are far more useful than 1 star, short cryptic comments on the Market details page. A compromise could have been opt-in/opt-out on app install, or on first install of an app by each developer, or explicit opt-out of stack trace sending on crash at least, processed separately from the form. The form has a manual input section that probably makes lots of users blow reporting off, because it looks like work. They could have still kept the per-crash opt-in for sending additional information with any of those solutions to protect private information, and still gotten devs more stack traces to work with. I guess the biggest danger I've heard people mention is apps sending private data in the message property of exceptions, which is included in stack traces. This might be possible even for an app without the internet permission, which users might trust more because they think it can't send data. On Sep 18, 2:00 pm, DanH <[email protected]> wrote: > First off, you are to be commended for putting this much effort into > diagnostics. Even the big players are just catching onto this (as > witnessed by the fact that there's no facility for this built into the > phone). "Real time" diagnostics are much friendlier for the user than > saying "Please reproduce with logging turned on" or whatever, and > generally the information you obtain is more comprehensive and helpful > (since you're more apt to see several instances of essentially the > same bug, but with slightly different symptoms). > > There is a slight danger that the paranoid among users will believe > that you're secretly collecting data on them. It's probably better to > somehow obtain their permission to send the failure report to you, vs > doing it silently and unconditionally. Asking them at the same time > if they want to provide an email address is good, though. > > In terms of options, I'd say "KISS" -- keep it simple. Unless the > facility is going to be picked up by a "trusted authority" (say, > Google), just have email address be reported back to the developer. > Promise, of course, that the email address will be kept private (and > make any users of your facilities aware that they're making this > promise) but don't bother with the complex forwarding service -- users > are no more apt to trust it than they are to trust the individual > developers, and in fact they're probably more likely to be confused by > the options and not agree at all. > > On Sep 18, 12:19 pm, Brad Gies <[email protected]> wrote: > > > This is a bit long winded (sorry, but I need to explain what I'm doing > > before I can ask the question). > > > Just wondering if I could get a few (hopefully few hundred) opinions on > > this : > > > I developed an Exception Handler for my first Android app (released the > > first month the market opened), which logs all uncaught exceptions to my > > server, and since then I have gradually refined it and improved. I'm now > > using it in my 4th public Android app and a few private apps, and I find > > it extremely helpful to find bugs that don't happen to me when I'm testing. > > > One thing I added that is proving to be extremely useful is an > > AlertDialog when the exception occurs asking the user if it is OK to > > contact him/her if I need more information to be able to fix the > > problem, and a box for them to enter their email address if they agree. > > I don't have good numbers for you on the acceptance rate because most of > > my public apps already have the users email address and for the private > > apps the company enforces their compliance (or supplies the emails for > > me to use). BUT... it looks like about 20% of users do enter their email > > address if asked, and that is more than enough to be very useful. > > > I think I can increase the percentage of users that do supply their > > emails addresses, and that is what my question is about :). (I will ask > > it soon) > > > First, It has occurred to me that my Exception Logger might be even more > > successful for me if other developers were also using it because users > > might have seen it before and trust it when they first see it in my > > apps. That obviously would only happen if quite a few developers were > > using it. > > > Anyway... sorry it's already getting long, and I AM trying to keep it > > from becoming a book. I have repackaged my Exception Logger and will > > release it in the next couple of days for other developers to use (the > > price is the good one - FREE). I will host the thing on my server (FYI > > it's a Cloud based server so we can increase capacity if needed) and any > > developers using it will be able to log in and view the exceptions their > > app has generated, and sort by time/date, user, and other fields. > > > NOW.. the question: I think the Exception Logger would be more > > successful getting the users to agree to be contacted IF their email > > addresses were kept confidential. Actually, I don't think there is much > > doubt that would be the case. BUT, there is a tradeoff. Obviously, most > > developers would prefer to see the email addresses so they can manage > > the contacts a bit more effectively without using my website to do it, > > BUT if the email addresses are not confidential, fewer users will give > > them. > > > So here are what I think are the options: > > > a) keep the email addresses confidential, but developers can send the > > user an email using my website, include both a reply address which goes > > to my website and then forwards the email to the developer, and also the > > developers email address so the user could respond directly to the > > developer if they choose. I'm sure this would have by far the highest > > success rate for getting contact info .... but means devs have to use my > > website to send the first email at least. > > > b) give the user a choice of keeping the email address confidential > > or just giving it to the developer. This should also have a fairly high > > acceptance rate by the user, but complicates the process for them > > because they would actually have to read the instructions to figure out > > how it works, and quite possibly a few users would think they asked for > > their email addresses to be confidential, when they actually checked the > > other option, and would be upset if they found out later. It's also a > > bit more work for me, for maybe very little benefit. > > > c) Don't bother keeping the email addresses confidential. All my own > > apps work this way, and it is useful, but I'm sure either of the other > > two options would have a better success rate of obtaining the email > > addresses, and therefore would be better for most devs to get > > information about problems in their apps. > > > I don't try the a) or b) options for myself because obviously I could > > see the email addresses in my log files if I wanted to look, and it > > would be a little deceitful to tell the user their email would be > > confidential in that case, even if I did use them properly ... BUT, I > > can do that for other developers without stretching the truth at all, so > > I think it's worth the effort if other devs want to use it. > > > So, please let me know what your opinions are. > > > I'm also hoping to get some idea of how many developers might want to > > use this. I've already done almost all the work, so it will be released > > even if nobody wants to use it. It freaks me out a little to open up my > > server to an unknown amount of use, but I am well setup to increase > > server capacity quickly if needed, and I don't think the cost of doing > > this will be too horrible (I hope). ... > > > Sincerely, > > > Brad Gies > > ----------------------------------------------------------------------- > > Bistro Bot - Bistro > > Blurbhttp://bgies.comhttp://bistroblurb.comhttp://ihottonight.comhttp://fo... > > ----------------------------------------------------------------------- > > > Everything in moderation, including abstinence > > > Never doubt that a small group of thoughtful, committed people can > > change the world. Indeed. It is the only thing that ever has - Margaret Mead -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
