Which tool inspects the view hierarchy to debug layouts?
This tests your knowledge of core Android Studio debugging tools. A great answer names the Layout Inspector, describes its 3D component tree and attributes pane, and notes its live update capability on API 29+. A red flag is only mentioning XML files.
What's really being asked
This question tests your hands-on experience with Android Studio's core debugging utilities. It's not about theoretical knowledge but whether you've actually debugged a complex layout issue. The interviewer is looking for familiarity with the Layout Inspector, its specific features, and how it provides insights that static XML analysis cannot. Mentioning its capabilities with both Views and Compose is a key differentiator for a senior candidate.
The full answer
A strong answer identifies the Layout Inspector and then details its three main components. First, the Component Tree, which shows the live hierarchy of Views or Composables. Second, the Layout Display, which provides a 2D or 3D visualization of the UI, allowing you to rotate and slice the view stack to understand overlap and depth. Third, the Attributes Pane, which is critical for debugging as it shows the final, resolved value of every attribute for a selected view and exactly where that value came from (e.g., a style, a theme, or an inline declaration). Mentioning the "live updates" feature on API 29+ is also a strong signal.
The mistakes people make
A weak answer is simply saying "I'd look at the XML." This completely misses the point of inspecting the running application, where state changes, styles, and programmatic modifications have already been applied. Another red flag is mentioning the Layout Inspector by name but being unable to describe what information it provides beyond "it shows the views." This suggests a lack of real-world use. Failing to mention the Attributes Pane is a significant omission, as it's the primary tool for solving "why is this view purple?" type problems.
What usually comes next
"Imagine the Layout Inspector shows a view is 100dp wide, but you set it to wrap_content in XML. What are some possible reasons for this discrepancy?" (Answer: parent constraints, a style overriding the value, programmatic change in code). Or, "How is inspecting a Compose hierarchy different from a View-based one in the Layout Inspector?" (Answer: Shows composable functions, not View objects; helps debug recomposition counts).
A concrete example
"I was debugging an issue where a button was unexpectedly shifted 16dp to the right. The XML layout_marginStart was 0dp. Using the Layout Inspector, I selected the button and checked the Attributes Pane. I saw that the final marginStart value of 16dp was being inherited from a style applied by the theme, which was overriding my local XML attribute. This allowed me to pinpoint the fix in the theme file instead of the layout file."
Interview question
A view's runtime appearance differs from its XML declaration. What key information does the Layout Inspector's Attributes Pane provide to diagnose this?
- a.A 3D rotatable model of the view hierarchy, showing how views are layered and overlap.
- b.The final, resolved value for each attribute and the exact source from which it was inherited, such as a style.Correct
- c.A direct link to the line in the XML file that defines the view, allowing for quick edits.
- d.A list of all programmatic changes made to the view in the corresponding Activity or Fragment code.
Why? this is the answer
The Attributes Pane is crucial because it shows the final, resolved value of an attribute and its origin, which often differs from the static XML due to styles or themes. The 3D model is a feature of the Layout Display, not the Attributes Pane.
Just read this? Test yourself on what you have been reading.
Read the original → developer.android.com
- #android
- #debugging
- #android studio
- #ui
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