Droidcon Boston '19

This course is a part of Droidcon Boston 2019, a 32-course Paths series from Pluralsight.

We all use crash reporting tools in our apps, but have you ever wondered what happens under the hood? How do these crash reporters do what they do to make our debugging lives easier? Let’s find out! In this session, you'll learn how to create a crash reporting SDK from scratch using Android's UncaughtExceptionHandler, starting by capturing and sending stack traces to an HTTP endpoint. We'll then progressively add functionality onto our crash reporter until it's turned into a battle-tested SDK that we're confident will save us hours of debugging crashes in production. As expected diving deeper into the inner workings of our tools, we’ll encounter challenges along the way. We’ll analyze the various scenarios, what they mean for our apps, and how to best go about solving for them given tradeoffs and solutions. Here are some of the challenges we’ll encounter: For starters, we’ll discuss the design constraints caused by working in a low-memory environment, and how streaming IO and JSON serialization can help us capture OutOfMemoryErrors. We’ll also learn the best practices of caching undelivered reports on disk for future delivery and triggering automatic upload of reports in response to connectivity changes. We’ll consider privacy issues, like how we can collect useful metadata about the device and application at the time of crash while respecting user privacy by filtering sensitive information. To further expand our tool, we’ll capture exceptions caught in a try-catch block and discuss the difficulties with ensuring thread-safety in these situations. Then we’ll move on to the various strategies for testing a crash reporter and walk through the benefits of black-box end-to-end tests. Another issue to examine is how we can deobfuscate stack traces in apps which use R8—we’ll review uploading a mapping file to an HTTP endpoint and read its contents to reveal a readable stack trace. There are even things we can do to highlight the most useful parts of stack traces as well as thinking through grouping related errors together. Then we’ll consider supporting different API levels and how it affects the collection of useful data, and finally, we’ll touch on capturing errors in NDK apps and the potential pitfalls in the Java Native Interface.