This has been one hell of a busy week for me. I think you can sort of tell from my Tweets and G+ posts that I have been debugging A LOT.

I was helping the new guy on our team look at something, and I think I almost gave him a heart attack.

It takes FOREVER to launch the app when you click that green bug. I hate that green bug. Save yourself some heartache:

  1. Put in your breakpoints
  2. Launch the app as you normally would
  3. Navigate to the offending activity
  4. Attach Debugger to Android Process

App encountering what looks like random crashing? Put in some exceptionally useful Exception Breakpoints! In the Breakpoints dialog (⌘+⇧+F8 / CMD+SHIFT+F8), click on the +, choose Java Exception Breakpoints and add the exception you are interested in.

This means that even without actual breakpoints – as long as the debugger is attached to the process – Android Studio will suspend the process on the exact line that will throw the exception. Very easy way of narrowing down on the root cause!

But what if (God forbid!) you uncover another issue while debugging? Now you have a ton of breakpoints but you don’t want to remove them because what if you still haven’t fixed that other thing and this line is really important but you don’t want to stop all the time. Ugh. It’s a mess!

Make some semblance of order out of the chaos. Group your breakpoints. A breakpoint group can contain any number of any kind of breakpoint that Android Studio supports. This allows you to mute/unmute a set of breakpoints without having to hunt them down one by one.

Just choose the interesting breakpoints, right click, then choose Move to group. From here you can either create a new group or add them to an existing group. You can configure each breakpoint to behave how you want them to: suspend the thread, log a message, hit and forget, etc.

Here’s the whole thing, in one magnificent gif.

Again, apologies to +Nick Butcher. I owe you a beer next time you’re in Sydney, Nick.