Three Steps to Quickly Improve Your Android Debugging Process

Getting Senty for Android up and running is incredibly easy, whether you’re coding in Java or a newer language like Kotlin. Plus the dependency only adds around 200kb to your APK, which is pretty negligible even if you’ve shrunk the size of your app as much as possible, either using ProGuard{:rel=”nofollow”}{:target=”_blank”} or a converted Wayne Szalinski shrink ray that works on apps instead of his family.

This standard implementation records errors when they occur, shows you a stack trace of where it occurred, and provides state about the user’s phone at the time, such as battery level, which version of Android they’re using, what hardware they have, the orientation of the phone, how much disk space is available, whether the device is rooted or not, etc. You could stop right there and feel pretty good about your error monitoring.

However, there are some additional things Sentry can do to enhance your error reports and help your team understand problems that might otherwise be confusing. Though these features take a little extra time to put in place, they’re worth the one-time effort — and you’ll be glad you implemented them when they’re the key to solving a puzzling problem.

Add Breadcrumbs

The more information you have on-hand that details exactly what your users were doing leading up to an error, the easier and less frustrating it is to fix that error. By using breadcrumbs, you’ll never again need to rely on a user’s (usually incomplete) description of when and how the problem occurred.

You can record a breadcrumb at any point in your application’s lifecycle. The most recent 100 breadcrumbs are stored in memory, then sent to Sentry alongside any errors that occur.

Let’s say you’re a social photo-sharing app. You’d want to record breadcrumbs for every key action a user can take: upload a photo, select a filter, alter that filter in some way, choose any of the different edit tools, complete edits, add a location, tag someone, share a photo, back out of the process and save a draft.

Recording breadcrumbs is easy:

Sentry.getContext().recordBreadcrumb(
    new BreadcrumbBuilder().setMessage("User 'Sally' began an image upload.").build()
);

Associate a user with the error

Tell Sentry who encountered the error. This can be a username from your app, an email address, an IP — something that will uniquely tie the user to the error. As with breadcrumbs, this is stored locally in memory and sent along with any errors that occur.

This is valuable in two contexts:

• From the developer side, you can see how many bugs this user has encountered and how many unique users a bug has impacted. If you have VIP users, you might even keep a special lookout for problems they’ve seen so that you can jump on those faster than you do for a typical error.

• From the customer experience side, if a user reaches out to you about a problem, you won’t need to have them explain it since you can find them and immediately see what they’re talking about. Using tools like Sentry’s community-created Zendesk integration{:rel=”nofollow”}{:target=”_blank”} you can even access this info within your support system; enabling agents to immediately see what problem the user is talking about, so they can provide the best possible answer in any given situation.

Since we’re unlikely to guess correctly as to how you manage usernames, this is not something we can automatically add to your app. However, it is another easy-to-add one-liner. Here’s how it’s done:

Sentry.getContext().setUser(
    new UserBuilder().setEmail("hello@sentry.io").build()
);

Users need only be described by one of: id, username, email or ip.

Add custom context with more tags and data fields

As noted at the very beginning of this post, we capture some basic phone state information (such as battery level and Android version) whenever a crash or error occurs. But there may be other pieces of information specific to your app that can help you get to the root of what’s causing a problem.

How fast was the phone moving? Maybe you notice an error is occurring whenever a phone hits 88mph, indicating the problem may be interference from a user’s Flux Capacitor as it sends them backwards or forwards in time.

What subscription plan is the user on? Maybe a specific error only occurs for people paying for your super expensive enterprise plan.

Even in situations where an error impacts everyone, you could potentially use this data to determine which users to reach out to first with apologies and/or manual fixes.

Adding extra context and tags is very easy:

// tags only allow strings as values and are searchable/sortable in Sentry
Sentry.getContext().addTag("tagName", "tagValue");

// extra data values can be any type, even collections, and are displayed at
// the bottom of the Sentry error UI
Sentry.getContext().addExtra("extra", "thing");

One of the biggest challenges debugging crashes and errors on Android comes from the huge diversity of conditions and devices your app finds itself in. With breadcrumbs and tags, not only can you aggregate data in real time to fix bugs faster than before, you’ll also gain a proactive, broader view of how to build features that your most valuable users will love.

​​