Not every system-level issue can be caught with app-side logging. Consider this one as an example:
http://code.google.com/p/android/issues/detail?id=42107 This one is not a freeze or a device reboot, but still -- -- there is no unhandled exception in the application (which could be trapped and logged), only some stuff in the system log, which, as we all know, is more difficult to access in 4.2. It won't show in the developer console's bug reports either. The process just quits. And then, a device freeze or a reboot can leave file-based logs without most recent data, because disk write ops won't be committed, and memory based logs obviously won't persist after a reboot. All in all, dealing with OS level bugs (and I consider every device freeze or reboot an OS level bug, no matter what the app is doing) is really hard... -- K 2013/1/8 Kristopher Micinski <krismicin...@gmail.com>: > True, I usually use a utility logging class that is a drop in > replacement for android's `Log`. You can get proguard to compile > these away appropriately easily (for empty methods used in a > production build), and in this case I can simply dump the log to an SD > card type location. I've done this before when I encountered a > problem with the logger's functionality for large data. > > Kris > > On Mon, Jan 7, 2013 at 4:52 PM, jason_gates <jason.gates...@gmail.com> wrote: >> Hi, >> >> No problem :) >> >> >> 1) Collection of an event log. I'm quoting the original post: >> >> >> "I have very little to go on in these reports. After a full reboot, there is >> little chance the logcat still has useful information. Since 4.1, we can't >> use any external programs to collect the log. I aim for prevention >> instead.". >> >> >> Thus, persist your own log. Your own application can write out a simple text >> file and later (after the reboot) read it. >> >> >> 2) If the issue is related to a vendor's key map, wouldn't that key map >> effect all applications on the device? Not just the poster's application? >> >> >> To summarize, the original post describes a the challenge of identifying an >> issue. Where does it state the issue known to occur when key combinations >> are invoked? Wouldn't that just a be an issue of reporting a bug to a >> vendor? >> >> >> Hope that helps :) >> >> Good Luck >> >> Jason >> >> >> >> On Monday, January 7, 2013 3:19:30 PM UTC-6, Kristopher Micinski wrote: >>> >>> I'm unclear: why is writing your own event logger supposed to help here? >>> >>> Unfortunately I'm afraid whenever this kind of thing happens it's >>> because you pushed some device or rom specific buttons (in the >>> metaphorical sense), making it hard to diagnose. >>> >>> Kris >>> >>> On Mon, Jan 7, 2013 at 4:14 PM, jason_gates <jason.g...@gmail.com> wrote: >>> > Hi, >>> > I have 2 suggestions :) >>> > >>> > First, I would review my code and make sure I've implemented >>> > try/catch/finally. You get inconsistent results if your application is >>> > not >>> > handling exceptions :) E.G. an attempt to use a value. Explicitly >>> > validate >>> > the value is not null. Place the block within a try/catch (and finally >>> > if >>> > apropos). >>> > >>> > Next, I would consider implementing my own event log. Is there some >>> > reason >>> > why you are restricted to "Logcat"? Wouldn't writing out your own event >>> > log >>> > help you diagnose your issue? >>> > >>> > Hope that helps :) >>> > Good Luck >>> > Jason >>> > >>> > >>> > >>> > >>> > >>> > On Monday, January 7, 2013 12:52:59 PM UTC-6, Nathan wrote: >>> >> >>> >> Well, lo and behold, I have a Galaxy Nexus right next to me that is >>> >> completely frozen this very minute. >>> >> >>> >> I thought reproducing a hard freeze on a device available to me would >>> >> be a >>> >> huge breakthrough. But no, nothing. The debugger detached without >>> >> telling me >>> >> anything. The logcat gives out with no useful clues. The device is just >>> >> here >>> >> frozen until I pull out the battery after which all evidence will be >>> >> destroyed. >>> >> >>> >> No Force Close dialog came up at anytime. No evidence in the log that >>> >> one >>> >> was trying. >>> >> >>> >> Now this device has done some weird things lately. Like saying it is >>> >> charging when not connected to anything. And the battery got hot and >>> >> ran out >>> >> too quickly for no apparent reason. >>> >> >>> >> Nathan >>> > >>> > -- >>> > You received this message because you are subscribed to the Google >>> > Groups "Android Developers" group. >>> > To post to this group, send email to android-d...@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 > > -- > 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
