Android

Resources

Resources are the additional files and static content that your code uses, such as bitmaps, user interface strings etc.

Each type of resource is placed in a specific subdirectory of your project's res/ directory.

You can add special qualifiers to resource directories to provide alternative resources for specific device configurations. At runtime, Android uses the appropriate resource based on the current configuration. 

res/
 --- drawable/
        icon.png
        background.png 
        
 --- drawable-mdpi/
        icon.png
        background.png 
 ...
 --- <resources_dir_name>-<qualifier>/

resource types

dir name description
animator XML files that define property animations.
anim XML files that define tween animations. Property animations can also be saved in this directory, but the animator directory is preferred for property animations to distinguish between the two types.
color XML files that define a state list of colors.
drawable Bitmap files (.png, .9.png, .jpg, .gif) or XML files that are compiled into Drawable subtypes.
mipmap Drawable files for different launcher icon densities.
layout XML files that define a user interface layout.
menu XML files that define app menus, such as an Options Menu, Context Menu, or Sub Menu.
raw Arbitrary files to save in their raw form, for example .mp3 files. As alternative you can put resources to /project/assets directory and read them with AssetManager.
values XML files that contain simple values, such as strings, integers, and colors.
xml Arbitrary XML files that can be read at runtime by calling Resources.getXML().
font Font files with extensions such as .ttf, .otf, or .ttc, or XML files that include a <font-family> element.

qualifiers

You can add multiple qualifiers to one directory name, by separating each qualifier with a dash. In this case, you must add them to the directory name in the order they are listed in the table.

configuration description
MCC and MNC

The mobile country code (MCC), optionally followed by mobile network code (MNC) from the SIM card in the device.

For example, mcc310 is U.S. on any carrier, mcc310-mnc004 is U.S. on Verizon, and mcc208-mnc00 is France on Orange.

language and region

The language is defined by a two-letter ISO 639-1 language code, optionally followed by a two letter ISO 3166-1-alpha-2 region code.

Android 7.0 (API 24) introduced support for BCP 47 language tags, which you can use to qualify language- and region-specific resources. To use a BCP 47 language tag, concatenate b+ and a two-letter ISO 639-1 language code, optionally followed by additional subtags separated by +.

Examples:

  • en
  • fr
  • en-rUS
  • fr-rFR
  • fr-rCA
  • b+en
  • b+en+US
  • b+es+419

If all your resources use a qualifier that is not correspond to current language, the system will not use them and your app will crash at runtime. For example, if all the string resources are Russian, and the device is in the English locale.
Layout direction The layout direction of your app.
  • ldrtl - layout direction from right to left.
  • ar - layout direction from left to right as in Hebrew language.

To enable right-to-left layout features for your app, you must set supportsRtl to "true" and set targetSdkVersion to 17 or higher in manifest file.
Smallest width

You can use this qualifier to ensure that, regardless of the screen's current orientation, your app's has at least N dps of width available for its UI.

sw<N>dp

Examples:

  • sw320dp
  • sw600dp
  • sw720dp

When your app provides multiple resource directories with different values for the smallestWidth qualifier, the system uses the one closest to the device's smallestWidth.

Remember that the smallest device width does not change when the screen orientation is changed.

Available width

Specifies a minimum available screen width, in dp units at which the resource should be used—defined by the N value.

w<N>dp

This configuration value changes when the orientation changes between landscape and portrait to match the current actual width.

Examples:

  • w720dp
  • w1024dp
Available height

Specifies a minimum available screen height, in dp units at which the resource should be used—defined by the N value.

h<N>dp

This configuration value changes when the orientation changes between landscape and portrait to match the current actual height.

Examples:

  • h720dp
  • h1024dp
Screen size

Possible values:

  • small - the minimum layout size for a small screen is approximately 320x426 dp units, for example QVGA low-density and VGA high density.
  • normal - the minimum layout size for a normal screen is approximately 320x470 dp units. Examples of such screens a WQVGA low-density, HVGA medium-density, WVGA high-density.
  • large - the minimum layout size for a large screen is approximately 480x640 dp units. Examples are VGA and WVGA medium-density screens.
  • xlarge - the minimum layout size for an xlarge screen is approximately 720x960 dp units. In most cases, these are likely tablet-style devices.

If all your resources use a size qualifier that is larger than the current screen, the system will not use them and your app will crash at runtime. For example, if all layout resources are tagged with the xlarge qualifier, but the device is a normal-size screen.
Screen aspect

Possible values:

  • long - long screens, such as WQVGA, WVGA, FWVGA.
  • notlong - not long screens, such as QVGA, HVGA, and VGA.

This isn't related to the screen orientation.
Round screen

Possible values (API 23+):

  • round - round screens, such as a round wearable device.
  • notround - rectangular screens, such as phones or tablets.
Wide color gamut

Possible values (API 26+):

  • widecg - displays with a wide color gamut such as Display P3 or AdobeRGB.
  • nowidecg - displays with a narrow color gamut such as sRGB.
High Dynamic Range (HDR)

Possible values (API 26+):

  • highdr - displays with a high-dynamic range.
  • nowidecg - displays with a low/standard dynamic range.
Screen orientation

Current screen orientation, possible values:

  • port - device is in portrait orientation (vertical).
  • land - device is in landscape orientation (horizontal).
UI mode

Possible values:

  • car - device is displaying in a car dock.
  • desk - device is displaying in a desk dock.
  • television - device is displaying on a television, providing a "ten foot" experience where its UI is on a large screen that the user is far away from, primarily oriented around DPAD or other non-pointer interaction.
  • appliance - device is serving as an appliance, with no display.
  • watch - device has a display and is worn on the wrist (API 20+).
  • vrheadset - device is displaying in a virtual reality headset.
Night mode

Possible values:

  • night - night time.
  • notnight - day time.
Screen pixel density (dpi)

Possible values:

  • ldpi - low-density screens; approximately 120dpi.
  • mdpi - medium-density (on traditional HVGA) screens; approximately 160dpi. It can be used for default resources.
  • hdpi - high-density screens; approximately 240dpi.
  • xhdpi - extra-high-density screens; approximately 320dpi.
  • xxhdpi - extra-extra-high-density screens; approximately 480dpi.
  • xxxhdpi - extra-extra-extra-high-density screens (API 18+); approximately 640dpi.
  • nodpi - this can be used for bitmap resources that you don't want to be scaled to match the device density.
  • tvdpi - screens somewhere between mdpi and hdpi; approximately 213dpi.
  • anydpi - matches all screen densities and takes precedence over other qualifiers. This is useful for vector drawables. (API 21+).
  • nnndpi - used to represent non-standard densities, where nnn is a positive integer screen density. This shouldn't be used in most cases.

There is a 3:4:6:8:12:16 scaling ratio between the six primary densities (ignoring the tvdpi density). So, a 9x9 bitmap in ldpi is 12x12 in mdpi, 18x18 in hdpi, 24x24 in xhdpi and so on.

If you don't provide alternative resources with qualifiers that better match the current device configuration, the system may use whichever resources are the best match.

Touchscreen type

Possible values:

  • notouch - device doesn't have a touchscreen.
  • finger - device has a touchscreen that is intended to be used through direction interaction of the user's finger.
Keyboard availability

Possible values:

  • keysexposed - device has a keyboard available. If the device has a software keyboard enabled (which is likely), this may be used even when the hardware keyboard isn't exposed to the user, even if the device has no hardware keyboard. If no software keyboard is provided or it's disabled, then this is only used when a hardware keyboard is exposed.
  • keyssoft - device has a software keyboard enabled, whether it's visible or not.
  • keyshidden - has a hardware keyboard available but it is hidden and the device does not have a software keyboard enabled.

This configuration value can change during the life of your application if the user opens the hardware keyboard.

Primary text input method

Possible values:

  • nokeys - device has no hardware keys for text input.
  • qwerty - device has a hardware qwerty keyboard, whether it's visible to the user or not.
  • 12key - device has a hardware 12-key keyboard, whether it's visible to the user or not.
Navigation key availability

Possible values:

  • navexposed - navigation keys are available to the user.
  • navhidden - navigation keys aren't available (such as behind a closed lid).
Primary non-touch navigation method

Possible values:

  • nonav - device has no navigation facility other than using the touchscreen.
  • dpad - device has a directional-pad (d-pad) for navigation.
  • trackball - device has a trackball for navigation.
  • wheel - device has a directional wheel(s) for navigation (uncommon).
API level

The API level supported by the device. Examples:

  • v4 - devices with Android 1.6 or higher, i.e API 4+.