Android Style vs. Theme and Attribute Resolution

WHAT THIS TESTS: This question assesses your understanding of resource indirection, a core principle for building scalable and maintainable Android UIs. It separates candidates who can only apply static resources from those who understand how to build dynamic, themeable apps. The interviewer is testing if you know the difference between compile-time and runtime resource resolution and the practical implications of each, such as implementing a dark mode.

A GOOD ANSWER COVERS: First, define a Style as a collection of attributes applied to a single View. It's for localizing a look, like for a specific type of button. Second, define a Theme as a style applied to a Context (like an Activity or Application), making its attributes available to the entire View hierarchy within that context. A Theme provides global defaults. Third, explain that a direct reference like @color/purple_500 is resolved at compile time by AAPT2 into a static integer ID pointing to a specific hex value. Finally, explain that an attribute reference like ?attr/colorPrimary is an indirect pointer. At runtime, when a View is inflated, the system queries the current Context's Theme to resolve this attribute into a concrete resource, allowing the value to change based on the active theme.

COMMON WRONG ANSWERS: Saying Styles and Themes are the same or interchangeable. While related, their scope and application are distinct. The most significant red flag is stating that ?attr/ is resolved at compile time. This indicates a fundamental misunderstanding of the entire theming mechanism. Another mistake is describing a Theme as just a 'big style' without mentioning its critical link to a Context and the View hierarchy. A weak answer also fails to explain why runtime resolution is powerful, missing the connection to features like light/dark modes or product-specific branding.

LIKELY FOLLOW-UPS: Expect questions like: "How would you define and use a custom theme attribute?" (Answer: Declare <attr> in attrs.xml, define it in your <style name="Theme.App">, and use it with ?attr/myCustomAttr in layouts). Or, "What is a theme overlay and when is it used?" (Answer: Applying android:theme to a ViewGroup to style a specific part of the UI differently, like a dark-themed dialog in a light-themed app).

ONE CONCRETE EXAMPLE: Imagine a styles.xml file where colorPrimary is defined differently for a light and dark theme: <style name="AppTheme.Light"><item name="colorPrimary">@color/blue_500</item></style> and <style name="AppTheme.Dark"><item name="colorPrimary">@color/blue_200</item></style>. A layout file contains <Button android:background="?attr/colorPrimary" ... />. If the Activity's theme is AppTheme.Light, the button's background resolves to @color/blue_500. If the system switches to night mode and the Activity's theme becomes AppTheme.Dark, the same button's background resolves to @color/blue_200 without any code changes, because the ?attr/ lookup happens at runtime against the new theme.