[android-developers] Re: Android, send me logs! - code library for detecting force-close and sending logs
The source and binaries of the prototype have been posted on Github for any interested. Comments are welcome. http://heroicefforts.github.com/Viable/intro.html On Mar 3, 2:29 am, laphroaig15 laphroai...@gmail.com wrote: Dupes were a concern for me as well; not only on the receiving side, but also for bugging the heck out of users who might encounter the crash regularly. The approach I've implemented so far is to store a digest with the issue. If the issue has already been reported by another user, then the app prompts to ask if the user would like to add a comment to the existing issue. An individual user is only prompted once per reported issue. On Mar 2, 11:25 pm, focuser linto...@gmail.com wrote: Hi guys, Thanks for your informative comments and discussion. In Android, send me logs!, I am just taking the simplest possible approach - sending logs by email looks like the simplest and most reliable way and best understood by users. Of course, the anonymity of users might be an issue. But it can be resolved by sending a POST request to a given URL. That requires some extra coding in the host client, for example to render a UI for users to review the content being submitted, UI and error handling code for submitting the POST request etc. I'm planning to build this into the next release if you guys don't mind. :) Compared to the defaultUncaughtExceptionHandler approach, analyzing logs has some advantages: - it's capable of capturing extra errors such as another infamous WNR (Window not responding) error, and even VM crashes due to Android bugs - it looks like a simpler approach to me: it doesn't interfere with existing code, whereas using defaultUncaughtExceptionHandler you would need to carefully relay to the default handler of the system, and like Streets of Boston said, you probably need to deal with extra stuff such as services; Of course, since the logs are not part of Android's official API, the result might be unreliable if not implemented correctly. But by analyzing existing platforms and applying some heuristics, I believe the result would be good enough for the majority of applications. BTW: What laphroaig15 mentioned about connecting the submitted logs to bug tracking systems sounds like a good idea. Maybe there could be a system on the server to remove/group duplicated bug reports/ submitted logs? Keep looking forward to more of your feedback. Linton -- 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
[android-developers] Re: Android, send me logs! - code library for detecting force-close and sending logs
Hi guys, Thanks for your informative comments and discussion. In Android, send me logs!, I am just taking the simplest possible approach - sending logs by email looks like the simplest and most reliable way and best understood by users. Of course, the anonymity of users might be an issue. But it can be resolved by sending a POST request to a given URL. That requires some extra coding in the host client, for example to render a UI for users to review the content being submitted, UI and error handling code for submitting the POST request etc. I'm planning to build this into the next release if you guys don't mind. :) Compared to the defaultUncaughtExceptionHandler approach, analyzing logs has some advantages: - it's capable of capturing extra errors such as another infamous WNR (Window not responding) error, and even VM crashes due to Android bugs - it looks like a simpler approach to me: it doesn't interfere with existing code, whereas using defaultUncaughtExceptionHandler you would need to carefully relay to the default handler of the system, and like Streets of Boston said, you probably need to deal with extra stuff such as services; Of course, since the logs are not part of Android's official API, the result might be unreliable if not implemented correctly. But by analyzing existing platforms and applying some heuristics, I believe the result would be good enough for the majority of applications. BTW: What laphroaig15 mentioned about connecting the submitted logs to bug tracking systems sounds like a good idea. Maybe there could be a system on the server to remove/group duplicated bug reports/ submitted logs? Keep looking forward to more of your feedback. Linton -- 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
[android-developers] Re: Android, send me logs! - code library for detecting force-close and sending logs
Dupes were a concern for me as well; not only on the receiving side, but also for bugging the heck out of users who might encounter the crash regularly. The approach I've implemented so far is to store a digest with the issue. If the issue has already been reported by another user, then the app prompts to ask if the user would like to add a comment to the existing issue. An individual user is only prompted once per reported issue. On Mar 2, 11:25 pm, focuser linto...@gmail.com wrote: Hi guys, Thanks for your informative comments and discussion. In Android, send me logs!, I am just taking the simplest possible approach - sending logs by email looks like the simplest and most reliable way and best understood by users. Of course, the anonymity of users might be an issue. But it can be resolved by sending a POST request to a given URL. That requires some extra coding in the host client, for example to render a UI for users to review the content being submitted, UI and error handling code for submitting the POST request etc. I'm planning to build this into the next release if you guys don't mind. :) Compared to the defaultUncaughtExceptionHandler approach, analyzing logs has some advantages: - it's capable of capturing extra errors such as another infamous WNR (Window not responding) error, and even VM crashes due to Android bugs - it looks like a simpler approach to me: it doesn't interfere with existing code, whereas using defaultUncaughtExceptionHandler you would need to carefully relay to the default handler of the system, and like Streets of Boston said, you probably need to deal with extra stuff such as services; Of course, since the logs are not part of Android's official API, the result might be unreliable if not implemented correctly. But by analyzing existing platforms and applying some heuristics, I believe the result would be good enough for the majority of applications. BTW: What laphroaig15 mentioned about connecting the submitted logs to bug tracking systems sounds like a good idea. Maybe there could be a system on the server to remove/group duplicated bug reports/ submitted logs? Keep looking forward to more of your feedback. Linton -- 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
Re: [android-developers] Re: Android, send me logs! - code library for detecting force-close and sending logs
What's nice about Apple's approach here is that developers don't have to do anything... it's a good way of improving the code quality for *all* apps. I was pretty surprised and happy when it came online a month or two ago because it confirmed that what was crashing across our user base were known issues. Most of the battle is getting *any* information about how the app is behaving in the field, so the auto-crash reports are really nice. I don't think there's an inherent conflict with Android's openness. The crashes are anonymized, and developers and users do chose to go through the Android Market -- which unlike Apple isn't the only way to get apps. And it would give feedback to the Android developers what kinds of bugs appear, because their users (the devs) don't seem to grasp the API or because there are bugs in the system that they would have consider minor until they see how often they really occur. -- 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
Re: [android-developers] Re: Android, send me logs! - code library for detecting force-close and sending logs
There's multiple third party libraries that already have this functionality. Mike On 02/25/2010 07:38 PM, mssmison wrote: I love this idea! I'd like to build it into the source itself, that would be a life saver.. lol -- 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
[android-developers] Re: Android, send me logs! - code library for detecting force-close and sending logs
I've been working on a 3rd party application that uses meta-data and exception handling as suggested above to allow users to submit this data to a developer's issue tracker and to browse said tracker. I plan to put it up on github next weekend. It's more of a prototype at the moment, but I'm hoping to get some feedback or contributions from some of the more experienced Android devs on the list. Cheers, Jess On Feb 25, 7:54 pm, Mike Novak michael.nova...@gmail.com wrote: There's multiple third party libraries that already have this functionality. Mike On 02/25/2010 07:38 PM, mssmison wrote: I love this idea! I'd like to build it into the source itself, that would be a life saver.. lol -- 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
[android-developers] Re: Android, send me logs! - code library for detecting force-close and sending logs
Inserting a try {} catch {xxxException ...} in the code an be hard...
if the crash occurs in a place we don't expect/suspect of not being
stable.
A solution for Google team, would be in the Manifest.xml to add
field :
sendErrorLogsTo=m...@me.com
So, for each Force Close we could receive a mail from Google (not
from the user).
At least we could track the number of crash, check if they decrease
over time, etc...
--
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
[android-developers] Re: Android, send me logs! - code library for detecting force-close and sending logs
I haven't made it public yet (i will at some point), but i have a similar system for my apps. The process of my activities registers itself by calling Thread.setDefaultUncaughtExceptionHandler(uncaughtXcptHandler) and binds to service that i wrote that runs in a different process (since my app will be dying because of an exception, it's tricky to properly handle the exception in the dying process itself). Then in the uncaughtXcptHandler.void uncaughtException(Thread t, Throwable e), I write out an error-log file with the stack-trace and some other info. Then i call an asynchronous method on my service that will pop up a dialog allowing the user to send me the error report or not. If the user clicks 'Yes', then the error-log file is read and sent to my webserver. My webserver then sends me an e-mail. This way, users can remain anonymous (no e-mail/reply address necessary). I let my app die immediately after calling the asynchronous method. If my app couldn't bind to the service for any reason, the old and trusted force-close message from Android is shown instead. On Feb 25, 3:10 pm, focuser linto...@gmail.com wrote: Hi fellow Android developers, How many times have you asked users to send you the logcat result to track down a nasty force-close? How many users have actually replied? It's not that users are lazy or busy. Having to run the logcat command or download an external log collector app just means too much trouble for them. It should be much simpler. It should be just one tap. In fact I'm surprised (or being ignorant) that an easier error reporting mechanism has not existed yet in the Android API, especially for the infamous force-close. That is why I coded and open-sourced Android, send me logs!, a small code library that makes it easy to detect force-close and send logs from within your own apps. You can program it to report errors with just one tap, and also include your own tracing information. Please check it out athttp://code.google.com/p/android-send-me-logs/. It's still in very early stage, and I would appreciate your critism, suggestions, comments, or even code contributions. Linton Ye -- 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
Re: [android-developers] Re: Android, send me logs! - code library for detecting force-close and sending logs
On 02/25/2010 11:57 PM, focuser wrote: Mike - I think Apple's approach may be good for Apple, and probably not that compatible with the openness of Android? Also, what's better of Apple's approach other than that users don't have to give their identity (email addresses etc) to individual developers? If you suggest it here, we could definitely consider to add it to the library if appropriate. What's nice about Apple's approach here is that developers don't have to do anything... it's a good way of improving the code quality for *all* apps. I was pretty surprised and happy when it came online a month or two ago because it confirmed that what was crashing across our user base were known issues. Most of the battle is getting *any* information about how the app is behaving in the field, so the auto-crash reports are really nice. I don't think there's an inherent conflict with Android's openness. The crashes are anonymized, and developers and users do chose to go through the Android Market -- which unlike Apple isn't the only way to get apps. I should say that I don't think of this as an either/or with what you're doing though. Apple's just pulling up crash dumps, whereas what you're doing is allowing big chunks of the log to be sent back. There's room for both of these to exist at the same time. Mike mssmison - thanks for your interest and compliment. Please let me know if you have any issues with the code. On Feb 25, 4:38 pm, mssmisoncpoul...@gmail.com wrote: I love this idea! I'd like to build it into the source itself, that would be a life saver.. lol -- 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
[android-developers] Re: Android, send me logs! - code library for detecting force-close and sending logs
For those of you that are comfortable using Flurry, a similar approach
works nicely. Flurry already collects uncaught exceptions, but for
some reason doesn't actually log the stack trace. To get around this,
I add an exceptionHandler that logs a Flurry event with the stack
trace as a parameter, like this:
OutputStream lOS = new ByteArrayOutputStream();
PrintStream lPS = new PrintStream(lOS, true);
t.printStackTrace(lPS);
lPS.flush();
MapString, String lArgs = new HashMapString, String();
lArgs.put(stackTrace, lOS.toString());
SharedPreferences lPrefs =
PreferenceManager.getDefaultSharedPreferences(pCtxt);
if(lPrefs.getBoolean(PREFS_REMOTE_DEBUG, true)){
FlurryAgent.onEvent(FLURRY_EVENT_UNCAUGHT_EXCEPTION,
lArgs);
}
One big advantage of this approach is that Flurry collects lots of
metrics w.r.t. the frequency, timing, and sequencing of the events.
Works very, very nicely.
On Feb 26, 10:10 am, Streets Of Boston flyingdutc...@gmail.com
wrote:
I haven't made it public yet (i will at some point), but i have a
similar system for my apps.
The process of my activities registers itself by calling
Thread.setDefaultUncaughtExceptionHandler(uncaughtXcptHandler) and
binds to service that i wrote that runs in a different process (since
my app will be dying because of an exception, it's tricky to properly
handle the exception in the dying process itself).
Then in the uncaughtXcptHandler.void uncaughtException(Thread t,
Throwable e), I write out an error-log file with the stack-trace and
some other info. Then i call an asynchronous method on my service that
will pop up a dialog allowing the user to send me the error report or
not. If the user clicks 'Yes', then the error-log file is read and
sent to my webserver. My webserver then sends me an e-mail. This way,
users can remain anonymous (no e-mail/reply address necessary).
I let my app die immediately after calling the asynchronous method. If
my app couldn't bind to the service for any reason, the old and
trusted force-close message from Android is shown instead.
On Feb 25, 3:10 pm, focuser linto...@gmail.com wrote:
Hi fellow Android developers,
How many times have you asked users to send you the logcat result to
track down a nasty force-close? How many users have actually replied?
It's not that users are lazy or busy. Having to run the logcat
command or download an external log collector app just means too much
trouble for them. It should be much simpler. It should be just one
tap.
In fact I'm surprised (or being ignorant) that an easier error
reporting mechanism has not existed yet in the Android API, especially
for the infamous force-close. That is why I coded and open-sourced
Android, send me logs!, a small code library that makes it easy to
detect force-close and send logs from within your own apps. You can
program it to report errors with just one tap, and also include your
own tracing information.
Please check it out athttp://code.google.com/p/android-send-me-logs/.
It's still in very early stage, and I would appreciate your critism,
suggestions, comments, or even code contributions.
Linton Ye
--
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
Re: [android-developers] Re: Android, send me logs! - code library for detecting force-close and sending logs
Just pointing out an alternative as well (I've used it in a few apps):
http://code.google.com/p/android-remote-stacktrace/
- Dan
On Fri, Feb 26, 2010 at 11:58 AM, dadical keyes...@gmail.com wrote:
For those of you that are comfortable using Flurry, a similar approach
works nicely. Flurry already collects uncaught exceptions, but for
some reason doesn't actually log the stack trace. To get around this,
I add an exceptionHandler that logs a Flurry event with the stack
trace as a parameter, like this:
OutputStream lOS = new ByteArrayOutputStream();
PrintStream lPS = new PrintStream(lOS, true);
t.printStackTrace(lPS);
lPS.flush();
MapString, String lArgs = new HashMapString, String();
lArgs.put(stackTrace, lOS.toString());
SharedPreferences lPrefs =
PreferenceManager.getDefaultSharedPreferences(pCtxt);
if(lPrefs.getBoolean(PREFS_REMOTE_DEBUG, true)){
FlurryAgent.onEvent(FLURRY_EVENT_UNCAUGHT_EXCEPTION,
lArgs);
}
One big advantage of this approach is that Flurry collects lots of
metrics w.r.t. the frequency, timing, and sequencing of the events.
Works very, very nicely.
On Feb 26, 10:10 am, Streets Of Boston flyingdutc...@gmail.com
wrote:
I haven't made it public yet (i will at some point), but i have a
similar system for my apps.
The process of my activities registers itself by calling
Thread.setDefaultUncaughtExceptionHandler(uncaughtXcptHandler) and
binds to service that i wrote that runs in a different process (since
my app will be dying because of an exception, it's tricky to properly
handle the exception in the dying process itself).
Then in the uncaughtXcptHandler.void uncaughtException(Thread t,
Throwable e), I write out an error-log file with the stack-trace and
some other info. Then i call an asynchronous method on my service that
will pop up a dialog allowing the user to send me the error report or
not. If the user clicks 'Yes', then the error-log file is read and
sent to my webserver. My webserver then sends me an e-mail. This way,
users can remain anonymous (no e-mail/reply address necessary).
I let my app die immediately after calling the asynchronous method. If
my app couldn't bind to the service for any reason, the old and
trusted force-close message from Android is shown instead.
On Feb 25, 3:10 pm, focuser linto...@gmail.com wrote:
Hi fellow Android developers,
How many times have you asked users to send you the logcat result to
track down a nasty force-close? How many users have actually replied?
It's not that users are lazy or busy. Having to run the logcat
command or download an external log collector app just means too much
trouble for them. It should be much simpler. It should be just one
tap.
In fact I'm surprised (or being ignorant) that an easier error
reporting mechanism has not existed yet in the Android API, especially
for the infamous force-close. That is why I coded and open-sourced
Android, send me logs!, a small code library that makes it easy to
detect force-close and send logs from within your own apps. You can
program it to report errors with just one tap, and also include your
own tracing information.
Please check it out athttp://code.google.com/p/android-send-me-logs/.
It's still in very early stage, and I would appreciate your critism,
suggestions, comments, or even code contributions.
Linton Ye
--
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.comandroid-developers%2bunsubscr...@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
[android-developers] Re: Android, send me logs! - code library for detecting force-close and sending logs
I take it a step further, and send one event for each exception cause
(up to three).
I also process the stacktrace to make it more compact (taking out
filenames, removing package prefixes that I expect, etc.) so that more
trace fits within Flurry's limits.
I find it useful already, even though my app's not on the market yet.
Flurry's tools aren't quite ideal for this. You'd like to
automatically cluster errors, and present each one with a count, with
a graph and history available, and links to individual event traces.
I've done similar stuff in the past for server applications. It
really, really pays off.
On Feb 26, 8:58 am, dadical keyes...@gmail.com wrote:
For those of you that are comfortable using Flurry, a similar approach
works nicely. Flurry already collects uncaught exceptions, but for
some reason doesn't actually log the stack trace. To get around this,
I add an exceptionHandler that logs a Flurry event with the stack
trace as a parameter, like this:
OutputStream lOS = new ByteArrayOutputStream();
PrintStream lPS = new PrintStream(lOS, true);
t.printStackTrace(lPS);
lPS.flush();
MapString, String lArgs = new HashMapString, String();
lArgs.put(stackTrace, lOS.toString());
SharedPreferences lPrefs =
PreferenceManager.getDefaultSharedPreferences(pCtxt);
if(lPrefs.getBoolean(PREFS_REMOTE_DEBUG, true)){
FlurryAgent.onEvent(FLURRY_EVENT_UNCAUGHT_EXCEPTION,
lArgs);
}
One big advantage of this approach is that Flurry collects lots of
metrics w.r.t. the frequency, timing, and sequencing of the events.
Works very, very nicely.
On Feb 26, 10:10 am, Streets Of Boston flyingdutc...@gmail.com
wrote:
I haven't made it public yet (i will at some point), but i have a
similar system for my apps.
The process of my activities registers itself by calling
Thread.setDefaultUncaughtExceptionHandler(uncaughtXcptHandler) and
binds to service that i wrote that runs in a different process (since
my app will be dying because of an exception, it's tricky to properly
handle the exception in the dying process itself).
Then in the uncaughtXcptHandler.void uncaughtException(Thread t,
Throwable e), I write out an error-log file with the stack-trace and
some other info. Then i call an asynchronous method on my service that
will pop up a dialog allowing the user to send me the error report or
not. If the user clicks 'Yes', then the error-log file is read and
sent to my webserver. My webserver then sends me an e-mail. This way,
users can remain anonymous (no e-mail/reply address necessary).
I let my app die immediately after calling the asynchronous method. If
my app couldn't bind to the service for any reason, the old and
trusted force-close message from Android is shown instead.
On Feb 25, 3:10 pm, focuser linto...@gmail.com wrote:
Hi fellow Android developers,
How many times have you asked users to send you the logcat result to
track down a nasty force-close? How many users have actually replied?
It's not that users are lazy or busy. Having to run the logcat
command or download an external log collector app just means too much
trouble for them. It should be much simpler. It should be just one
tap.
In fact I'm surprised (or being ignorant) that an easier error
reporting mechanism has not existed yet in the Android API, especially
for the infamous force-close. That is why I coded and open-sourced
Android, send me logs!, a small code library that makes it easy to
detect force-close and send logs from within your own apps. You can
program it to report errors with just one tap, and also include your
own tracing information.
Please check it out athttp://code.google.com/p/android-send-me-logs/.
It's still in very early stage, and I would appreciate your critism,
suggestions, comments, or even code contributions.
Linton Ye
--
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
[android-developers] Re: Android, send me logs! - code library for detecting force-close and sending logs
I love this idea! I'd like to build it into the source itself, that would be a life saver.. lol -- 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
[android-developers] Re: Android, send me logs! - code library for detecting force-close and sending logs
Mike - I think Apple's approach may be good for Apple, and probably not that compatible with the openness of Android? Also, what's better of Apple's approach other than that users don't have to give their identity (email addresses etc) to individual developers? If you suggest it here, we could definitely consider to add it to the library if appropriate. mssmison - thanks for your interest and compliment. Please let me know if you have any issues with the code. On Feb 25, 4:38 pm, mssmison cpoul...@gmail.com wrote: I love this idea! I'd like to build it into the source itself, that would be a life saver.. lol -- 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
