

In-App Diagnostics

Android has many tools to help you make sense of what is going on in your app, from complex tools like Traceview to simpler things like Logcat. Plus, if you are using an IDE, you have access to a debugger, which can let you step through code, inspect data members and other variables, and so on.

However, they all have one element in common: they are general-purpose tools. They know nothing specifically about your app, just Android apps in general. As a result, there may be information that you can gather that would be of immense benefit for debugging and diagnostic purposes, but that the general-purpose tools cannot collect for you.

More importantly, you need some way to see any diagnostic data that you collect. Logging stuff to Logcat can sometimes work, but then you have to worry about accidentally shipping that logging code in production, which would be less than ideal. And there are many cases where Logcat itself will not be a great visualization of the information.

What would be better is if we could add our own diagnostic tools to our app, for use while debugging, while excluding them from our release builds. And it would be great if we could add in these tools without changing much, if anything, of our production code to reference them. This chapter will explore how to implement such tools.


In addition to the core chapters, it would be a good idea if you had read:

Also, one of the techniques bears some resemblance to the tapjacking attack, though fortunately without the privacy and security ramifications.

One of the sample apps is based on a RecyclerView sample app, and so you may wish to skim the RecyclerView material to ensure that you understand enough about what is going on with the sample.

The Diagnostic Activity

The preview of this section will not appear here for a while, due to a time machine mishap.

The Diagnostic Overlay

The preview of this section was stepped on by Godzilla.