In this article, we’ll explore a range of debugging techniques that can be used while developing in Android Studio. As developers, we all know that there are days where you spend way more time in your debugger than you do in your code editor.
If you don’t know what debugging actually is then check out the link below:
In this post, we’ll cover some of the essential tips and tricks that will be easy to incorporate into your debugging flow—and will hopefully make it more efficient.
Here are some of the tips that we will cover here:
- Log filtering
- Folding logs
- Conditional breakpoints
- Apply changes
- Analyze stacktrace
To start, I’ve created a really simple application with a list of users. We can remove the user by swiping a list item from left to right. We’ll consider this as a guiding example for our trying out our debugging techniques.
Every Android log message has a tag and a priority associated with it.
- The tag of the log message is the string that indicates the system from which the message is coming.
- The tag priority is one of the following character values:
- V — Verbose (lowest priority)
- D — Debug
- I — Info
- W — Warning
- E — Error
- A — Assert
Now, let’s open up Logcat — this is where all our Android logs surface in the IDE. In the above app example, I removed a user from the list and printed the log with the TAG name Remove Item.
In the below screenshot, you can see I’ve logged the message Remove Item : Yes for when any user is deleted from the list. These are the logs that are showing before the filtering is applied:
You might notice that from the above screenshot, there’s lots of other information showing in the Logcat, like the date and the package name, which we don’t currently care about.
To remove the unnecessary information from your Logcat, we need to follow these steps:
- Go to the Logcat’s left panel → settings icon ⚙
- Uncheck the unnecessary pieces of information you’d like to exclude.
When we fold logs, we essentially create a filter that will collapse all of them together and omit other information that we don’t care about. To do this, we need to highlight the relevant substring between all the various irrelevant bits of information.
- Right-click the log string
- Select the option Fold lines like this from the popup, which will look like the below screenshot:
- After that, you will see the console pop up, and in that pop up, click Ok.
Here’s the example below of how you can do that
The conditional breakpoint basically allows you to stop the execution of your code when any certain condition is met. To demonstrate the need for this, let’s look at the sample code below:
I’ve created a function called checkUserCount with the param userCount. If the userCount is less than 10, then we need to add more users. Otherwise, we do nothing.
In this case, we want to debug the function i.echeckUserCount, which ensures that user counts are less than 10.
In the above screenshot, we can see that when we first called our function checkUserCount, the value of the userCount returns 11, and it will catch the breakpoint and print “Do Nothing”.
Now, what if I want to catch the breakPoint only for addMoreUsers to do that we need to set the value of the userCountwhich will be less than 10. Here are the steps you need to follow.
- Right-click on the breakpoint in the debugger
- Add the condition (i.e. userCount value threshold)
- Hit done
Here’s the screenshot showing what this looks like:
If the value is equal to true when the code hits it, then we’ll catch the breakpoint.
Apply Changes uses platform APIs from Android Oreo (8.0) and higher to ensure reliable and consistent behavior.
Android Studio now features three buttons that control how much application is restarted, here’s these are
- Run will deploy all the changes and restart the application.
- Apply Code Changes will change only your code changes without restarting anything.
- Apply Changes will change your resource and code changes and restart only the activity without restarting the app.
Above, Apply Changes disabled because I’m running on Android 7.0 (i.e. below Oreo).
Let’s say you’re debugging your code, you added something new, and this is the point where you might decide to restart the application and again hit the debug button. In that case, you can use Apply Changes to implement your code changes and see them reflected in your application.
The benefit of using the apply changes is it will not modify the APK file.
And finally, despite all of these tips and tricks, you are going to still write some bugs, you’re still going to publish them, and you’re still getting a bug report. If you ever get a bug report that has a call stack in it, just copy that stack, head over to you Android Studio project and follow this flow:
Analyze tab → Analyze Stack Trace or Thread Dump → paste the stack there.
After this, you’ll see that the Android Studio console stack is fully annotated—this means you can click those annotated/highlighted classes that are causing the bug and quickly jump to your codebase with the exact line number.
Below is an example of how you can do that:
This article taught you some of the powerful debugging features available in Android Studio, which will make debugging more efficient and easy.
Apart from the above list here are some other tips which you can also learn from these links as well.
I hope this article is helpful. If you think something is missing, have questions, or would like to offer any thoughts or suggestions, go ahead and leave a comment below. I’d appreciate the feedback.
I’ve written some other Android-related content, and if you liked what you read here, you’ll probably also enjoy these:
Sharing (knowledge) is caring 😊 Thanks for reading this article. Be sure to clap or recommend this article if you found it helpful. It means a lot to me.