Simple Android Debug Procedure

Identify WHERE the issue is happening

1. Look at the logcat error to see if you can immediately identify the issue in the line of code
2. Make sure to use Log.e(“tag”,”specific error note”) rather than in app toasts/popups. The UI execution thread can be blocked by other operations, but the log is written independent of execution.
3. Always include e.printStackTrace(); in your try-catch blocks. Otherwise runtime exceptions fail silently.
4. Isolate the last change that led to the issue (with code X it works but X+ doesn’t)
5. Run through the code in your head (what should be executing/running/open)

Identify WHAT the issue is (get to a Google query)

1. Look at stack Logcat errors/traces.  Any errors?  Any outputs that are not expected?
2. Work your way down the call stack.  Start with the first method (onCreate) and work your way to the last method viewing variables at runtime along the way to make sure they are what you'd expect.
3. Watch inheritance
• A lot of pain has come from issues with overrides.  For example I assume my code is using java.library.newclass when instead it’s using mycode.newclass or android.newclass.

Finding a solution

1. Google it to see if is a common issue
2. Answers usually come from stack overflow/api documentation. 
• Beware so sub-optimal implementations. There is a strong temptation using stack overflow just to paste in a solution to see if it works, but if you don’t understand what is going on it will introduce issues for you in the future
• For example I added an animation sequence in android that overrode the onpause method. This caused an unhandled exception to fire every time I tried to call finish() or pause() or a user hit the home/back button. Huge pain to find and its not an issue that is immediately apparent (ie you’ll go 5-10 versions forward before discovering it. Then you need to backtrack).
3. If you can’t find it you probably have another error in your code causing it
4. This is a good time to roll back your code to the last time it was working and clean it all up/comment. 

• This is good practice.
• It is an opportunity to examine every line of code again to see if anything triggers an association with the trouble spot

Last Word: Version Control

Most of your errors will be caused by the last piece of code added. However, the tougher ones were introduced a long time ago, and you only found it now. Good version control lets you quickly step back in your version history to identify where the bug was introduced. Even if you are a lone wolf developer get your GitHub/SVN/CVS on.