Roman Palkoci6 min

Debugging in Android Studio

EngineeringProductFeb 4, 2016

EngineeringProduct

/

Feb 4, 2016

Roman PalkociAndroid Engineer

Share this article

Debugging is one of the essential parts of a developer’s everyday life. We always strive to write bulletproof code and bug-free applications but to do this, we have to fix every bug, which are sometimes hard to spot in the code. Debugging allows you to go through each line of code, evaluating your app’s variables, methods and how well your code is working. It’s easier to find small mistake in large pieces of code. In this article we will go through basic tips and tricks on debugging an Android app.

Start debug mode

When you want to start the debugging mode, first make sure your device is setup for debugging and connected to USB, and open your project in Android Studio (AS) and just click the Debug icon

. Then select your device in the Choose Device window, and Android Studio will launch your application in the debug mode. Android Studio will also automatically open the Debug tool. You can turn it on manually by clicking Debug!

at the bottom of Android Studio. Another way to start debugging without having to restart your app is by clicking on “Attach debugger to Android process”

. You also have to select the device and the app (process) you want to attach the debugger to. This option is also very useful if you want to debug a specific feature, and you have to go through a couple of other screens in the meantime. Because some operations run slower in the debug mode going through the app without the debug mode on is much faster. When you are one click away from the thing you want to debug, attach a debugger to your app and start debugging right there.

Debug using Logs

The easiest way to debug your code is to use Log. This is a utility that allows you to send log outputs, which you can then view in Logcat in AS. You don’t even need to run your app in the debug mode to do this. Simply use android.util.Log in combination with one of the following methods: Log.v(), Log.d(), Log.i(), Log.w(), Log.e() or Log.wtf(). All of them use 2 string parameters: TAG and your message. You can also pass Throwable as a third parameter, which will log your TAG, message and exception log. By using different methods — levels of verbosity (VERBOSE, DEBUG, INFO, WARNING, ERROR) — you can later filter the logs out or even set up AS and customize the Logcat text colors and text background for each level.

Here’s a simple example:

private static final String TAG = “MyActivity”;

...

button.setOnClickListener(new OnClickListener(){
	@Override
	public void onClick(View view){
		Log.d(TAG, “Click on button”);
    }
}

Verbose should never be compiled when you are doing the release build of your app, but you can do this during the development process. Debug logs are kept out at runtime, while Error, Warnings and Info logs are always kept in. Therefore, if you use any of these logs for developing purposes, don’t forget to remove them especially if you log some sensitive data. Better yet, wrap these logs into an if-statement.

For example:

if (BuildConfig.DEBUG) {
  Log.d(“Sensitive message”);
}

Or create your own BuildConfig field and set it up in a gradle file.

Logcat

At STRV we use the Logcat utility, which handles if-statement among other things. Check it out here. In build.gradle we have build config property LOGS, which can be set to true in the debug build type and to false in the release type. Logcat always check the LOGS property before logging any message. Then you don’t have to worry about wrapping it in any if-statement.

Simply call the method:

Logcat.d(“Your message here”);

You can also set other parameters in this class. The message can include “Code location”. This means that it displays the name of the method, the line of code and also the thread where Logcat is called. Another cool thing about Logcat is that you can log formatted messages. So instead of:

Logcat.d(“Message with index: ” + someInteger)

we use:

Logcat.d(“Message with index: %d”, someInteger)

This method allows you to have as many parameters as you want.

Breakpoints

When you are at the point where you can’t fix a bug just by looking at your code, it’s time to use breakpoints. Breakpoints allow you to pause the execution of your app at a particular line of code.

Setting up breakpoints

Just go to the file that you want to debug, find a line of code where you want to start and click on the sidebar to the left of this line. You will see a red dot there. Then run your app in the debug mode or attach a debugger (see above).

You can also customize your breakpoint configurations. Set up your breakpoints by right clicking on the red dot and then input a condition when you want to fire this breakpoint. It’s very handy when this piece of code is called multiple times but you want to stop at particular point. You can also open the breakpoints settings — View Breakpoints

— on the left side of the Debug tool window. You will be able to see all breakpoints, disable/enable each breakpoint or select one breakpoint from the list and configure it. For example, you can disable one breakpoint until another breakpoint is hit and then remove it once it’s hit.

Debug with breakpoints

Android Studio will highlight whatever line of code the app stops at when a breakpoint is hit. The hard part starts in the Debug window — examining every variable that is currently allocated and going line by line or jumping to another breakpoint. Expand the tree of an object, and you will be able to see all its field values. If it’s a custom object, it will show the same value as the toString() method. If you are interested in a particular field in this object or you want some easy-to-read result, override the toString() method. You won’t need to open the tree, you will see the result next to the root of the tree.
The cool thing is is that if you have a bitmap you can also see the image while debugging.

You can also set up watches to see only the variables you are interested in. But you can also evaluate any expression at your current execution point using the allocated variables and methods (or even other objects and methods from that particular object). You can also evaluate expressions in the Evaluate Expression view.

You can open the Variables view by clicking on the

icon and watches by clicking on () and Evaluate Expression by clicking

.

Once you figured out what’s going on at this particular point, it’s time to move to the next step. Here you have couple of options:

Step Over — go to the next line of code without entering a method at the current line

Step Into — go to the first line the inside method called at the current line

Step Out — go to the next line outside the current method

Resume Program — to continue the program normally or to advance to the next breakpoint

Capture Screenshots and Videos

Android Studio also allows you to capture screenshots or a short video of the device screen while your app is running. It’s useful as a promo, and you can also attach screenshots or videos to a bug report. To use it, run your app in the debug mode, open the Android DDMS tool window —

— then hit Screen Capture

and click Save. For video also run the app in the debug mode and open the Android DDMS tool window and then hit Screen Record

. Click on Start Recording and interact with your app. Click on Stop Recording, then enter a filename for the recording and click OK.

While no developer loves the debugging process, it is a necessary evil and will make your code better and your clients happy. Android Studio makes debugging easy … maybe even fun! (Or maybe not). In the words of the great Edsger W. Dijkstra: “If debugging is the process of removing software bugs, then programming must be the process of putting them in.”

We're hiring

Share this article