-
-
Notifications
You must be signed in to change notification settings - Fork 2.2k
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
Block reports sent to ACRA #17402
base: main
Are you sure you want to change the base?
Block reports sent to ACRA #17402
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
general idea looks good and implementation seems functional (though I have poor Kotlin taste still, so don't rely on that)
some comments on functional/non-functional mix in the comment but I was able to parse through
bit o bike-shedding on throwable vs exception in naming etc
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Architecture:
- This doesn't process logcat
- I believe this changes the type of the exception to
Throwable
AnkiDroid/src/test/java/com/ichi2/anki/CrashReportServiceTest.kt
Outdated
Show resolved
Hide resolved
AnkiDroid/src/test/java/com/ichi2/anki/CrashReportServiceTest.kt
Outdated
Show resolved
Hide resolved
with regard to "This doesn't process logcat" from David -> I noticed while verifying my acrarium purge that there were some instances where the stack prompting a current error did not contain an email but the included logcat did. So it is a valid concern. I altered my purge matcher to also match emails deeper into the report (logcat also, not just original stack) so I'm cleaning them now, but better if they never hit logcat. Whole thing is messy, for sure |
Work's left to be done. Still unsure about certain things. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks SO much better, thanks so much!!!
One suggestion, take it or leave it
Co-authored-by: David Allison <62114487+david-allison@users.noreply.github.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Approval still stands.
Important
squash-merge
Given discussion on Discord - pushing this back to also be implemented for unhandled exceptions
To be concrete about the idea of installing the filter as an uncaught exception handler also, here is exactly how to do it Anki-Android/AnkiDroid/src/main/java/com/ichi2/anki/analytics/UsageAnalytics.kt Lines 117 to 131 in 15b748a
As long as we already have the filter logic, it's just "store ref to original handler, install ourselves as handler, and after we handle an uncaught exception pass it on to the original handler" - idea being that this is yet another ask on the PR but this one is hopefully satisfyingly easy and then covers the last place these could slip through |
See title. Related:
#17392
ankidroid/Anki-Android-Backend#439
ankitects/anki@ba1f5f4
Preemptive "may lord have mercy".