Resources & Configuration Interview Questions
ANDROID › System
Explain why Android's resource system needs a 'best match' algorithm at all instead of just doing an exact string match on the directory name.
What a strong answer covers: A device's real configuration, density, locale, orientation, API level, night mode, and more, rarely matches any single folder's qualifier string exactly, and multiple qualifiers combine in real devices. The algorithm eliminates qualifiers the device can't satisfy, then picks the most specific remaining match according to a fixed precedence order, falling back toward the unqualified default folder, which is what gives graceful degradation across the huge combinatorial space of devices instead of a crash.
You're building UI that should look meaningfully different on a foldable's inner screen versus a phone. Would you reach for sw600dp resource qualifiers or Compose's WindowSizeClass, and why?
What a strong answer covers: sw600dp-style qualifiers are computed once from smallest width, typically at process start or activity recreation, and don't reactively update when a foldable unfolds or a window is resized in multi-window without a full recreation; WindowSizeClass recomputes from the actual current window size as it changes. For adaptive or resizable-window scenarios, WindowSizeClass is the modern recommended approach, while qualifier directories are still the right tool for genuinely static resources like drawables and strings, not for dynamic layout branching in Compose.
A designer hands you assets at 1x, 2x, and 3x. How do you decide which Android density buckets to actually ship, and what's the risk of just dumping every bucket you're given into the project?
What a strong answer covers: Map those scale factors onto Android's mdpi baseline, roughly 1x to mdpi, 2x to xhdpi, 3x to xxhdpi, and rely on Android's automatic scaling for buckets you don't ship, since the system scales the nearest available density rather than failing on a missing one; shipping every bucket you're handed is pure APK bloat, not a correctness requirement. For simple iconography, vector drawables in an anydpi bucket sidestep density buckets entirely, reserving raster assets for photographic content where vectors would look wrong or cost too much to render.