Resources & Configuration Quiz
ANDROID › System
A device is xhdpi (320 dpi). A view's height is set to 48dp. How many physical pixels tall is it?
- 64 px
- 48 px
- 24 px
- 96 px
Answer: 96 px
px = dp * (dpi / 160) = 48 * (320 / 160) = 48 * 2 = 96 px. xhdpi is a 2x density relative to the 160 dpi baseline.
Which directory name correctly orders its qualifiers per Android's rules?
- res/drawable-hdpi-night/
- res/drawable-night-hdpi/
- res/drawable-night-en/
- res/drawable/hdpi-night/
Answer: res/drawable-night-hdpi/
Qualifiers must follow the precedence table: night mode precedes density, so drawable-night-hdpi is correct. Locale (en) outranks night mode, and qualifiers cannot be nested in subfolders.
The device locale is en-US. Available: drawable/, drawable-en/, and drawable-fr/. Which is chosen?
- drawable-fr/
- drawable/
- drawable-en/
- It throws Resource Not Found
Answer: drawable-en/
drawable-fr/ contradicts the locale and is eliminated; between drawable-en/ and the default, the more specific matching qualifier (en) wins. The default is only used when nothing more specific matches.
Why is screen density handled specially in the resource-selection algorithm?
- Density qualifiers are ignored entirely on modern high-resolution phones and tablets
- A mismatched density is never eliminated; the closest bucket is picked and scaled
- Only the exactly matching density bucket is ever allowed to be selected at runtime
- Density always overrides locale within the qualifier precedence ordering table
Answer: A mismatched density is never eliminated; the closest bucket is picked and scaled
Unlike other qualifiers, a non-matching density does not disqualify a directory. Android keeps all density variants, picks the closest, and scales the bitmap, so a single asset can serve any screen.
Which qualifier is the recommended, orientation-stable way to provide a distinct tablet layout?
- layout-sw600dp, the smallestWidth-based tablet qualifier
- layout-large, the deprecated size bucket for larger screens
- layout-port, the orientation-only qualifier for portrait
- layout-xlarge, the old bucket for very large screens
Answer: layout-sw600dp, the smallestWidth-based tablet qualifier
smallestWidth (sw600dp) matches the screen's shortest dimension in dp and is constant across orientations, unlike the deprecated screen-size buckets (small/normal/large/xlarge) or orientation qualifiers.
Per current Android guidance, the Compact-to-Medium width breakpoint for window size classes is at:
- 480 dp
- 600 dp
- 720 dp
- 840 dp
Answer: 600 dp
Width classes are Compact < 600 dp, Medium 600–839 dp, and Expanded >= 840 dp, so the Compact/Medium boundary sits at 600 dp.
In Jetpack Compose, what is the recommended way to drive layout decisions for different display sizes?
- Read android.os.Build.MODEL to detect tablets by their reported device name
- Hardcode px thresholds read from DisplayMetrics.widthPixels at runtime
- Use WindowSizeClass via currentWindowAdaptiveInfo() for the window
- Lock the activity to portrait orientation and ship a single fixed layout
Answer: Use WindowSizeClass via currentWindowAdaptiveInfo() for the window
Modern guidance uses window size classes computed from the app's actual window (currentWindowAdaptiveInfo / WindowSizeClass), which behaves correctly in multi-window, desktop windowing, and on foldables, rather than physical device characteristics.
Why are font sizes conventionally specified in sp instead of dp?
- sp pixels are always physically larger than dp pixels on every screen
- sp is measured in raw physical pixels and ignores screen density entirely
- sp tracks density like dp, and also applies the user’s font scale
- sp disables all scaling so text keeps a fixed physical size on every device
Answer: sp tracks density like dp, and also applies the user’s font scale
sp behaves like dp for density scaling but additionally applies the user's preferred font scale, so text honors accessibility settings; dp does not respond to the font-size setting.
A vector drawable lives in res/drawable-anydpi-v24/. How does the resource system treat an anydpi directory during selection?
- It is scaled like ldpi assets when displayed on low-density screens
- It is used only on devices that report no specific density bucket
- It is ignored unless the device runs exactly API level 24
- It matches all densities and wins over density-qualified bitmaps
Answer: It matches all densities and wins over density-qualified bitmaps
anydpi matches every density and outranks density-qualified bitmaps, which is why density-independent vectors are placed there; the -v24 part additionally requires API 24 or higher, not exactly 24.
Which resource directory should hold color or theme overrides that apply only when the device is using dark theme?
- values-night/
- values-dark/
- values-darktheme/
- values-uimode-night/
Answer: values-night/
The night-mode UI qualifier directory is values-night, which Android selects when the system or app is in dark theme. 'dark', 'darktheme', and 'uimode-night' are not valid qualifier names.
You add res/layout-w600dp/. Compared with layout-sw600dp, how does the w600dp (available width) qualifier behave?
- It behaves the same as sw600dp and stays fixed across device rotation
- It uses the current available width, so its match can change on rotation
- It matches the screen height in dp rather than the available screen width
- It only works on Android 12+ devices and is silently ignored on older ones
Answer: It uses the current available width, so its match can change on rotation
wNNNdp is evaluated against the current available width, which differs between portrait and landscape, whereas smallestWidth (swNNNdp) uses the constant shorter dimension and stays fixed across rotation.
Why are launcher icons recommended to live in res/mipmap-* directories rather than res/drawable-*?
- Only mipmap folders may contain vector drawables, while drawable folders cannot
- The drawable folders are not permitted to hold PNG bitmap files, only XML assets
- Mipmap resources survive density splits and shrinking, keeping a crisp icon
- Mipmap icons are automatically tinted by the system to match the device theme
Answer: Mipmap resources survive density splits and shrinking, keeping a crisp icon
A launcher may display an icon from a higher density bucket than the device's own; mipmap resources survive density splits and shrinking while non-matching drawables can be removed, keeping the launcher icon crisp.
What does the -v31 suffix on a resource directory such as values-v31/ mean?
- The resources apply only to apps whose minSdk is exactly 31
- The resources target version 31 of the app, matching its versionCode
- The directory is deleted on devices below API 31 during installation
- The resources are selected on devices running API level 31 or higher
Answer: The resources are selected on devices running API level 31 or higher
The platform version qualifier vNN matches devices at that API level or above and is unrelated to versionCode; it is the lowest-precedence qualifier and is often appended automatically by the build tools.
Per the Material window size class system, the standard height breakpoints are:
- Compact < 480 dp, Medium 480 to 899 dp, Expanded >= 900 dp
- Compact < 600 dp, Medium 600 to 839 dp, Expanded >= 840 dp
- Compact < 720 dp and Expanded >= 720 dp, with no Medium class
- Height is never classified; only width has defined window size classes
Answer: Compact < 480 dp, Medium 480 to 899 dp, Expanded >= 900 dp
Window height classes are Compact < 480 dp, Medium 480 to 899 dp, and Expanded >= 900 dp, which differ from the width thresholds of 600 dp and 840 dp.