A computer is a machine that follows a list of instructions called a program. An Android device is a computer and an app is a program.
After completing each instruction in an app, the Android device goes onto the next one by default. Some instructions, however, direct the device to jump to a different instruction in the list. An instruction can also tell the device to change the contents of a variable, which is a little container that holds a value such as a number or a piece of text.
So now we know two ways in which an app can tell the device to go wrong. The app can tell the device to go off course as the device executes its way through the list of instructions; or it can tell the device to put an incorrect value into a variable. These mistakes are called bugs in the app, and identifying and removing them is called debugging.
One way to debug the app is to look over the device’s shoulder as it executes the app’s instructions one at a time. We would also like to see the contents of the variables and watch the device change these contents at each step. But there’s a problem: the device normally executes a million instructions per second.
To slow the app down by a factor of a million, or even to pause it entirely while we think, we can subject it to the control of a tool called a debugger which is built into Android Studio. The debugger can also show us the contents of the variables, and even lets us change those contents to perform little tests and experiments to find out what has gone wrong.
But it can be very tedious to watch the app execute its instructions, perhaps repeating them millions of times, until we get to the instruction suspected of harboring a bug. To get there faster, we can insert a breakpoint — something like a stop sign or roadblock — at the instruction where we want the device to pause. Then we can let the debugger run the app at full speed, starting at its first instruction, confident that the device will pause for our inspection when it reaches the breakpoint.