Master These Debugging Techniques in Android Studio

Debugging breakpoints tracking is an important means of analyzing code and solving bugs during software development. The use of debugging tools varies across different IDEs, but the debugging features provided are certainly comprehensive. Many programmers’ debugging abilities are limited to basic step execution and breakpoint jumping, unaware that there are many lesser-known but very convenient debugging techniques. This article takes Android Studio as an example to showcase some debugging techniques that most people are not aware of; mastering these will make you a debugging master.

Basic Usage

There are two ways to debug an app: the first is to directly click the small bug icon next to the run button in the image below to run and debug the current project, which I think everyone knows.

The second method is to debug an app that is already running, which is also a more commonly used debugging technique, namely Attach debugger to Android process. Click the third button next to the run button, the Choose Process window pops up, select the corresponding process, and click the OK button to enter debugging mode; at this point, we can set breakpoints directly in the code where needed:

Next are common debugging methods. There is a row of operation buttons on the top toolbar of the debug window, such as Step Over (step execution), Step Into (enter method), etc., as shown in the image:

The most direct way to set and cancel breakpoints is to click on the blank space next to the line number of the target code. Then, in the debug window on the left side, there is a breakpoint browsing button View Breakpoints, located below the stop button, which allows you to browse all breakpoints in the project, as well as add and delete breakpoints:

Conditional Breakpoints

Sometimes, we set breakpoints inside a loop, but we only want to see the execution situation for a specific loop iteration. Do we have to use the Run to Cursor function to keep jumping to the next breakpoint until our requirement is met?

If you know about conditional breakpoints, you will definitely regret not using them earlier. Conditional breakpoints allow developers to input conditions, such as entering i == 5 in a fori loop to let the program run directly to the sixth iteration, or setting breakpoints for a specific element in a for each loop. Just right-click the breakpoint, input the condition in the pop-up window, click the Done button, and when the program executes to the loop body, it will stop at the iteration that meets the condition for debugging:

Log Breakpoints

Printing logs is also a very effective method for tracking and analyzing problems in programs. However, if our program is already running and in debugging mode, and we want to print logs for a more intuitive analysis of the code, do we have to stop debugging, add log code, and recompile and run it?

If you know about log breakpoints, you won’t have to go through such a hassle. Again, right-click the breakpoint, in the pop-up window uncheck the Suspeng checkbox (which means that the program will not stop at this breakpoint for debugging), and then check Log evaluated expression:, and enter the print statement. This way, when the program in debug mode reaches this point, it will not stop but will print the corresponding information in the console, such as:

Object Evaluation

At breakpoints, if there are variable objects, the system provides an expression evaluation function. For the variable objects in the Variables view, we can input any calculation statement and see the expression calculation result in real-time. The specific operation is to right-click the variable object in the Variables view, select Evaluate Expression, a pop-up expression window will appear, input any calculation statement you want, click the Evaluate button, and the result will be displayed:

Method Breakpoints

Typically, we add breakpoints to the code within methods and rarely debug the methods themselves. In fact, if we just want to see the parameters and return results of a method, we can set a breakpoint at the first line of the method definition and debug the method itself. At this point, the icon style of the breakpoint will also be different:

Variable Breakpoints

Sometimes, we want to know when and where a custom variable changes, so we can use variable breakpoints. The icon style of variable breakpoints is also different; set a breakpoint at the variable definition line, start debugging, and during program execution, if the value of that variable changes, the program will automatically stop and locate the place where the variable value changed for debugging:

Exception Breakpoints

During program execution, various unknown exceptions may occur. If we can make the program stop at the first moment an exception occurs and locate the place where the exception appears for debugging, that would be great. The versatile Android Studio provides such functionality.

Open the breakpoint manager, there are two ways to open it: click the tool menu Run, select View Breakpoints; in the debug window, click the View Breakpoints icon directly. Click the plus button in the upper left corner to add various breakpoints, including the Method Breakpoints and Field Watchpoints mentioned earlier. Here we select Exception Breakpoints, and in the pop-up Enter Exception Class window, input the exception category to monitor:

Welcome to Contribute

The above are some very practical but rarely seen debugging techniques using the Android Studio tool during the development process. Of course, all these operations can be opened via shortcut keys. Moving the mouse cursor over the corresponding icon will display the corresponding shortcut key combinations for you to use as needed.

Of course, if you have better debugging techniques, feel free to leave a comment to share, so we can learn together through sharing and progress through communication.