The problem is the upgrade process seems like it has some race conditions in it. Mostly things around resources being non-existent, even though they are definitely there in the drawable directory. Even more disconcerting is a stack trace that is in the old code, but is very definitely running a few pieces of new code at the same time.
An example. I had a crash while accessing resources(that are definitely present) in a service. It was on a blank line in the new codebase, and matched up in the old. The crash was reported via ACRA, which sources its destination from the app's application class. In this particular upgrade, I changed the destination in the application class due to an acra upgrade.. So the old crash should have gone to the old destination, while new version crashes should goto the new place. However, I received a old version crash report at the new destination. It's not just ACRA through, I've received user reported crashes via the market with the same stacktraces with almost all the comments mentioning that it crashed right after they upgraded. On Sun, May 1, 2011 at 5:29 PM, Dianne Hackborn <hack...@android.com> wrote: > Allowing applications to include any information is a really tricky subject. > Even the stack crawls can been a concern -- for example there was an issues > raised in the past about a health care about that could throw an exception > that would have some user information in the exception message. > > People often don't realize just how complicated a lot of this stuff is > outside of just writing some code and releasing it. > On Sun, May 1, 2011 at 5:45 PM, TreKing <treking...@gmail.com> wrote: >> >> On Sun, May 1, 2011 at 4:14 PM, Dianne Hackborn <hack...@android.com> >> wrote: >>> >>> Just to be aware -- the logging information is pretty sensitive. >> >> Agreed. I should clarify - the logging information I collect is >> specifically for my own app, not the system log. In release mode I write to >> my own, internal log file and submit that if there is a crash. If I get a >> crash report and can't figure it out from the exception, I throw in some >> logging with the next update and am able to better investigate the problem >> next time it happens. After the issue is fixed, I just take out the logging >> for the next update. >> I do give the user the *option* to include the system log, though in >> retrospect I've never actually needed the extra information to fix any >> problems. >> >>> >>> We've found it hard enough to keep the platform and its apps clean about >>> logging personal information (pretty much every release has had last-minute >>> fixes for personal information being logged), and when you add in >>> manufacturers and third party apps, it is just impossible. For example there >>> was the manufacturer who released devices whose soft keyboard logged each >>> key pressed, and it is just scary what one sees various third party apps. >> >> Agreed again. I've "debugged" some apps by viewing the LogCat while I run >> them and it's fairly absurd what some apps leave in release mode. >> >>> >>> There has also been significant pressure to do something stronger, such >>> as not allow third party apps access to the logs at all or only to the data >>> they have written to the log. I don't know if that will actually happen, >>> but it is enough of a concern to be a possibility. >> >> That would be fantastic. If the system could direct each app's logs to >> it's own location and include only that to the developer in the Market >> console, it would be infinitely more useful. >> >>> >>> This is also why Android Feedback does not currently make the logs >>> available, because of the kinds of personal information likely to be in >>> them. >> >> Understood - but it does make them fairly unusable for all but the most >> obvious of crashes. This is why I opted for my own solution. I would never >> have identified and fixed the number of issues I have already by solely >> relying on the Market crash reports. (It also doesn't help that very few >> people actually report the issues and the ones that do provide little to no >> explanation). >> >> >> ------------------------------------------------------------------------------------------------- >> TreKing - Chicago transit tracking app for Android-powered devices >> >> -- >> 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 > > > -- > Dianne Hackborn > Android framework engineer > hack...@android.com > > Note: please don't send private questions to me, as I don't have time to > provide private support, and so won't reply to such e-mails. All such > questions should be posted on public forums, where I and others can see and > answer them. > > -- > 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 -- 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
