Android Studio: Debugging Tips n’ Tricks
Debugging is the key process of finding and fixing bugs or unexpected behavior in your code. All code has errors, from incorrect behavior in your app to behavior that highly consumes memory or network resources, to actual app freezing or crashing.
Debugging is one of the crucial parts of a software developer’s everyday life. We always attempt to write bug-free applications but to do this, we have to fix every bug, which is 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 mistakes in large pieces of code. In this article, we will go through important tips and tricks on debugging an Android app.
- Log filtering/folding
- Conditional breakpoints
- Dependent breakpoints
- Suspend thread
- Evaluate and log
- Breakpoint groups
- Drop frame
- Evaluate expression
- Apply changes
- Analyze stack trace
Log filtering / folding
If we open up Logcat in Android Studio, we are seeing these things on that Logcat surfaces.
Show date and time with seconds: 1517955388.555 123–456, process and thread IDs: SampleTag, package name: com.android.sample and show tag: This is a sample message
In most cases, we don’t need date and time, package name and thread IDs. So to do that we can uncheck these options and we can view what are necessary.
To add Custom filter we can set through Filter Drop-Down ->Edit Filter Configuration->Create New Logcat Filter
We can set any filter message on the Filter Name section and we can find easily on Logcat.
Folding is managing the same kind of line of the message as doing a folding trick: Choose any message from Logcat and then right-click on that message ->Fold Line Like This->Double Click On Choose message (Can change message)->Then Ok.
Now we can fold and open the message of the same lines.
Conditional breakpoints
Add a breakpoint, as you normally do, and click with the right mouse button on it. You will be prompt with a dialog. In the condition, you can put some kotlin/java code.
The debugger can also stop execution on breakpoints only when some conditions are met. We can apply expressions and hit count conditions to any breakpoint and remove them without resetting the breakpoint. We’ll revisit the Breakpoints Window to add expressions and hit count conditionals.
Dependent breakpoints
Dependent Breakpoints(Not a Conditional Bp) ( Breakpoint1 is enabled if B2 is enabled etc..)
For this purpose, the debugger allows you to create dependent breakpoints.
To set a breakpoint the current one must depend on
- Do one of the following:
- Right-click the corresponding breakpoint icon in the left gutter and click More in the opened breakpoint properties.
- In the Breakpoints dialog (Ctrl+Alt+B or Run | View Breakpoints… ), select the desired breakpoint. Note that in this dialog, you can also set a dependant breakpoint.
2. In Disabled until the selected breakpoint is hit, select a breakpoint the current one must depend on.
3. After breakpoint was hit, select
- Disable again to disable the current breakpoint after the selected breakpoint is hit.
- Leave enabled to keep the current breakpoint enabled after the selected breakpoint is hit.
Suspend thread
If we are trying to debug multithread apps in Android Studio, we could have troubles with some of our breakpoints, so it’s better to enable an Android Studio option to pause all threads by default setting.
When the currently executing thread encounters the breakpoint, it will just stop every thread in the application.
Evaluate and log
“Evaluate and Log” multiple variables or make a string expression at a breakpoint. In this case, it will not stop app execution further and will get debug strings.
Just unselect the Suspend checkbox -> select Evaluate and log checkbox and add any kotlin expression. Then it will evaluate the expression and log into the log section without suspending the thread.
Breakpoint groups
If we are working on multiple bugs, sometimes we need to move on to another bug without completing the currently working bug. In this condition, most of the developers disable the previously added debugger. So, breakpoint groups are the feature to save breakpoints for future purposes.
Right-click on the breakpoint -> click on the More -> select multiple breakpoints we want to group -> Right-click -> Create new -> give group name
Then we can enable/disable them in a single click.
Drop frame
We can drop the frames until we reach the point where we want to be. This isn’t exactly stepping backward, but it is quite similar in a lot of respects.
For example, we step over a method called a() expecting to get 2 but after re-checking the value returned we notice it's 5 instead of 2. How can we step back to where we were before and step into the method to see what is going on? We know we can do this in Android Studio if targeting devices running with at least Android10.
Click on the Drop frame button: It will pull you out from the current method and put you right forward started and if you step into it again you will get a second chance.
Evaluate expression
When debugging an application, we can set a breakpoint and when that triggers, we can right-click in the editor and select ‘Evaluate Expression’ or just Evaluate Expression(Alt+F8). In this window, we can check any statement and data.
Apply changes
Apply changes tools in Android Studio are to provide that allows us to quickly edit and validate code changes in our app. Without reinstalling the app we can change our block of code and meantime we can debug as well.
This feature is available for devices and emulators running on Android 8.0 or newer, Android Studio now features three buttons that control how much of the application Run, Apply Changes and Apply Code Changes.
To achieve this feature:
- Add your debugger in any code of line
- Change/Add any code of line or conditions
- Attach a debugger into the new code of line
- Click on Apply Code Changes
- After applying code changes again click on Drop frame
- And at last hit step in button and your debugger will be in the changes code of line
Analyze stack trace
Finally, despite all of these tips and tricks, we are still going to write some codes, debug and will get crashes or bug reports as well.
So, to track stack trace text:
Go to Analyze -> Analyze Stack Trace or Thread Dump… ->Put stack trace or complete thread dump into the box(It will find value on the clipboard) -> Ok
It will quickly jump into the codebase.
Enjoy!! Happy Debugging 🙂
