リソースの提供

ビットマップ ファイル（.png、.9.png、.jpg、.gif）または次のドローアブル リソース サブタイプにコンパイルされる XML ファイル:

• ビットマップ ファイル
• 9-patch（リサイズ可能なビットマップ）
• 状態リスト
• 形状
• アニメーション ドローアブル
• その他のドローアブル

ドローアブル リソースをご覧ください。

未加工の形式で保存する任意のファイル。これらのリソースを未加工の InputStream で開くには、リソース ID（R.raw.filename）を指定して Resources.openRawResource() を呼び出します。

ただし、元のファイル名とファイル階層にアクセスする必要がある場合は、一部のリソースを assets/ ディレクトリ（res/raw/ の代わりに）に保存することを検討してください。 assets/ のファイルにはリソース ID が付与されていないため、読み取りには AssetManager が必要です。

文字列、整数、色など、単純な値を含む XML ファイル。

その他の res/ サブディレクトリの XML リソース ファイルは XML ファイル名に基づいて 1 つのリソースを定義しますが、values/ ディレクトリのファイルは複数のリソースを表します。このディレクトリのファイルの場合、<resources> 要素の子がそれぞれ 1 つのリソースを定義します。 たとえば、<string> 要素は R.string リソースを生成し、<color> 要素は R.color リソースを生成します。

各リソースの定義には XML 要素を使用するため、ファイルには任意の名前を設定でき、1 つのファイル内にさまざまなリソースを配置できます。 ただし、わかりやすくするために、一意のリソースタイプをそれぞれのファイルに配置することもできます。 次は、このディレクトリで作成できるリソースのファイル名の変換例です。

• リソースの配列の場合 arrays.xml（型付き配列）。
• 色の値の場合 colors.xml
• 寸法の値の場合 dimens.xml。
• 文字列の値の場合 strings.xml。
• スタイルの場合 styles.xml。

文字列リソース、スタイル リソース、その他のリソース タイプをご覧ください。

モバイル カントリーコード（MCC）です。端末の SIM カードにあるモバイル ネットワーク コード（MNC）が続くことがあります。 たとえば、mcc310 は米国の任意の携帯通信会社、mcc310-mnc004 は米国の Verizon、mcc208-mnc00 はフランスの Orange となります。

端末が無線通信接続（GSM 電話）を使用する場合、MCC と MNC の値は SIM カードの値となります。

さらに、MCC のみを使用することもできます（たとえば、アプリケーションに国固有の法に関するリソースを含める場合）。 言語のみに基づいて指定する場合は、代わりに言語と地域の修飾子（次のセクションで解説）を使用します。 MCC と MNC 修飾子を使用する場合は、慎重に設定し、予測のとおりに機能することをテストします。

さらに、設定フィールド mcc、mnc もご覧ください。これらは、それぞれ、現在のモバイル カントリーコードとモバイル ネットワーク コードを表します。

言語は 2 文字の ISO 639-1 言語コードで定義し、オプションで、2 文字の ISO 3166-1-alpha-2 地域コードを後ろに追加します（前に小文字の「r」を付けます）。

コードでは大文字と小文字が区別されません。地域を区別するには、r 接頭辞を使用します。 地域のみは指定できません。

ユーザーがシステム設定で言語を変更すると、アプリケーションの実行中にこの値が変更されます。 実行時のアプリケーションに与える影響については、実行時の変更の処理をご覧ください。

アプリケーションを他の言語にローカライズするための詳細なガイドは、ローカライズをご覧ください。

さらに、locale 設定フィールドもご覧ください。これは、現在のロケールを表します。

アプリケーションのレイアウトの方向です。ldrtl は、「レイアウト方向は右から左」という意味になります。ldltr は、「レイアウト方向は左から右」という意味で、こちらの設定が暗黙的にデフォルト値になります。

この設定は、レイアウト、ドローアブル、値など、任意のリソースに適用できます。

たとえば、アラビア語に何らかの特定なレイアウトを提供し、その他の「右から左」の言語（ペルシャ語やヘブライ語）に汎用的なレイアウトを提供する場合、次のように設定します。

res/
    layout/   
        main.xml  (Default layout)
    layout-ar/  
        main.xml  (Specific layout for Arabic)
    layout-ldrtl/  
        main.xml  (Any "right-to-left" language, except
                  for Arabic, because the "ar" language qualifier
                  has a higher precedence.)

注: アプリで右から左のレイアウト機能を有効にするには、supportsRtl を "true" に設定し、targetSdkVersion を 17 以上に設定します。

API レベル 17 で追加。

使用可能な画面領域の最小寸法で指定する、画面の基本サイズ。 具体的には、端末の smallestWidth は画面に使用できる高さと幅の最小サイズとなります（画面の「使用できる最小幅」と考えることもできます）。 画面の現在の向きに関係なく、この修飾子を使用することで、アプリケーションの UI に少なくとも <N> dps の幅を使用できます。

たとえば、画面領域のレイアウトの最小寸法を常に 600 dp とする必要がある場合、この修飾子を使用してレイアウト リソース res/layout-sw600dp/ を作成できます。 システムは、600dp の側が縦になるか横になるか関係なく、使用可能な画面の最小寸法が 600dp 以上の場合にのみこれらのリソースを使用します。 smallestWidth は端末の固定された画面サイズ特性です。画面の向きが変わっても、端末の smallestWidth は変更されません。

端末の smallestWidth では画面の装飾とシステム UI が考慮されます。たとえば、端末の画面に smallestWidth の軸に沿ったスペースを考慮した固定 UI 要素がある場合、これらの画面ピクセルは UI に使用できないため、システムは実際の画面サイズよりも小さな smallestWidth を宣言します。 つまり、使用する値は、レイアウトが必要とする実際の最小寸法にする必要があります（通常は、この値は、画面の現在の向きに関係なく、レイアウトがサポートする「最小幅」になります）。

次に、一般的な画面サイズに使用する値を示します。

• 320。次のような画面設定を持つ端末。
  • 240x320 ldpi（QVGA ハンドセット）
  • 320x480 mdpi（ハンドセット）
  • 480x800 hdpi（高密度ハンドセット）
• 480。480x800 mdpi（タブレットやハンドセット）などの画面。
• 600。600x1024 mdpi（7 インチタブレット）などの画面。
• 720。720x1280 mdpi（10 インチタブレット）などの画面。

アプリケーションで smallestWidth 修飾子の値が異なる複数のリソース ディレクトリを提供する場合、システムは端末の smallestWidth に最も近い（かつ超過しない）ものを使用します。

API レベル 13 で追加。

さらに、android:requiresSmallestWidthDp 属性もご覧ください。これは、アプリケーションが互換性を持つ最小の smallestWidth と、端末の smallestWidth 値を保持する smallestScreenWidthDp 設定フィールドを宣言します。

さまざまな画面の設計とこの修飾子の使用方法についての詳細は、複数画面をサポートするのデベロッパー ガイドをご覧ください。

リソースに使用する、使用可能な最小の画面幅を dp 単位で指定します。<N> の値で定義します。 画面の向きの縦と横を変更すると、現在の実際の幅に合わせて、この設定値が変更されます。

アプリケーションでこの設定が異なる複数のリソース ディレクトリを提供する場合、システムは端末の現在の画面の幅に最も近い（かつ超過しない）ものを使用します。 この値は画面の装飾を考慮します。つまり、端末のディスプレイの左や右に何らかの固定 UI 要素がある場合、これらの UI 要素を考慮し、アプリケーションの使用可能なスペースを減らして、実際の画面サイズよりも小さな幅を使用します。

API レベル 13 で追加。

さらに、screenWidthDp 設定フィールドもご覧ください。これは現在の画面の幅を保持します。

さまざまな画面の設計とこの修飾子の使用方法についての詳細は、複数画面をサポートするのデベロッパー ガイドをご覧ください。

リソースを使用する、使用可能な最小の画面幅を「dp」単位で指定します。—<N> の値で定義します。 画面の向きの縦と横を変更すると、現在の実際の高さに合わせて、この設定値が変更されます。

アプリケーションでこの設定が異なる複数のリソース ディレクトリを提供する場合、システムは端末の現在の画面の高さに最も近い（かつ超過しない）ものを使用します。 この値は画面の装飾を考慮します。つまり、端末のディスプレイの上や下に何らかの固定 UI 要素がある場合、これらの UI 要素を考慮し、アプリケーションの使用可能なスペースを減らして、実際の画面サイズよりも小さな高さを使用します。 固定されていない画面の装飾（全画面にした場合に非表示になる携帯電話のステータスバーなど）や、タイトルバーやアクションバーなどのウィンドウの装飾は、ここでは考慮されません。そのため、アプリケーションでは指定したスペースよりもやや小さなサイズに対処できるように準備をし置く必要があります。

API レベル 13 で追加。

さらに、screenHeightDp 設定フィールドもご覧ください。これは現在の画面の幅を保持します。

さまざまな画面の設計とこの修飾子の使用方法についての詳細は、複数画面をサポートするのデベロッパー ガイドをご覧ください。

• small:低密度 QVGA 画面と同等のサイズを持つ画面です。 小さい画面の最小レイアウト サイズは約 320x426 dp 単位です。 たとえば、QVGA 低密度や VGA 高密度です。
• normal:中密度 HVGA 画面と同等のサイズを持つ画面です。 通常の画面の最小レイアウト サイズは約 320x470 dp 単位です。 たとえば、WQVGA 低密度、HVGA 中密度、WVGA 高密度といった画面になります。
• large:中密度 VGA 画面と同等のサイズを持つ画面です。 大きな画面の最小レイアウト サイズは約 480x640 dp 単位です。 たとえば、VGA や WVGA の中密度といった画面です。
• xlarge:従来の中密度 HVGA 画面よりもはるかに大きなサイズの画面です。 特大の画面の最小レイアウト サイズは約 720x960 dp 単位です。 ほとんどの場合、特大の画面を持つ端末はポケットに入れて持ち運ぶことができないほど大きく、タブレット スタイルの端末になります。 API レベル 9 で追加。

注: サイズ識別子を持つ場合でも、リソースがそのサイズの画面以外には対応しないということではありません。 現在の端末に最適な識別子を持つ代替リソースを提供していない場合でも、システムによって最適なリソースが使用されることがあります。

警告: すべてのリソースが現在の画面よりも大きなサイズ識別子を使用している場合、システムはそれらのリソースを使用せず、アプリケーションは実行時にクラッシュしてしまいます（たとえば、すべてのリソースに xlarge 識別子のタグが付いているが、端末は通常サイズの画面である場合）。

API レベル 4 で追加。

詳細については、複数画面をサポートするをご覧ください。

さらに、screenLayout 設定フィールドもご覧ください。これは、画面のサイズが小、中、大のいずれかであるかを表します。

• long:WQVGA、WVGA、FWVGA のような長い画面
• notlong:QVGA、HVGA、VGA のように長くない画面

API レベル 4 で追加。

これは純粋に画面のアスペクト比を基準とします（「長い」画面は幅広の画面になります）。これは画面の向きには関係ありません。

さらに、screenLayout 設定フィールドもご覧ください。これは、画面のサイズが長いかどうかを表します。

• round:ウェアラブル端末のような円形の画面
• notround:スマートフォンやタブレットのような長方形の画面

API レベル 23 で追加。

さらに、isScreenRound() 設定メソッドで、画面の形状が円形かどうかを確認します。

• port:端末は縦向き（垂直）になっています
• land:端末は横向き（水平）になっています

ユーザーが画面を回転すると、アプリケーションの実行中にこの値が変更されます。 実行時のアプリケーションに与える影響については、実行時の変更の処理をご覧ください。

さらに、orientation 設定フィールドもご覧ください。これは、現在の端末の画面の向きを表します。

• car:端末は車載ドックで表示されています
• desk:端末はデスクドックで表示されています
• television:端末はテレビで表示されており、「10 フィート」離れた位置からの操作が可能です。UI はユーザーから離れた場所にある大きな画面に表示され、主に十字キーやポインタ以外のやり取りで操作します。
• appliance:端末をアプライアンスとして使用します。ディスプレイはありません
• watch:端末にはディスプレイがあり、手首に装着して使用します

API レベル 8 で追加。television は API 13 で追加。watch は API 20 で追加。

端末をホルダーに装着したり、取り外したりしたときのアプリの反応については、装着状態とホルダータイプを特定および監視するをご覧ください。

ユーザーが端末をドックに装着すると、アプリケーションの実行中にこの値が変更されます。 UiModeManager を使用すると、これらのモードの一部を有効または無効にできます。実行時のアプリケーションに与える影響については、実行時の変更の処理をご覧ください。

• night: 夜間
• notnight: 昼間

API レベル 8 で追加。

ナイトモードを自動モード（デフォルト）のままにしておくと、時間を基準にしてモードが変更された場合に、アプリケーションの実行中にこの値が変更されます。 UiModeManager を使用すると、このモードを有効または無効にできます。 実行時のアプリケーションに与える影響については、実行時の変更の処理をご覧ください。

• ldpi:低密度の画面。約 120dpi です。
• mdpi:中密度（従来の HVGA）の画面。約 160dpi です。
• hdpi:高密度の画面。約 240dpi です。
• xhdpi:超高密度の画面。約 320dpi です。API レベル 8 で追加。
• xxhdpi:超超高密度の画面。約 480dpi です。API レベル 16 で追加。
• xxxhdpi:超超高密度が使用（ランチャー アイコンのみ。「Supporting Multiple Screens」の注をご覧ください）。約 640dpi です。 API レベル 18 で追加。
• nodpi:端末の密度に合わせてサイズを変更しないビットマップ リソースに使用します。
• tvdpi:密度が mdpi と hdpi の間の画面。約 213dpi です。これは「プライマリ」の密度グループとしては認識されません。 ほとんどの場合、テレビ向けのものであり、大部分のアプリは必要としません。—通常、アプリの場合は mdpi と hdpi リソースを提供すれば十分であり、システムが必要に応じてサイズを変更します。 API レベル 13 で追加。
• anydpi:この修飾子はどんな画面密度にも適しており、ほかの修飾子よりも優先されます。 これはベクター型ドローアブルの場合に便利です。API レベル 21で追加。

6 つのプライマリ密度のサイズの比率は 3:4:6:8:12:16 です（tvdpi 密度を除く）。 そのため、ldpi では 9x9 のビットマップ、mdpi では 12x12 のビットマップ、hdpi では 18x18 のビットマップ、xhdpi では 24x24 のビットマップとなります。

画像リソースがテレビや他の特定の端末で正常に表示されず、tvdpi リソースを試す場合、拡張係数は 1.33*mdpi になります。 たとえば、画面向けの 100px x 100px 画像は、tvdpi 向けにすると 133px x 133px となります。

注: 密度識別子を持つ場合でも、リソースがその密度の画面以外には対応しないということではありません。 現在の端末に最適な識別子を持つ代替リソースを提供していない場合でも、システムによって最適なリソースが使用されることがあります。

異なる画面密度を処理する方法や、Android が現在の密度に合わせてビットマップのサイズを変更する方法については、複数画面をサポートするをご覧ください。

• notouch:端末にはタッチスクリーンが搭載されていません。
• finger:端末には、ユーザーの指先による指示操作で使用するためのタッチスクリーンが搭載されています。

touchscreen 設定フィールドもご覧ください。これは、端末上のタッチスクリーンのタイプを表します。

• keysexposed:端末ではキーボードを使用できます。端末でソフトウェア キーボードが有効な（と想定される）場合、端末にハードウェア キーボードが接続されておらず、ハードウェア キーボードがユーザーに提示されていない場合でも、この値が使用されることがあります。 ソフトウェア キーボードが提供されていない、または無効になっている場合は、ハードウェア キーボードが認識された場合にのみ使用されます。
• keyshidden:端末には使用可能なハードウェア キーボードがありますが非表示になっています。また、端末ではソフトウェア キーボードが有効になっていません。
• keyssoft:表示されているかどうかに関係なく、端末ではソフトウェア キーボードが有効になっています。

keysexposed リソースを提供するが、keyssoft リソースを提供しない場合、システムのソフトウェア キーボードが有効になっている場合は、キーボードが表示されているかに関係なく、システムは keysexposed リソースを使用します。

ユーザーがハードウェア キーボードを開くと、アプリケーションの実行中にこの値が変更されます。 実行時のアプリケーションに与える影響については、実行時の変更の処理をご覧ください。

さらに、設定フィールド hardKeyboardHidden と keyboardHidden もご覧ください。それぞれ、ハードウェア キーボードと、任意のキーボード（ソフトウェアを含む）の可視性を表します。

• nokeys:端末にはテキスト入力用のハードウェア キーはありません。
• qwerty:ユーザーに表示されているかどうかに関係なく、端末にはハードウェア クワーティ キーボードが搭載されています。
• 12key:ユーザーに表示されているかどうかに関係なく、端末にはハードウェア 12key キーボードが搭載されています。

さらに、keyboard 設定フィールドもご覧ください。これは、使用可能な主なテキストの入力方法を表します。

• navexposed:ユーザーはナビゲーション キーを使用できます。
• navhidden:ナビゲーション キーは使用できません（閉じられた lid の背後になっている場合など）。

ユーザーがナビゲーション キーを表示させると、アプリケーションの実行中にこの値が変更されます。 実行時のアプリケーションに与える影響については、実行時の変更の処理をご覧ください。

さらに、navigationHidden 設定フィールドもご覧ください。これは、ナビゲーション キーが非表示になっているかどうかを表します。

• nonav:端末には、タッチスクリーン以外のナビゲーション機能がありません。
• dpad:端末にはナビゲーション用の方向キー（十字キー）があります。
• trackball:端末にはナビゲーション用のトラックボールがあります。
• wheel:端末にはナビゲーション用の方向ホイールがあります（特殊）。

navigation 設定フィールドもご覧ください。これは、利用可能なナビゲーション方法のタイプを表します。

端末がサポートする API レベル。たとえば、v1 は API レベル 1（Android 1.0 以降の端末）、v4 は API レベル 4（Android 1.6 以降の端末）となります。 これらの値の詳細については、Android API levels のドキュメントをご覧ください。