资源管理指南-优快云博客

本文详细介绍了在Android项目中如何管理和组织不同类型的资源文件，包括图片、布局、字符串等，并阐述了如何针对不同设备配置提供可选资源，以实现更好的适配效果。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

一.综述：

应尽量在程序代码中使用图片和字符串等外部资源，使得你可以独立地维护他们。使用外部资源还可以是你能够为不同的设备提供不同的配置，如语言和屏幕尺寸。为了为不同的设备提供合适的配置，你需要在你项目的 res/ 下组织你的资源，通过按类型和配置分组的一系列子文件夹。

对于任何一种资源，你可以为你的应用指定默认的和多个可选择的资源：

默认的资源是：不管设备配置而使用的资源或者当没有可选择的资源符合当前设备时被使用；
可选择的资源：你为一种指定的配置设计的。为了区分一组资源是为了一个特定的配置而设计的，需要在文件夹命上加上合适的限定。比如：当你的默认UI布局保存在 res/layout/目录中，你可以为横屏指定一个不通的布局，保存res/layout-land 在目录中。Android会自动根据当前的情况选择一种布局。

比如，图一表明了系统会为没有合适的可选资源可用时的两个设备使用相同的布局。图二则加入了大屏幕的可选布局资源文件：

接下来的文档为你如何组织应用资源文件，提供可选资源，在应用中访问他们以及其它的提供了指导：

提供资源：你可以为应用提供哪类的资源，在哪里保存他们，以及如何为指定的设备配置提供可选资源；
访问资源：如何使用你提供的资源。两种方式：在应用代码中引用或者从其它XML资源中引用；
处理运行时更改：如何管理Activity在运行时发生的配置更改；
本地化：从细节到整体地指导你的应用使用可选资源。此时对应唯一一种可选的资源，这对于吸引更多用户十分重要；
资源类型：一个你可以使用的资源类型的参考，描述它们的XML元素，属性和语法。

===============================================================================================================================

二.提供资源：

本节为你示范了如何为你的Android项目内的资源分类，被为指定的设备配置提供可选的资源。

1.资源分类：你应该把每一类资源放在 res/ 目录下的特定的子目录下。比如，这是一个简单项目的目录结构：

MyProject/
    src/  
        MyActivity.java  
    res/
        drawable/  
            icon.png  
        layout/  
            main.xml
            info.xml
        values/  
            strings.xml 
表1描述了 res/ 下支持的资源目录：

目录资源类型
animator/
属性动画(Android 3.0)

anim/
补间动画

color/
颜色

drawable/
Bitmap文件或被编译成drawable的资源：

layout/
布局文件

menu/
菜单资源

raw/
以原始方式存储的任意文件。

要打开这类文件，需要调用Resources.openRawResource()，输入资源ID（R.raw.filename）

如果需要处理原始文件名和文件级别，可以考虑存到asssets目录。

assets目录中的文件没有资源ID，可以使用AssetManager读取它们。

values/
values目录中的文件可以描述多种资源。

该目录中的文件，每个<resources>中的元素定义一个单独的资源。

你可以将多种资源放置都同一个文件。

然而，为了清晰，一种资源应该放到一个单独的文件里。

xml/
任意的xml文件，可以通过Resources.getXML()读取。各种XML配置文件必须存放到这里。

注意：千万不要在 res/ 下直接保存一个资源文件，这会引起编译错误。

目录	资源类型
`animator/`	属性动画(Android 3.0)
`anim/`	补间动画
`color/`	颜色
`drawable/`	Bitmap文件或被编译成drawable的资源：
`layout/`	布局文件
`menu/`	菜单资源
`raw/`	以原始方式存储的任意文件。要打开这类文件，需要调用Resources.openRawResource()，输入资源ID（R.raw.filename）如果需要处理原始文件名和文件级别，可以考虑存到asssets目录。 assets目录中的文件没有资源ID，可以使用AssetManager读取它们。
`values/`	values目录中的文件可以描述多种资源。该目录中的文件，每个<resources>中的元素定义一个单独的资源。你可以将多种资源放置都同一个文件。然而，为了清晰，一种资源应该放到一个单独的文件里。
`xml/`	任意的xml文件，可以通过Resources.getXML()读取。各种XML配置文件必须存放到这里。

2.提供可选资源：

几乎每一个应用都应该提供可选资源来支持特定的设备配置。比如，为不同的屏幕提供图片资源，为不同的语言提供字符串资源。在运行时，Android检测当前的配置并加载对于资源。

为指定的配置提供给指定的一组资源，分为以下2步：

1.在res/下创建一个形式为<资源名>-<配置限定>为的目录。可以为一个目录附加多个限定，用破折号分开。但是要注意顺序要同表二相同，否则将被忽略。

2.保存各自的可选资源在这个新的目录下。这个资源文件名被徐完全和默认的资源文件相同。如：

res/
    drawable/   
        icon.png
        background.png    
    drawable-hdpi/  
        icon.png
        background.png

Configuration Qualifier Values Description
MCC - MNC Examples:
mcc310
mcc310-mnc004
mcc208-mnc00
etc.
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.

If the device uses a radio connection (GSM phone), the MCC and MNC values come from the SIM card.

You can also use the MCC alone (for example, to include country-specific legal resources in your application). If you need to specify based on the language only, then use the language and regionqualifier instead (discussed next). If you decide to use the MCC and MNC qualifier, you should do so with care and test that it works as expected.

Also see the configuration fields mcc, and mnc, which indicate the current mobile country code and mobile network code, respectively.

Language and region Examples:
en
fr
en-rUS
fr-rFR
fr-rCA
etc.
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 (preceded by lowercase "r").

The codes are not case-sensitive; the r prefix is used to distinguish the region portion. You cannot specify a region alone.

This can change during the life of your application if the user changes his or her language in the system settings. See Handling Runtime Changes for information about how this can affect your application during runtime.

See Localization for a complete guide to localizing your application for other languages.

Also see the locale configuration field, which indicates the current locale.

smallestWidth sw<N>dp

Examples:
sw320dp
sw600dp
sw720dp
etc.
The fundamental size of a screen, as indicated by the shortest dimension of the available screen area. Specifically, the device's smallestWidth is the shortest of the screen's available height and width (you may also think of it as the "smallest possible width" for the screen). You can use this qualifier to ensure that, regardless of the screen's current orientation, your application's has at least <N>dps of width available for it UI.

For example, if your layout requires that its smallest dimension of screen area be at least 600 dp at all times, then you can use this qualifer to create the layout resources, res/layout-sw600dp/. The system will use these resources only when the smallest dimension of available screen is at least 600dp, regardless of whether the 600dp side is the user-perceived height or width. The smallestWidth is a fixed screen size characteristic of the device; the device's smallestWidth does not change when the screen's orientation changes.

The smallestWidth of a device takes into account screen decorations and system UI. For example, if the device has some persistent UI elements on the screen that account for space along the axis of the smallestWidth, the system declares the smallestWidth to be smaller than the actual screen size, because those are screen pixels not available for your UI. Thus, the value you use should be the actual smallest dimension required by your layout (usually, this value is the "smallest width" that your layout supports, regardless of the screen's current orientation).

Some values you might use here for common screen sizes:

320, for devices with screen configurations such as:
240x320 ldpi (QVGA handset)
320x480 mdpi (handset)
480x800 hdpi (high density handset)

480, for screens such as 480x800 mdpi (tablet/handset).
600, for screens such as 600x1024 mdpi (7" tablet).
720, for screens such as 720x1280 mdpi (10" tablet).

When your application provides multiple resource directories with different values for the smallestWidth qualifier, the system uses the one closest to (without exceeding) the device's smallestWidth.

Added in API level 13.

Also see the android:requiresSmallestWidthDp attribute, which declares the minimum smallestWidth with which your application is compatible, and the smallestScreenWidthDp configuration field, which holds the device's smallestWidth value.

For more information about designing for different screens and using this qualifier, see the Supporting Multiple Screens developer guide.

Available width w<N>dp

Examples:
w720dp
w1024dp
etc.
Specifies a minimum available screen width, in dp units at which the resource should be used—defined by the <N> value. This configuration value will change when the orientation changes between landscape and portrait to match the current actual width.

When your application provides multiple resource directories with different values for this configuration, the system uses the one closest to (without exceeding) the device's current screen width. The value here takes into account screen decorations, so if the device has some persistent UI elements on the left or right edge of the display, it uses a value for the width that is smaller than the real screen size, accounting for these UI elements and reducing the application's available space.

Added in API level 13.

Also see the screenWidthDp configuration field, which holds the current screen width.

For more information about designing for different screens and using this qualifier, see the Supporting Multiple Screens developer guide.

Available height h<N>dp

Examples:
h720dp
h1024dp
etc.
Specifies a minimum available screen height, in "dp" units at which the resource should be used—defined by the <N> value. This configuration value will change when the orientation changes between landscape and portrait to match the current actual height.

When your application provides multiple resource directories with different values for this configuration, the system uses the one closest to (without exceeding) the device's current screen height. The value here takes into account screen decorations, so if the device has some persistent UI elements on the top or bottom edge of the display, it uses a value for the height that is smaller than the real screen size, accounting for these UI elements and reducing the application's available space. Screen decorations that are not fixed (such as a phone status bar that can be hidden when full screen) arenot accounted for here, nor are window decorations like the title bar or action bar, so applications must be prepared to deal with a somewhat smaller space than they specify.

Added in API level 13.

Also see the screenHeightDp configuration field, which holds the current screen width.

For more information about designing for different screens and using this qualifier, see the Supporting Multiple Screens developer guide.

Screen size small
normal
large
xlarge
small: Screens that are of similar size to a low-density QVGA screen. The minimum layout size for a small screen is approximately 320x426 dp units. Examples are QVGA low density and VGA high density.
normal: Screens that are of similar size to a medium-density HVGA screen. 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: Screens that are of similar size to a medium-density VGA screen. The minimum layout size for a large screen is approximately 480x640 dp units. Examples are VGA and WVGA medium density screens.
xlarge: Screens that are considerably larger than the traditional medium-density HVGA screen. The minimum layout size for an xlarge screen is approximately 720x960 dp units. In most cases, devices with extra large screens would be too large to carry in a pocket and would most likely be tablet-style devices. Added in API level 9.

Note: Using a size qualifier does not imply that the resources areonly for screens of that size. If you do not provide alternative resources with qualifiers that better match the current device configuration, the system may use whichever resources are thebest match.

Caution: If all your resources use a size qualifier that is larger than the current screen, the system will not use them and your application will crash at runtime (for example, if all layout resources are tagged with the xlarge qualifier, but the device is a normal-size screen).

Added in API level 4.

See Supporting Multiple Screens for more information.

Also see the screenLayout configuration field, which indicates whether the screen is small, normal, or large.

Screen aspect long
notlong
long: Long screens, such as WQVGA, WVGA, FWVGA
notlong: Not long screens, such as QVGA, HVGA, and VGA

Added in API level 4.

This is based purely on the aspect ratio of the screen (a "long" screen is wider). This is not related to the screen orientation.

Also see the screenLayout configuration field, which indicates whether the screen is long.

Screen orientation port
land
port: Device is in portrait orientation (vertical)
land: Device is in landscape orientation (horizontal)

This can change during the life of your application if the user rotates the screen. See Handling Runtime Changes for information about how this affects your application during runtime.

Also see the orientation configuration field, which indicates the current device orientation.

UI mode car
desk
television appliance
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

Added in API level 8, television added in API 13.

This can change during the life of your application if the user places the device in a dock. You can enable or disable some of these modes using UiModeManager. See Handling Runtime Changes for information about how this affects your application during runtime.

Night mode night
notnight
night: Night time
notnight: Day time

Added in API level 8.

This can change during the life of your application if night mode is left in auto mode (default), in which case the mode changes based on the time of day. You can enable or disable this mode usingUiModeManager. See Handling Runtime Changes for information about how this affects your application during runtime.

Screen pixel density (dpi) ldpi
mdpi
hdpi
xhdpi
nodpi
tvdpi
ldpi: Low-density screens; approximately 120dpi.
mdpi: Medium-density (on traditional HVGA) screens; approximately 160dpi.
hdpi: High-density screens; approximately 240dpi.
xhdpi: Extra high-density screens; approximately 320dpi. Added in API Level 8
nodpi: This can be used for bitmap resources that you do not want to be scaled to match the device density.
tvdpi: Screens somewhere between mdpi and hdpi; approximately 213dpi. This is not considered a "primary" density group. It is mostly intended for televisions and most apps shouldn't need it—providing mdpi and hdpi resources is sufficient for most apps and the system will scale them as appropriate. This qualifier was introduced with API level 13.

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

If you decide that your image resources don't look good enough on a television or other certain devices and want to try tvdpi resources, the scaling factor is 1.33*mdpi. For example, a 100px x 100px image for mdpi screens should be 133px x 133px for tvdpi.

Note: Using a density qualifier does not imply that the resources are only for screens of that density. If you do not provide alternative resources with qualifiers that better match the current device configuration, the system may use whichever resources are the best match.

See Supporting Multiple Screens for more information about how to handle different screen densities and how Android might scale your bitmaps to fit the current density.

Touchscreen type notouch
finger
notouch: Device does not have a touchscreen.
finger: Device has a touchscreen that is intended to be used through direction interaction of the user's finger.

Also see the touchscreen configuration field, which indicates the type of touchscreen on the device.

Keyboard availability keysexposed
keyshidden
keyssoft
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 is not 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.
keyshidden: Device has a hardware keyboard available but it is hidden and the device does not have a software keyboard enabled.
keyssoft: Device has a software keyboard enabled, whether it's visible or not.

If you provide keysexposed resources, but not keyssoft resources, the system uses the keysexposed resources regardless of whether a keyboard is visible, as long as the system has a software keyboard enabled.

This can change during the life of your application if the user opens a hardware keyboard. See Handling Runtime Changes for information about how this affects your application during runtime.

Also see the configuration fields hardKeyboardHidden andkeyboardHidden, which indicate the visibility of a hardware keyboard and and the visibility of any kind of keyboard (including software), respectively.

Primary text input method nokeys
qwerty
12key
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.

Also see the keyboard configuration field, which indicates the primary text input method available.

Navigation key availability navexposed
navhidden
navexposed: Navigation keys are available to the user.
navhidden: Navigation keys are not available (such as behind a closed lid).

This can change during the life of your application if the user reveals the navigation keys. See Handling Runtime Changes for information about how this affects your application during runtime.

Also see the navigationHidden configuration field, which indicates whether navigation keys are hidden.

Primary non-touch navigation method nonav
dpad
trackball
wheel
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).

Also see the navigation configuration field, which indicates the type of navigation method available.

Platform Version (API level) Examples:
v3
v4
v7
etc.
The API level supported by the device. For example, v1 for API level 1 (devices with Android 1.0 or higher) and v4 for API level 4 (devices with Android 1.6 or higher). See the Android API levels document for more information about these values.

Caution: Android 1.5 and 1.6 only match resources with this qualifier when it exactly matches the platform version. See the section below about Known Issues for more information.

限定名规则：

可以为同一组资源附加多个限定名，用破折号分开。如drawable-en-rUS-land被应用于横屏模式下的美语设备；
限定名顺序必须与上表一致，如drawable-hdpi-port/是对的，而drawable-port-hdpi/是错的；
可选资源目录不能陪嵌套，如，不可以使用res/drawable/drawable-en/这样的目录；
目录是大小写不敏感的；
每个限定种类只能有一个值。比如，你不能使用 drawable-rES-rFR/，而要用drawable-rES/和drawable-rFR/来代替；
然而，你不必为上述第五点的情况复制文件，而可以使用资源的别名；

创建别名：当你想为多个设备配置使用同一个资源但又不想设置为默认的话，你可以创建可选资源文件别名。

注意，不是每一类资源都可以使用别名的。特别的， animation, menu, raw等不提供这个功能。

比如，假设你要使用icon.png，并却要为不同的地区设置不同的版本，然而，两个地区，English-Canadian 和 French-Canadian却是相同的。那么，你就可以使用别名。你可以把图片保存在默认的 res/drawable/ 目录下。然后在res/drawable-en-rCA/和res/drawable-fr-rCA/下创建 icon.xml 文件，使用<bitmap>元素引用该图片。

以下是一些别名的XML文件的实例：

图片文件：
<?xml version="1.0" encoding="utf-8"?>
<bitmap xmlns:android="http://schemas.android.com/apk/res/android"
    android:src="@drawable/icon_ca" />
布局文件：
<?xml version="1.0" encoding="utf-8"?>
<merge>
    <include layout="@layout/main_ltr"/>
</merge>
字符串和其他简单的值：
<?xml version="1.0" encoding="utf-8"?>
<resources>
    <string name="hello">Hello</string>
    <string name="hi">@string/hello</string>
</resources>
<?xml version="1.0" encoding="utf-8"?>
<resources>
    <color name="yellow">#f00</color>
    <color name="highlight">@color/red</color>
</resources>

Configuration	Qualifier Values	Description
MCC - MNC	Examples: `mcc310` `mcc310-mnc004` `mcc208-mnc00` etc.	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. If the device uses a radio connection (GSM phone), the MCC and MNC values come from the SIM card. You can also use the MCC alone (for example, to include country-specific legal resources in your application). If you need to specify based on the language only, then use the language and regionqualifier instead (discussed next). If you decide to use the MCC and MNC qualifier, you should do so with care and test that it works as expected. Also see the configuration fields `mcc`, and `mnc`, which indicate the current mobile country code and mobile network code, respectively.
Language and region	Examples: `en` `fr` `en-rUS` `fr-rFR` `fr-rCA` etc.	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 (preceded by lowercase "`r`"). The codes are not case-sensitive; the `r` prefix is used to distinguish the region portion. You cannot specify a region alone. This can change during the life of your application if the user changes his or her language in the system settings. See Handling Runtime Changes for information about how this can affect your application during runtime. See Localization for a complete guide to localizing your application for other languages. Also see the `locale` configuration field, which indicates the current locale.
smallestWidth	`sw<N>dp` Examples: `sw320dp` `sw600dp` `sw720dp` etc.	The fundamental size of a screen, as indicated by the shortest dimension of the available screen area. Specifically, the device's smallestWidth is the shortest of the screen's available height and width (you may also think of it as the "smallest possible width" for the screen). You can use this qualifier to ensure that, regardless of the screen's current orientation, your application's has at least `<N>`dps of width available for it UI. For example, if your layout requires that its smallest dimension of screen area be at least 600 dp at all times, then you can use this qualifer to create the layout resources, `res/layout-sw600dp/`. The system will use these resources only when the smallest dimension of available screen is at least 600dp, regardless of whether the 600dp side is the user-perceived height or width. The smallestWidth is a fixed screen size characteristic of the device; the device's smallestWidth does not change when the screen's orientation changes. The smallestWidth of a device takes into account screen decorations and system UI. For example, if the device has some persistent UI elements on the screen that account for space along the axis of the smallestWidth, the system declares the smallestWidth to be smaller than the actual screen size, because those are screen pixels not available for your UI. Thus, the value you use should be the actual smallest dimension required by your layout (usually, this value is the "smallest width" that your layout supports, regardless of the screen's current orientation). Some values you might use here for common screen sizes: 320, for devices with screen configurations such as: 240x320 ldpi (QVGA handset) 320x480 mdpi (handset) 480x800 hdpi (high density handset) 480, for screens such as 480x800 mdpi (tablet/handset). 600, for screens such as 600x1024 mdpi (7" tablet). 720, for screens such as 720x1280 mdpi (10" tablet). When your application provides multiple resource directories with different values for the smallestWidth qualifier, the system uses the one closest to (without exceeding) the device's smallestWidth. Added in API level 13. Also see the `android:requiresSmallestWidthDp` attribute, which declares the minimum smallestWidth with which your application is compatible, and the `smallestScreenWidthDp` configuration field, which holds the device's smallestWidth value. For more information about designing for different screens and using this qualifier, see the Supporting Multiple Screens developer guide.
Available width	`w<N>dp` Examples: `w720dp` `w1024dp` etc.	Specifies a minimum available screen width, in `dp` units at which the resource should be used—defined by the `<N>` value. This configuration value will change when the orientation changes between landscape and portrait to match the current actual width. When your application provides multiple resource directories with different values for this configuration, the system uses the one closest to (without exceeding) the device's current screen width. The value here takes into account screen decorations, so if the device has some persistent UI elements on the left or right edge of the display, it uses a value for the width that is smaller than the real screen size, accounting for these UI elements and reducing the application's available space. Added in API level 13. Also see the `screenWidthDp` configuration field, which holds the current screen width. For more information about designing for different screens and using this qualifier, see the Supporting Multiple Screens developer guide.
Available height	`h<N>dp` Examples: `h720dp` `h1024dp` etc.	Specifies a minimum available screen height, in "dp" units at which the resource should be used—defined by the `<N>` value. This configuration value will change when the orientation changes between landscape and portrait to match the current actual height. When your application provides multiple resource directories with different values for this configuration, the system uses the one closest to (without exceeding) the device's current screen height. The value here takes into account screen decorations, so if the device has some persistent UI elements on the top or bottom edge of the display, it uses a value for the height that is smaller than the real screen size, accounting for these UI elements and reducing the application's available space. Screen decorations that are not fixed (such as a phone status bar that can be hidden when full screen) arenot accounted for here, nor are window decorations like the title bar or action bar, so applications must be prepared to deal with a somewhat smaller space than they specify. Added in API level 13. Also see the `screenHeightDp` configuration field, which holds the current screen width. For more information about designing for different screens and using this qualifier, see the Supporting Multiple Screens developer guide.
Screen size	`small` `normal` `large` `xlarge`	`small`: Screens that are of similar size to a low-density QVGA screen. The minimum layout size for a small screen is approximately 320x426 dp units. Examples are QVGA low density and VGA high density. `normal`: Screens that are of similar size to a medium-density HVGA screen. 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`: Screens that are of similar size to a medium-density VGA screen. The minimum layout size for a large screen is approximately 480x640 dp units. Examples are VGA and WVGA medium density screens. `xlarge`: Screens that are considerably larger than the traditional medium-density HVGA screen. The minimum layout size for an xlarge screen is approximately 720x960 dp units. In most cases, devices with extra large screens would be too large to carry in a pocket and would most likely be tablet-style devices. Added in API level 9. Note: Using a size qualifier does not imply that the resources areonly for screens of that size. If you do not provide alternative resources with qualifiers that better match the current device configuration, the system may use whichever resources are thebest match. Caution: If all your resources use a size qualifier that is larger than the current screen, the system will not use them and your application will crash at runtime (for example, if all layout resources are tagged with the `xlarge` qualifier, but the device is a normal-size screen). Added in API level 4. See Supporting Multiple Screens for more information. Also see the `screenLayout` configuration field, which indicates whether the screen is small, normal, or large.
Screen aspect	`long` `notlong`	`long`: Long screens, such as WQVGA, WVGA, FWVGA `notlong`: Not long screens, such as QVGA, HVGA, and VGA Added in API level 4. This is based purely on the aspect ratio of the screen (a "long" screen is wider). This is not related to the screen orientation. Also see the `screenLayout` configuration field, which indicates whether the screen is long.
Screen orientation	`port` `land`	`port`: Device is in portrait orientation (vertical) `land`: Device is in landscape orientation (horizontal) This can change during the life of your application if the user rotates the screen. See Handling Runtime Changes for information about how this affects your application during runtime. Also see the `orientation` configuration field, which indicates the current device orientation.
UI mode	`car` `desk` `television appliance`	`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 Added in API level 8, television added in API 13. This can change during the life of your application if the user places the device in a dock. You can enable or disable some of these modes using `UiModeManager`. See Handling Runtime Changes for information about how this affects your application during runtime.
Night mode	`night` `notnight`	`night`: Night time `notnight`: Day time Added in API level 8. This can change during the life of your application if night mode is left in auto mode (default), in which case the mode changes based on the time of day. You can enable or disable this mode using`UiModeManager`. See Handling Runtime Changes for information about how this affects your application during runtime.
Screen pixel density (dpi)	`ldpi` `mdpi` `hdpi` `xhdpi` `nodpi` `tvdpi`	`ldpi`: Low-density screens; approximately 120dpi. `mdpi`: Medium-density (on traditional HVGA) screens; approximately 160dpi. `hdpi`: High-density screens; approximately 240dpi. `xhdpi`: Extra high-density screens; approximately 320dpi. Added in API Level 8 `nodpi`: This can be used for bitmap resources that you do not want to be scaled to match the device density. `tvdpi`: Screens somewhere between mdpi and hdpi; approximately 213dpi. This is not considered a "primary" density group. It is mostly intended for televisions and most apps shouldn't need it—providing mdpi and hdpi resources is sufficient for most apps and the system will scale them as appropriate. This qualifier was introduced with API level 13. There is a 3:4:6:8 scaling ratio between the four primary densities (ignoring the tvdpi density). So, a 9x9 bitmap in ldpi is 12x12 in mdpi, 18x18 in hdpi and 24x24 in xhdpi. If you decide that your image resources don't look good enough on a television or other certain devices and want to try tvdpi resources, the scaling factor is 1.33mdpi. For example, a 100px x 100px image for mdpi screens should be 133px x 133px for tvdpi. Note:* Using a density qualifier does not imply that the resources are only for screens of that density. If you do not provide alternative resources with qualifiers that better match the current device configuration, the system may use whichever resources are the best match. See Supporting Multiple Screens for more information about how to handle different screen densities and how Android might scale your bitmaps to fit the current density.
Touchscreen type	`notouch` `finger`	`notouch`: Device does not have a touchscreen. `finger`: Device has a touchscreen that is intended to be used through direction interaction of the user's finger. Also see the `touchscreen` configuration field, which indicates the type of touchscreen on the device.
Keyboard availability	`keysexposed` `keyshidden` `keyssoft`	`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 is not 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. `keyshidden`: Device has a hardware keyboard available but it is hidden and the device does not have a software keyboard enabled. `keyssoft`: Device has a software keyboard enabled, whether it's visible or not. If you provide `keysexposed` resources, but not `keyssoft` resources, the system uses the `keysexposed` resources regardless of whether a keyboard is visible, as long as the system has a software keyboard enabled. This can change during the life of your application if the user opens a hardware keyboard. See Handling Runtime Changes for information about how this affects your application during runtime. Also see the configuration fields `hardKeyboardHidden` and`keyboardHidden`, which indicate the visibility of a hardware keyboard and and the visibility of any kind of keyboard (including software), respectively.
Primary text input method	`nokeys` `qwerty` `12key`	`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. Also see the `keyboard` configuration field, which indicates the primary text input method available.
Navigation key availability	`navexposed` `navhidden`	`navexposed`: Navigation keys are available to the user. `navhidden`: Navigation keys are not available (such as behind a closed lid). This can change during the life of your application if the user reveals the navigation keys. See Handling Runtime Changes for information about how this affects your application during runtime. Also see the `navigationHidden` configuration field, which indicates whether navigation keys are hidden.
Primary non-touch navigation method	`nonav` `dpad` `trackball` `wheel`	`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). Also see the `navigation` configuration field, which indicates the type of navigation method available.
Platform Version (API level)	Examples: `v3` `v4` `v7` etc.	The API level supported by the device. For example, `v1` for API level 1 (devices with Android 1.0 or higher) and `v4` for API level 4 (devices with Android 1.6 or higher). See the Android API levels document for more information about these values. Caution: Android 1.5 and 1.6 only match resources with this qualifier when it exactly matches the platform version. See the section below about Known Issues for more information.

=================================================================================================================================================

三.访问资源：

1.当你为应用提供了资源文件吗，你可以通过资源ID来引用。所有的资源ID都在项目下的R.class文件下，有aapt工具自动生成。

2.每一类资源都有一个对应的R子类，如R.drawable。每一类资源的每一个资源都有一个静态整数，如R.drawable.icon，这个整数就是资源ID，你可以用来检索你的资源一个资源ID通常组成如下：

资源类型：每一个资源都被分类到一个类型中，如string, drawable和layout 。
资源名：是文件名，排除路径；如果这个资源是一个简单的值的话，如字符串，则也可以是XML文件中属性的值，如android:name；

3.访问资源丫头两种方式：

在代码中：使用一个R.class文件中的子类中的静态整数，如 R.string.hello。
在XML中：使用一个特定的XML语法，如@string/hello

4.访问平台资源：

Android包含许多标准资源，如 styles, themes, 和 layouts 。要访问这些资源，用android 包名限定你的资源引用。如，Android系统了一个布局资源，你可以用来ListAdapter中的list items：其中 simple_list_item_1是平台定义的布局文件

setListAdapter(new ArrayAdapter<String>(this, android.R.layout.simple_list_item_1, myarray));

应用程序资源