How do you debug an app crash in Android Studio?

WHAT THIS TESTS: This question tests 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. It's not about listing tools, but about explaining the logical sequence of using them. A senior answer demonstrates moving from broad analysis (Logcat) to fine-grained inspection (breakpoints and variable state) to solve the problem quickly.

A GOOD ANSWER COVERS: A strong answer describes a clear, multi-step process. First, reproduce the crash reliably. Second, immediately check Logcat. Filter by the app's package name and look for a "FATAL EXCEPTION" log. The stack trace is the most important clue, pointing to the exact file and line number where the crash occurred. Third, if the stack trace isn't enough (e.g., a NullPointerException on a complex line), set a breakpoint on or just before the crashing line. Fourth, run the app in debug mode. When the breakpoint hits, use the Debugger window's "Variables" pane to inspect the state of all relevant objects. Fifth, if a variable is already in a bad state (e.g., null), move the breakpoint earlier in the call stack and repeat the inspection process until you find where the bad state was first introduced.

COMMON WRONG ANSWERS: The biggest red flag is immediately resorting to adding Log.d() or println() statements throughout the code. This is an inefficient, "shotgun debugging" approach that indicates a lack of familiarity with the IDE's powerful tools. Another weak answer is vaguely saying "I'd use a breakpoint" without explaining where you'd place it and what you'd look for. A senior candidate specifies why they are placing a breakpoint (e.g., "to inspect the user object before it's accessed") and what they'll do next based on what they find.

LIKELY FOLLOW-UPS: Expect questions that add complexity, such as: "What if the crash only happens on a background thread?" (Answer: Use the thread selector in the Debugger). "How would you debug a crash reported by a user in production?" (Answer: Analyze the stack trace from a crash reporting tool like Firebase Crashlytics). "What's the difference between a watch and evaluating an expression?" (Answer: A watch persists between steps; an evaluation is a one-time check).

ONE CONCRETE EXAMPLE: Imagine a NullPointerException on the line String url = user.getProfile().getAvatarUrl();. The Logcat stack trace points directly here. I would set a breakpoint on this line and run in debug mode. When it hits, I'd inspect the user object in the Variables pane. If user itself is null, I've found the problem. If user is not null, I would right-click and 'Evaluate Expression' on user.getProfile(). If that evaluates to null, I've pinpointed the immediate cause. My next step would be to find where the user object was created or modified and set a breakpoint there to understand why its profile was never set.