When building Android apps, your app is bound to crash from time to time or exhibit strange unexpected behavior. You know you have experienced a runtime exception when you see this in your emulator or device:
Don't worry though! This is totally normal and there's a specific set of steps you can take to solve these. Refer to our guide below and/or these debugging slides for more a detailed look at debugging crashes and investigating unexpected problems with your app.
As an Android developer, you'll need to cultivate a "debugging mindset" as well as build up defensive programming practices that make writing error-prone code less likely. In addition, you'll often find yourself in the role of a coding investigator in order to understand where and why an app is crashing or not working as expected. A few key principles about debugging are captured below:
- Just because a program runs, doesn’t mean it’s going to work as you expected. This class of issues are known as runtime errors. This is contrast to compile-time errors which prevent an app from running and are often easier to catch.
- Think of debugging as an opportunity to fill gaps in knowledge. Debugging is an opportunity to understand your app better than you did before and hopefully sharpen your ability to write correct code in the future by programming defensively.
- Debugging is a vital part of the software development process. Often you may find yourself on some days spending more time debugging crashes or unexpected behavior then writing new code. This is entirely normal as a mobile engineer.
The following high-level principles should be applied when faced with an unexpected app behavior during investigation:
- Replicate. Convince yourself that there is an issue in the code that can be repeatedly reproduced by following the same steps. Before assuming the code is broken, try restarting the emulator, trying the app on a device and/or fully re-building the app.
- Reduce. Try to isolate or reduce the code surrounding the issue and figure out the simplest way to reproduce what’s occurring. Comment out or remove extraneous code that could be complicating the issue.
- Research. If you are running into a major unexpected issue, you are probably not alone. Search Google for the behavior using any descriptive identifiers. Visit the issue tracker for the component you are seeing issues with. Search stackoverflow for posts about the same issue.
Armed with this mindset and the above principles, let's take a look at how to debug and investigate issues that arise within our apps.
When you see your app crash and close, the basic steps for diagnosing and resolving this are outlined below:
- Find the final exception stack trace within the Android Monitor (logcat)
- Identify the exception type, message, and file with line number
- Open the file within your app and find the line number
- Look at the exception type and message to diagnose the problem
- If the problem is not familiar, google around searching for answers
- Make fixes based on the proposed solutions and re-run the app
- Repeat until the crash no longer occurs
This process nearly always starts with an unexpected app crash as we'll see below.
Witnessing the Crash
Suppose we were building a simple movie trailer app called Flixster that lets the users browse new movies and watch trailers from Youtube. Imagine we ran the app, and we wanted to play the trailer and we saw this crash instead:
First off though when you see the crash dialog, don't press OK on that dialog until after you've already went through these steps be