Debugging with Android Studio

Welcome back! In lesson 17 you built a Dice Roller that reacts to taps. Sooner or later every app you build will do something you did not expect: a wrong total, a button that does nothing, or the dreaded "App keeps stopping" dialog. Today you learn what professional developers do in that moment. They do not guess and they do not panic. They debug.

A bug is a gap between what you meant the program to do and what it actually does. Debugging is the detective work of closing that gap. Think of a mechanic whose danfo bus makes a strange noise. A bad mechanic replaces parts at random. A good one listens, opens the bonnet, tests one part at a time and finds the real cause. Android Studio gives you the stethoscope, the torch and the spanner.

By the end of this lesson you will be able to:

• Write messages to Logcat with Log.d, Log.i, Log.w and Log.e, and explain the six log levels.
• Filter Logcat by tag, level, package and message text so you can find one line among thousands.
• Read a stack trace from the top and find the exact line in your own code that crashed.
• Set a breakpoint, run your app in debug mode and pause it mid-execution.
• Use the Debug tool window: Variables, Watches, the call stack (Frames), and the step buttons (step over, step into, step out, resume).
• Use Evaluate Expression to test an idea on a paused app without editing code.
• Set a conditional breakpoint that only stops when something interesting happens.
• Follow a repeatable five-step method for hunting a bug.

How this fits the bigger picture: This lesson matches the official Use the debugger in Android Studio codelab, part of Unit 2, Pathway 2 of Google's Android Basics with Compose course. The official codelab walks through one sample app. We use our own app with two deliberate bugs, go further into Logcat and conditional breakpoints, and give you a method you can reuse for the rest of the course.

Why this lesson matters

Beginners often think good programmers write code without bugs. They do not. Good programmers are simply fast at finding bugs. A skilled debugger can fix in ten minutes what takes a guesser two hours, and the skills transfer to every later lesson: networking, databases, background work. Time spent here is repaid many times.

You should be comfortable with the following. Skim the lesson number if any item feels shaky.

1. A running Compose app

You need an Android Studio project with an Empty Activity and a working emulator or phone (lessons 3 to 5). If you can press Run and see your app, you are ready.

2. Functions, if and loops

We debug a function that loops over a list and an if that applies a discount. Both appear in lessons 8 and 9.

3. Data classes and lists

A data class is a small container for related values, such as a name and a price. A List holds several of them (lessons 11 and 14).

4. Basic state in Compose

You saw remember { mutableStateOf(...) } in lesson 17: a value that, when changed, makes the screen redraw. Lesson 19 explains it fully. Here we use it only to show a result on the screen.

5. The Android Studio layout

Android Studio has a Run tool window and a Logcat tool window along the bottom edge. If you cannot see them, use View > Tool Windows or click the icons on the bottom toolbar. Menu names move slightly between versions, so look for the nearest match.

Three kinds of bug

Logic bugs are the sneakiest, because the computer is happily doing exactly what you told it. Crashes at least tell you where they happened.

Your three debugging tools

              YOUR APP (running)
                    |
   +----------------+-----------------+
   |                |                 |
 LOGCAT        STACK TRACE       DEBUGGER
 "What did     "Where did it     "Freeze time and
  the app       crash, and        look inside the
  say?"         who called        app's memory."
                whom?"

• Logcat is the app's diary. You write sentences into it (Log.d) and Android writes its own as well. It is cheap and works on any device, but you only see what you remembered to log.
• Stack traces are the app's last words when it crashes. They list the chain of function calls that led to the crash.
• The debugger pauses the app on a line you choose and lets you inspect every variable, then run the code one line at a time. It is the most powerful tool, but it takes a minute to set up.

The five-step debugging method

Write this down. It works for every bug in every language.

1. Reproduce it. Find exact steps that trigger the bug every time. A bug you cannot reproduce cannot be fixed.
2. Read the evidence. Read the error message and stack trace top to bottom before touching any code.
3. Form one hypothesis. "I think the loop runs one time too many." One guess, written as a sentence.
4. Test the hypothesis with a log line or a breakpoint. Do not change code yet. Confirm that your guess is true.
5. Fix, then re-run the original steps to prove the bug is gone, and check that you broke nothing else.

Think about it: Why is step 4 (testing the guess) separate from step 5 (fixing)? Because fixing a wrong guess can hide the symptom while leaving the real cause alive, and then the bug returns later in a worse place.

We will debug a tiny app called Market Basket. It lists three things you bought at Bodija market, adds up the cost and gives a 10 percent discount when the total is above ₦10,000. It contains two deliberate bugs. Build it exactly as written first, then hunt the bugs with the tools above.

Step 1: Create the project

1. Choose File > New > New Project and pick Empty Activity.
2. Name it Market Basket, set the package name to com.techbase.basket, and keep the defaults for language (Kotlin) and build configuration.
3. Wait for Gradle to finish syncing.

Step 2: The logic file

Right-click the com.techbase.basket package, choose New > Kotlin Class/File, pick File and name it Basket. Replace the content with this:

package com.techbase.basket
import android.util.Log
private const val TAG = "BasketLogic"
data class BasketItem(val name: String, val price: Int, val quantity: Int)
/** Adds up price times quantity for every item. */
fun basketTotal(items: List<BasketItem>): Int {
 var total = 0
 for (i in 0..items.size) {
 val item = items[i]
 Log.d(TAG, "Adding ${item.name}: ${item.price} x ${item.quantity}")
 total += item.price * item.quantity
 }
 return total
}
/** Gives 10 percent off when the total is above 10,000 naira. */
fun applyDiscount(total: Int): Int {
 return if (total > 10_000) total / 10 else total
}

Do not fix anything yet. Both functions are wrong on purpose.

Step 3: The screen

Open MainActivity.kt and replace its content:

package com.techbase.basket
import android.os.Bundle
import android.util.Log
import androidx.activity.ComponentActivity
import androidx.activity.compose.setContent
import androidx.compose.foundation.layout.Arrangement
import androidx.compose.foundation.layout.Column
import androidx.compose.foundation.layout.fillMaxSize
import androidx.compose.foundation.layout.padding
import androidx.compose.material3.Button
import androidx.compose.material3.MaterialTheme
import androidx.compose.material3.Surface
import androidx.compose.material3.Text
import androidx.compose.runtime.Composable
import androidx.compose.runtime.getValue
import androidx.compose.runtime.mutableStateOf
import androidx.compose.runtime.remember
import androidx.compose.runtime.setValue
import androidx.compose.ui.Alignment
import androidx.compose.ui.Modifier
import androidx.compose.ui.unit.dp
private const val TAG = "BasketScreen"
class MainActivity : ComponentActivity() {
 override fun onCreate(savedInstanceState: Bundle?) {
 super.onCreate(savedInstanceState)
 setContent {
 MaterialTheme {
 Surface(modifier = Modifier.fillMaxSize()) {
 BasketScreen()
 }
 }
 }
 }
}
@Composable
fun BasketScreen(modifier: Modifier = Modifier) {
 val items = listOf(
 BasketItem("Rice", 4_500, 2),
 BasketItem("Beans", 1_500, 1),
 BasketItem("Garri", 800, 3)
 )
 var result by remember { mutableStateOf("Tap the button") }
 Column(
 modifier = modifier.padding(24.dp),
 horizontalAlignment = Alignment.CenterHorizontally,
 verticalArrangement = Arrangement.Center
 ) {
 items.forEach { item ->
 Text("${item.name}: ${item.quantity} x ₦${item.price}")
 }
 Button(
 onClick = {
 Log.d(TAG, "Calculate tapped")
 val total = basketTotal(items)
 val payable = applyDiscount(total)
 Log.i(TAG, "total=$total payable=$payable")
 result = "You pay ₦$payable"
 }
 ) {
 Text("Calculate")
 }
 Text(result, style = MaterialTheme.typography.headlineSmall)
 }
}

Block by block. BasketScreen keeps a list of three items and one piece of state, result, holding the sentence to show. When the button is tapped it logs a line, calls our two logic functions, logs the numbers, and updates result. The screen then redraws with the new text. The Log.d and Log.i calls are the beginning of your Logcat diary.

What should happen: 4,500 x 2 is 9,000, plus 1,500, plus 800 x 3 which is 2,400, so the total is ₦12,900. That is above 10,000, so a 10 percent discount of 1,290 leaves ₦11,610.

Run the app (green triangle) and tap Calculate. Something goes wrong: the app closes. Good. A bug to hunt.

Opening Logcat

Click Logcat in the bottom tool bar (or View > Tool Windows > Logcat). Make sure the device drop-down at the top shows your emulator or phone. You will see a fast-moving river of text. Android itself logs hundreds of lines a minute, so the skill is not reading Logcat, it is filtering it.

Log levels

Every log line has a level that says how important it is. There are six, from least to most serious.

Each call takes a tag (a short label, by convention the class name) and a message:

import android.util.Log
private const val TAG = "BasketScreen"
fun demoLogging(total: Int) {
 Log.d(TAG, "total is $total") // debug note
 Log.i(TAG, "Calculation finished") // information
 Log.w(TAG, "Total is unusually large: $total") // warning
 Log.e(TAG, "Could not read item") // error
}

A call with an exception attached prints the stack trace as well: Log.e(TAG, "Failed", exception).

Tip: Logging runs on a real device, so never log passwords, tokens or personal data. Anyone who plugs in your phone with a cable can read Logcat. Remove noisy debug logs before you publish (lesson 49 covers release preparation).

Filtering Logcat

The Logcat search box at the top accepts plain words and key:value filters. The syntax below is the one used by recent Android Studio versions. Older versions have a different filter dialog, so if a key is not recognised, look for the filter drop-down next to the search box.

Try it now. Type package:mine and look at your lines. You should see something similar to this, in the order the code ran:

D Calculate tapped
D Adding Rice: 4500 x 2
D Adding Beans: 1500 x 1
D Adding Garri: 800 x 3
E FATAL EXCEPTION: main

The last line is the clue. The logs prove the loop handled all three items, then something went wrong after Garri, which suggests it tried to go on to a fourth item that does not exist. We have a hypothesis already, without any debugger. That is the power of good logs.

Where Logcat is not enough

Logs only show what you remembered to log, and each new log needs a re-build and re-run. For a bug deep inside a calculation, you want to freeze the app and look around. That is the debugger.

When an exception is not handled, Android prints a stack trace in red. The trace for our crash will look similar to this. Exact wording and line numbers vary by Android version and by your code.

FATAL EXCEPTION: main
Process: com.techbase.basket, PID: 8123
java.lang.ArrayIndexOutOfBoundsException: length=3; index=3
    at java.util.Arrays$ArrayList.get(Arrays.java:3585)
    at com.techbase.basket.BasketKt.basketTotal(Basket.kt:13)
    at com.techbase.basket.MainActivityKt$BasketScreen$1$1.invoke(MainActivity.kt:62)
    at androidx.compose.foundation.ClickableNode$clickPointerInput$3.invoke(Clickable.kt:...)
    ...

How to read it

1. The first line after FATAL EXCEPTION names the exception type and a message: ArrayIndexOutOfBoundsException: length=3; index=3. Translation: "You asked for item number 3, but the list has only 3 items (numbered 0, 1, 2)."
2. Then come the frames, one per function call, newest first. Each is at package.Class.function(File.kt:line).
3. The frames from Android or library code (java.util, androidx, android.) are plumbing. Skip down to the first frame that is in your own package, here com.techbase.basket.BasketKt.basketTotal(Basket.kt:13).
4. Click the blue Basket.kt:13 link. Android Studio opens that file at that line. The crash happened at or just after that line.

read the trace like a family tree, from the crash upwards:

  Arrays$ArrayList.get      <- the library said "no such index"
        ^ called by
  basketTotal(Basket.kt:13) <- YOUR code asked for index 3   <-- start here
        ^ called by
  BasketScreen onClick      <- the button handler called basketTotal
        ^ called by
  Compose click handling    <- framework plumbing

Line 13 is val item = items[i]. Now look at the loop above it: for (i in 0..items.size). In Kotlin 0..3 includes 3. A list of three items has indexes 0, 1 and 2, so the loop made one visit too many. This is the famous off-by-one error.

The fix is to use until, which stops before the end value, or to loop over the items directly:

for (i in 0 until items.size) { /* ... */ } // indexes 0, 1, 2
for (item in items) { /* ... */ } // simplest and safest

Apply the second form in Basket.kt:

fun basketTotal(items: List<BasketItem>): Int {
 var total = 0
 for (item in items) {
 Log.d(TAG, "Adding ${item.name}: ${item.price} x ${item.quantity}")
 total += item.price * item.quantity
 }
 return total
}

Run again and tap Calculate. No crash. But the screen says You pay ₦1290, not ₦11,610. We have a second bug, a logic bug, and no stack trace to help. Time for the debugger.

Breakpoints

A breakpoint is a flag on a line of code that says: "when execution reaches here, pause the whole app before running this line."

1. Open MainActivity.kt and find the line val total = basketTotal(items).
2. Click once in the grey gutter (the narrow strip with line numbers) beside that line. A red dot appears. That is your breakpoint. Click it again to remove it.

Running in debug mode

A normal Run does not stop at breakpoints. You need Debug:

• Click the bug icon in the toolbar (next to the green Run triangle), or use Run > Debug 'app'.
• Android Studio installs the app in debug mode and opens the Debug tool window at the bottom.
• Tap Calculate in the app. The app freezes, the breakpoint line turns blue, and the Debug window shows the app's internal state.

If the app does not stop, check that the red dot is solid (not a red circle with a line through it, which means it is muted) and that you pressed the bug icon, not the triangle. Debugging is slower than normal running and uses more memory, which matters on a modest laptop. Close other heavy programs if the emulator stalls.

Anatomy of the Debug window

+--------------------------------------------------------------+
| Debug: app    [Debugger] [Logcat]                            |
+--------------------------------------------------------------+
| TOOLBAR: Resume | Pause | Stop | Step Over | Step Into |     |
|          Step Out | Run to Cursor | Evaluate Expression      |
+----------------------+---------------------------------------+
| FRAMES (call stack)  | VARIABLES  and  WATCHES               |
|  > onClick           |  items = ArrayList (size = 3)         |
|    invoke            |  result = "Tap the button"            |
|    ...               |  total = (not yet assigned)           |
+----------------------+---------------------------------------+

• Frames shows the same chain of calls as a stack trace, but live. Click a frame to see the variables as they were in that function.
• Variables shows every value in scope. Click the small arrows to open objects, so you can look inside items and see each BasketItem.
• Watches is a list of expressions you type in, such as items.size, that Studio re-calculates at every pause. Click the + in the Watches area.

The step buttons

When paused, you control time with these buttons. Shortcuts below are the defaults on Windows and Linux; on a Mac, hover over each button to see its shortcut, because they use the Command and Option keys.

Step Over versus Step Into is the one to remember. Imagine reading a recipe that says "make the stew (see page 40)". Step over means "trust the stew recipe, move to the next line". Step into means "turn to page 40 and read it".

Hunting Bug 2

With the app paused on val total = basketTotal(items):

1. Press Step Over (F8). The line runs and total appears in Variables. It should read 12900. That is right! So basketTotal is now correct.
2. The next line is val payable = applyDiscount(total). Press Step Into (F7) this time. The debugger jumps into applyDiscount in Basket.kt, with total = 12900 visible.
3. Press Step Over once. You are paused on the if line. Since total > 10_000 is true, the code takes the first branch and calculates total / 10.
4. Look at the Variables or hover over total / 10. It is 1290. The code returns one tenth of the price, not the price minus one tenth. We have found it: the discount formula is wrong.

You never needed to guess. Each step shrank the search area: first the total (fine), then the discount (wrong), then the formula.

Evaluate Expression: test the fix before writing it

Still paused inside applyDiscount, open Evaluate Expression (Alt + F8, or the calculator icon). Type total - total / 10 and press Evaluate. The result is 11610, which is the number we expected. You tested the fix without changing a single line of code or restarting. You can evaluate almost any Kotlin expression, call functions, and inspect objects here.

Now apply the fix:

fun applyDiscount(total: Int): Int {
 return if (total > 10_000) total - total / 10 else total
}

Press Stop (red square), then Run again and tap Calculate. The screen reads You pay ₦11610. Both bugs are fixed. Compare Logcat with package:mine:

D Calculate tapped
D Adding Rice: 4500 x 2
D Adding Beans: 1500 x 1
D Adding Garri: 800 x 3
I total=12900 payable=11610

The problem with simple breakpoints

Suppose the basket held 200 items and the bug only happens for the item called "Yam". A plain breakpoint inside the loop would pause 200 times. You would press Resume until your finger hurt. Android Studio offers three better answers.

Conditional breakpoints

Put a breakpoint on the total += item.price * item.quantity line in Basket.kt. Then right-click the red dot. A small pop-up appears with a Condition box. Type a Kotlin expression that returns true or false:

item.name == "Garri"

Now the app pauses only when the condition is true. With our three items it stops once, on Garri, and you can see item.quantity is 3. Other useful conditions:

item.price > 4000 // only expensive items
total > 9000 // only after the running total passes 9000

If you mistype the condition, Studio normally pauses anyway and complains, so check the Debug window for a message.

Logpoints (breakpoints that write instead of pause)

In the same right-click pop-up, tick Evaluate and log and type a message such as "item=" + item.name. The breakpoint no longer stops the app. It prints to the Debug console and the app runs at full speed. Logpoints let you add a log without editing code, rebuilding, or remembering to delete it later. Untick Suspend in the pop-up if the dialog offers it, so the app does not pause.

Exception breakpoints

Open Run > View Breakpoints (or Ctrl + Shift + F8). Use the + button to add a Java Exception Breakpoint and choose a type such as ArrayIndexOutOfBoundsException or the general IndexOutOfBoundsException. Now the debugger stops at the moment the exception is thrown, with all variables still alive, instead of after the app has already died. This is gold for crashes that are hard to trace.

Housekeeping

• Mute Breakpoints (the red dot with a slash in the Debug toolbar) turns all stops off temporarily.
• Breakpoints stay in the project until you remove them, so tidy up when you are done. A forgotten breakpoint in a loop makes the app look frozen.
• Debug is slower than Run. Never judge the speed of your app while debugging.

Mistake #1: Pressing Run instead of Debug. The symptom: you set a breakpoint and the app never stops. The fix: use the bug icon (Debug 'app'). If the app is already running, stop it and start it in debug mode, or use the Attach Debugger to Android Process button.

Mistake #2: Reading the bottom of the stack trace first. The problem: the bottom shows framework plumbing that is the same for every crash. The fix: read the exception name and message at the top, then find the first frame in your own package.

Mistake #3: Fixing without reproducing. The wrong approach: "I think I saw it crash once, so I changed something." The fix: always write down the exact taps that trigger the bug, change one thing, and repeat those exact taps. If the bug is gone, you have evidence. If you changed three things at once, you will never know which one worked.

Mistake #4: Too much logging. The wrong code: a Log.d on every line, so Logcat becomes a wall of text. The fix: log decisions and key values only, use a clear tag per class, and filter with tag: and package:mine. Delete temporary logs afterwards.

Mistake #5: Using println in an Android app. The problem: println output may not appear where you expect in Logcat and has no tag or level, so you cannot filter it. The fix: use Log.d(TAG, "...").

Mistake #6: Stepping into library code by accident. The symptom: you press F7 on a line and land in a file you do not recognise. The fix: press Step Out (Shift + F8) to return, and use Step Over by default. Only step into functions you wrote and want to inspect.

Mistake #7: Leaving breakpoints or sensitive logs in the app. The problem: breakpoints make later runs seem to hang, and logs can leak private data. The fix: review Run > View Breakpoints and your Log calls before you share or release an app.

Mistake #8: Believing the first idea. The problem: you assume the bug is in line 13 because that is where the crash showed, but the real cause is where a bad value was created, maybe ten lines earlier. The fix: use the Frames list and Variables to walk back to where the wrong value first appeared.

Question 1. Name the six Logcat levels from least to most serious and say which function writes an error.

Question 2. A stack trace lists many frames. Which frame do you look at first, and why?

Question 3. You are paused on a line that calls calculateFee(order), a function you wrote. What is the difference between Step Over and Step Into?

Question 4. A loop runs 500 times but the bug appears only when item.id == 237. What is the best breakpoint to use?

Question 5. What does Evaluate Expression let you do, and why is that useful?

Go deeper: official resources

• Android Basics with Compose, Unit 2, Pathway 2: the official pathway that contains the Use the debugger in Android Studio codelab.
• Debug your app: official guide to the debugger, breakpoints and the Debug window.
• Write and view logs with Logcat: the filter syntax and Logcat settings.
• Log reference: every Log function and level.