There is even a quick way to create this sort of breakpoint: just press the Shift key and click in the gutter. If you just want to quickly verify that your breakpoint was triggered and don’t care about specifics, use the “Breakpoint hit” message to log that the breakpoint has been hit. You can now add any code expression, and it will be evaluated and logged to the console. Here, in logic when the player is just about to collide with an object, setting a condition of player.health = 1 enables you to catch the last time the player collides with the object before their health drops to 0. When the code hits the line, if the expression evaluates to true the breakpoint activates. The condition can be any code expression that equates to a Boolean. To set a conditional breakpoint, right-click on a breakpoint and add a condition. To avoid this you can set a conditional breakpoint.

You set a breakpoint on collisions but now the code stops on every collision. For example, in a game you are developing, you may want to stop when a player collides with the object that uses up their last bit of health. You may need to chase down a bug that relates to a particular type of event in your app or game. This is useful because it preserves the settings on the breakpoint, including the things I’m going to mention next.

If you find that you have set a breakpoint at an inappropriate place, rather than clearing and resetting the breakpoint, you can drag it to the line that you care about. Now, you’ll start hitting your breakpoints as you normally would in a debug session.

In the Choose Process dialog, highlight the process you want to attach the debugger to and click OK.

Android studio debug device image