-
Notifications
You must be signed in to change notification settings - Fork 169
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Top-level exception handling #681
Comments
How will the stacktraces look from a release build? i ve seen some before and they are basically useless example
We could probably disable obfusication if isnt already since it's foss anyway but minimization/release optimizations will still make it look like that |
It looks like GlitchTip is FOSS and supports android reporting, but I have no experience with it. I also don't know how this interacts with optimizers. We could, at the very least, manage exception messages better. I have seen that raygun supposedly works with R8/ProGuard, but that's not free and probably not worth paying for with the current scale of Jerboa. Anyone have any experience with other tools? I use Sentry at work, so I'm partial to GlitchTip. |
It seems its possible |
I've always used Sentry at work. I know Firebase Crashlytics also de-minifies/de-obfuscates if you provide source maps, and it's free afaik. I'm not sure how to open it for OSS projects though. |
I have disabled obfuscation, and the stack traces are pretty readable. Dessalines won't agree to it unless its FOSS and we can host it ourselves. |
Fixed by above PR. |
"We should probably implement some sort of top level exception handling that allows the user to submit a bug report directly from the app to make it easier to get a full backtrace. If you can get the full backtrace from logcat that'd be great." - #538 (comment)
The text was updated successfully, but these errors were encountered: