How would you debug an app crash in Android Studio?
This tests your systematic debugging process. A good answer starts with Logcat to find the stack trace, then uses breakpoints to inspect program state *before* the crash occurs. A red flag is randomly adding print statements instead of using the debugger.
What's really being asked
This question evaluates your debugging methodology. The interviewer wants to see a systematic, efficient process for moving from a high-level symptom (a crash) to a specific root cause (a line of code with incorrect state). It's not just about knowing the tools exist, but how you apply them in a logical sequence: first analyze the report (Logcat), then inspect the scene (Debugger/breakpoints).
The full answer
A strong answer describes a four-step process. First, reproduce the crash reliably while monitoring Logcat. Second, filter Logcat for your app's process ID and look for the "FATAL EXCEPTION" tag to find the stack trace, identifying the exception type (e.g., NullPointerException) and the exact file and line number in your own code. Third, set a breakpoint a few lines before the crashing line and run the app in Debug mode. Fourth, when the breakpoint is hit, use the Debugger window to inspect variables, checking for nulls or unexpected values. Use "Evaluate Expression" to test hypotheses about the state.
The mistakes people make
The biggest red flag is a chaotic or inefficient process. A weak answer is "I'd add a bunch of Log.d statements to see what the values are." This shows a junior-level approach and unfamiliarity with the interactive debugger, which is far more powerful. Another red flag is only mentioning reading the Logcat trace. While essential, that's only the first step; a senior engineer is expected to use the debugger to inspect the program's state before the crash happens to understand the "why."
What usually comes next
Be ready for "What if the crash only happens on a specific device or Android version?" (Answer: Use the Android Emulator to create an AVD with those exact specs). Or, "When would you use a conditional breakpoint?" (Answer: In a loop that crashes after many iterations, like for (i in 0..1000), you can set a condition like i == 998 to stop just before the problem). Another is "How would you debug an OutOfMemoryError?" (Answer: Switch to the Memory Profiler to look for leaks or large bitmap allocations).
A concrete example
Imagine a NullPointerException in a RecyclerView adapter's onBindViewHolder. Logcat points to MyAdapter.kt:45. You'd set a breakpoint at line 43. When it hits, you inspect the position parameter and the underlying data list. You might find the list is smaller than the position indicates, or the object at that position is null because a network request failed silently. The fix would be to add defensive null checks or handle the failed network state properly.
Interview question
After identifying the exact line causing a crash from the Logcat stack trace, what is the most effective next step to understand the root cause?
- a.Use the Android Profiler to analyze CPU and memory usage patterns leading up to the crash.
- b.Set a breakpoint a few lines before the crash and run in Debug mode to inspect variable states.Correct
- c.Add several Log statements around the crashing line to print the values of relevant variables.
- d.Wrap the crashing line in a try/catch block to prevent the app from crashing.
Why? this is the answer
Setting a breakpoint allows you to interactively inspect the program's state right before the error, revealing the unexpected values causing the crash. While adding Log statements can work, it is a slower, iterative process compared to the interactive debugger.
Just read this? Test yourself on what you have been reading.
Read the original → developer.android.com
- #android
- #debugging
- #android studio
- #kotlin
You just looked this up. Could you explain it out loud?
That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on android — each one lists the topics its interview covers.
See open roles