مروری بر منابع برنامه

منابع، فایل‌های اضافی و محتوای استاتیکی هستند که کد شما از آنها استفاده می‌کند، مانند بیت‌مپ‌ها، تعاریف طرح‌بندی، رشته‌های رابط کاربری، دستورالعمل‌های انیمیشن و موارد دیگر.

همیشه منابع برنامه مانند تصاویر و رشته‌ها را از کد خود خارجی کنید تا بتوانید آنها را به طور مستقل نگهداری کنید. همچنین، با گروه‌بندی آنها در دایرکتوری‌های منابع با نام‌های خاص، منابع جایگزین برای پیکربندی‌های خاص دستگاه فراهم کنید. در زمان اجرا، اندروید از منبع مناسب بر اساس پیکربندی فعلی استفاده می‌کند. به عنوان مثال، ممکن است بخواهید بسته به اندازه صفحه نمایش، طرح‌بندی رابط کاربری متفاوتی ارائه دهید یا بسته به تنظیمات زبان، رشته‌های متفاوتی ارائه دهید.

پس از اینکه منابع برنامه خود را خارجی‌سازی کردید، می‌توانید با استفاده از شناسه‌های منبع که در کلاس R پروژه شما تولید می‌شوند، به آنها دسترسی داشته باشید. این سند به شما نشان می‌دهد که چگونه منابع را در پروژه اندروید خود گروه‌بندی کنید. همچنین به شما نشان می‌دهد که چگونه منابع جایگزین را برای پیکربندی‌های خاص دستگاه فراهم کنید و سپس از کد برنامه یا سایر فایل‌های XML خود به آنها دسترسی پیدا کنید.

انواع منابع گروهی

هر نوع منبع را در یک زیرشاخه خاص از دایرکتوری res/ پروژه خود قرار دهید. برای مثال، در اینجا سلسله مراتب فایل برای یک پروژه ساده آمده است:

MyProject/
    src/
        MyActivity.java
    res/
        drawable/
            graphic.png
        layout/
            main.xml
            info.xml
        mipmap/
            icon.png
        values/
            strings.xml

دایرکتوری res/ شامل تمام منابع موجود در زیرشاخه‌های خود است: یک منبع تصویر، دو منبع طرح‌بندی، یک دایرکتوری mipmap/ برای آیکون‌های لانچر و یک فایل منبع رشته‌ای. نام‌های دایرکتوری منابع مهم هستند و در جدول ۱ توضیح داده شده‌اند.

نکته: برای اطلاعات بیشتر در مورد استفاده از پوشه‌های mipmap، به بخش «قرار دادن آیکون‌های برنامه در دایرکتوری‌های mipmap» مراجعه کنید.

جدول ۱. دایرکتوری‌های منابع پشتیبانی‌شده در دایرکتوری res/ پروژه.

دایرکتوری نوع منبع
animator/ فایل‌های XML که انیمیشن‌های Property را تعریف می‌کنند.
anim/ فایل‌های XML که انیمیشن‌های Tween را تعریف می‌کنند. انیمیشن‌های property نیز می‌توانند در این دایرکتوری ذخیره شوند، اما دایرکتوری animator/ برای انیمیشن‌های property ترجیح داده می‌شود تا بین این دو نوع تمایز قائل شود.
color/ فایل‌های XML که فهرستی از رنگ‌ها را تعریف می‌کنند. برای اطلاعات بیشتر، به منبع فهرست وضعیت رنگ مراجعه کنید.
drawable/

فایل‌های بیت‌مپ (PNG، .9.png ، JPG یا GIF) یا فایل‌های XML که به زیرگروه‌های منابع ترسیمی زیر کامپایل می‌شوند:

  • فایل‌های بیت‌مپ
  • نه وصله (بیت‌مپ‌های قابل تغییر اندازه)
  • فهرست‌های ایالتی
  • اشکال
  • انیمیشن‌های قابل ترسیم
  • سایر فایل‌های قابل ترسیم

برای اطلاعات بیشتر، به منابع Drawable مراجعه کنید.

mipmap/ فایل‌های قابل ترسیم برای تراکم‌های مختلف آیکون‌های لانچر. برای اطلاعات بیشتر در مورد مدیریت آیکون‌های لانچر با پوشه‌های mipmap/ ، به بخش «قرار دادن آیکون‌های برنامه در دایرکتوری‌های mipmap» مراجعه کنید.
layout/ فایل‌های XML که طرح‌بندی رابط کاربری را تعریف می‌کنند. برای اطلاعات بیشتر، به منبع طرح‌بندی مراجعه کنید.
menu/ فایل‌های XML که منوهای برنامه، مانند منوی گزینه‌ها، منوی زمینه یا زیرمنو را تعریف می‌کنند. برای اطلاعات بیشتر، به منبع منو مراجعه کنید.
raw/

فایل‌های دلخواه برای ذخیره به شکل خام خود. برای باز کردن این منابع با یک InputStream خام، تابع Resources.openRawResource() را با شناسه منبع که R.raw. filename است، فراخوانی کنید.

با این حال، اگر به دسترسی به نام اصلی فایل‌ها و سلسله مراتب فایل‌ها نیاز دارید، ذخیره منابع در دایرکتوری assets/ را به جای res/raw/ در نظر بگیرید. فایل‌های موجود در assets/ شناسه منبع ندارند، بنابراین فقط می‌توانید آن‌ها را با استفاده از AssetManager بخوانید.

values/

فایل‌های XML که حاوی مقادیر ساده‌ای مانند رشته‌ها، اعداد صحیح و رنگ‌ها هستند.

در حالی که فایل‌های منبع XML در سایر زیرشاخه‌های res/ یک منبع واحد را بر اساس نام فایل XML تعریف می‌کنند، فایل‌های موجود در پوشه values/ چندین منبع را توصیف می‌کنند. برای یک فایل در این پوشه، هر فرزند عنصر <resources> یک منبع واحد را تعریف می‌کند. به عنوان مثال، یک عنصر <string> یک منبع R.string ایجاد می‌کند و یک عنصر <color> یک منبع R.color ایجاد می‌کند.

از آنجا که هر منبع با عنصر XML مخصوص به خود تعریف می‌شود، می‌توانید نام فایل را هر چه می‌خواهید بگذارید و انواع مختلف منابع را در یک فایل قرار دهید. با این حال، برای وضوح بیشتر، ممکن است بخواهید انواع منابع منحصر به فرد را در فایل‌های مختلف قرار دهید. برای مثال، در اینجا برخی از قراردادهای نام فایل برای منابعی که می‌توانید در این دایرکتوری ایجاد کنید، آورده شده است:

برای اطلاعات بیشتر، به منابع رشته‌ای ، منابع سبک و انواع منابع بیشتر مراجعه کنید.

xml/ فایل‌های XML دلخواه که می‌توانند در زمان اجرا با فراخوانی Resources.getXML() خوانده شوند. فایل‌های پیکربندی XML مختلفی باید در اینجا ذخیره شوند، مانند پیکربندی جستجو .
font/ فایل‌های فونت با پسوندهایی مانند TTF، OTF یا TTC، یا فایل‌های XML که شامل عنصر <font-family> هستند. برای اطلاعات بیشتر در مورد فونت‌ها به عنوان منابع، به بخش افزودن فونت به عنوان منبع XML مراجعه کنید.

هشدار: هرگز فایل‌های منبع را مستقیماً درون پوشه res/ ذخیره نکنید. این کار باعث خطای کامپایلر می‌شود.

برای اطلاعات بیشتر در مورد انواع منابع، به نمای کلی انواع منابع مراجعه کنید.

منابعی که در زیرشاخه‌های تعریف‌شده در جدول ۱ ذخیره می‌کنید، منابع پیش‌فرض شما هستند. یعنی این منابع، طراحی و محتوای پیش‌فرض برنامه شما را تعریف می‌کنند. با این حال، انواع مختلف دستگاه‌های اندروید ممکن است به انواع مختلفی از منابع نیاز داشته باشند.

برای مثال، می‌توانید منابع طرح‌بندی متفاوتی را برای دستگاه‌هایی که صفحه نمایش بزرگتری نسبت به حالت عادی دارند، فراهم کنید تا از فضای اضافی صفحه نمایش بهره‌مند شوید. همچنین می‌توانید منابع رشته‌ای مختلفی را ارائه دهید که متن رابط کاربری شما را بر اساس تنظیمات زبان دستگاه ترجمه می‌کنند. برای ارائه این منابع مختلف برای پیکربندی‌های مختلف دستگاه، باید علاوه بر منابع پیش‌فرض خود، منابع جایگزینی نیز ارائه دهید.

منابع جایگزین ارائه دهید

اکثر برنامه‌ها منابع جایگزینی را برای پشتیبانی از پیکربندی‌های خاص دستگاه ارائه می‌دهند. به عنوان مثال، منابع ترسیمی جایگزین را برای تراکم‌های مختلف صفحه نمایش و منابع رشته‌ای جایگزین را برای زبان‌های مختلف در نظر بگیرید. در زمان اجرا، اندروید پیکربندی فعلی دستگاه را تشخیص داده و منابع مناسب را برای برنامه شما بارگذاری می‌کند.

شکل ۱. دو دستگاه که از منابع طرح‌بندی متفاوت بر اساس اندازه صفحه نمایش استفاده می‌کنند.

برای مشخص کردن گزینه‌های خاص پیکربندی برای مجموعه‌ای از منابع، موارد زیر را انجام دهید:

  1. یک دایرکتوری جدید در res/ ایجاد کنید که به شکل <resources_name> - <qualifier> نامگذاری شده باشد.
    • <resources_name> نام دایرکتوری منابع پیش‌فرض مربوطه است (که در جدول ۱ تعریف شده است).
    • <qualifier> نامی است که پیکربندی منحصر به فردی را که این منابع برای آن استفاده می‌شوند، مشخص می‌کند (تعریف شده در جدول 2).

    می‌توانید بیش از یک <qualifier> اضافه کنید. هر کدام را با یک خط تیره از هم جدا کنید.

    احتیاط: هنگام افزودن چندین توصیف‌کننده، باید آنها را به همان ترتیبی که در جدول ۲ فهرست شده‌اند، قرار دهید. اگر توصیف‌کننده‌ها به طور نادرست مرتب شده باشند، منابع نادیده گرفته می‌شوند.

  2. منابع جایگزین مناسب را در این دایرکتوری جدید ذخیره کنید. فایل‌های منبع باید دقیقاً مشابه فایل‌های منبع پیش‌فرض نامگذاری شوند.

برای مثال، در اینجا برخی از منابع پیش‌فرض و جایگزین آورده شده است:

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

توصیف‌کننده hdpi نشان می‌دهد که منابع موجود در آن دایرکتوری برای دستگاه‌هایی با صفحه نمایش با تراکم بالا هستند. تصاویر موجود در این دایرکتوری‌های drawable برای تراکم‌های صفحه نمایش خاص اندازه‌گذاری شده‌اند، اما نام فایل‌ها دقیقاً یکسان هستند. به این ترتیب، شناسه منبعی که برای ارجاع به تصویر icon.png یا background.png استفاده می‌کنید، همیشه یکسان است. اندروید با مقایسه اطلاعات پیکربندی دستگاه با توصیف‌کننده‌های موجود در نام دایرکتوری منابع، نسخه‌ای از هر منبع را که به بهترین وجه با دستگاه فعلی مطابقت دارد، انتخاب می‌کند.

احتیاط: هنگام تعریف یک منبع جایگزین، مطمئن شوید که آن منبع را در پیکربندی پیش‌فرض نیز تعریف کرده‌اید. در غیر این صورت، برنامه شما ممکن است هنگام تغییر پیکربندی توسط دستگاه با استثنائات زمان اجرا مواجه شود. به عنوان مثال، اگر یک رشته فقط به values-en و نه values ​​اضافه کنید، برنامه شما ممکن است هنگام تغییر زبان پیش‌فرض سیستم توسط کاربر با استثنای Resource Not Found مواجه شود.

جدول ۲ توصیف‌کننده‌های پیکربندی معتبر را به ترتیب اولویت فهرست می‌کند. می‌توانید با جدا کردن هر توصیف‌کننده با خط تیره، چندین توصیف‌کننده را به نام یک دایرکتوری اضافه کنید. اگر از چندین توصیف‌کننده برای یک دایرکتوری منابع استفاده می‌کنید، باید آنها را به ترتیبی که در جدول فهرست شده‌اند، به نام دایرکتوری اضافه کنید.

جدول ۲. نام‌های توصیف‌کننده پیکربندی.

پیکربندی مقادیر واجد شرایط توضیحات
MCC و MNC مثال‌ها:
mcc310
mcc310-mnc004
mcc208-mnc00

کد کشور تلفن همراه (MCC)، که به صورت اختیاری با کد شبکه تلفن همراه (MNC) از سیم کارت موجود در دستگاه دنبال می‌شود. به عنوان مثال، mcc310 در هر اپراتوری مربوط به ایالات متحده است، mcc310-mnc004 در Verizon مربوط به ایالات متحده است و mcc208-mnc00 در Orange مربوط به فرانسه است.

اگر دستگاه از اتصال رادیویی استفاده می‌کند (یعنی یک تلفن GSM است)، مقادیر MCC و MNC از سیم کارت می‌آیند.

همچنین می‌توانید به تنهایی از MCC استفاده کنید، برای مثال، برای گنجاندن منابع حقوقی خاص کشور در برنامه خود. اگر نیاز دارید که فقط بر اساس زبان مشخص کنید، به جای آن از توصیف‌کننده زبان، خط (اختیاری) و منطقه (اختیاری) استفاده کنید. اگر از توصیف‌کننده MCC و MNC استفاده می‌کنید، این کار را با دقت انجام دهید و آزمایش کنید که مطابق انتظار کار کند.

همچنین به فیلدهای پیکربندی mcc و mnc مراجعه کنید که به ترتیب کد کشور موبایل و کد شبکه موبایل فعلی را نشان می‌دهند.

زبان، خط (اختیاری) و منطقه (اختیاری) مثال‌ها:
en
fr
en-rUS
fr-rFR
fr-rCA
b+en
b+en+US
b+es+419
b+zh+Hant
b+sr+Latn+RS

این زبان با یک کد زبان دو حرفی ISO 639-1 تعریف می‌شود که به صورت اختیاری با یک کد منطقه دو حرفی ISO 3166-1-alpha-2 (که قبل از آن r کوچک قرار می‌گیرد) دنبال می‌شود.

کدها به حروف کوچک و بزرگ حساس نیستند . پیشوند r برای تمایز بخش منطقه استفاده می‌شود. شما نمی‌توانید فقط یک منطقه را مشخص کنید.

اندروید ۷.۰ (سطح API ۲۴) پشتیبانی از برچسب‌های زبانی BCP 47 را معرفی کرد که می‌توانید از آن‌ها برای تعیین صلاحیت منابع خاص زبان و منطقه استفاده کنید. یک برچسب زبانی از دنباله‌ای از یک یا چند زیربرچسب تشکیل شده است که هر کدام از آن‌ها دامنه زبان شناسایی شده توسط برچسب کلی را اصلاح یا محدود می‌کنند. برای اطلاعات بیشتر در مورد برچسب‌های زبانی، به برچسب‌های شناسایی زبان‌ها مراجعه کنید.

برای استفاده از یک برچسب زبان BCP 47، b+ و یک کد زبان دو حرفی ISO 639-1 را به هم متصل کنید، که به صورت اختیاری با زیربرچسب‌های اضافی که با + از هم جدا شده‌اند، دنبال می‌شود.

اگر کاربران زبان خود را در تنظیمات سیستم تغییر دهند، برچسب زبان می‌تواند در طول عمر برنامه شما تغییر کند. برای اطلاعات بیشتر در مورد چگونگی تأثیر این موضوع بر برنامه شما در زمان اجرا، به بخش مدیریت تغییرات پیکربندی مراجعه کنید.

برای راهنمای کامل بومی‌سازی برنامه خود برای زبان‌های دیگر، به بومی‌سازی برنامه خود مراجعه کنید.

همچنین به متد getLocales() مراجعه کنید که لیست تعریف‌شده‌ی زبان‌ها را ارائه می‌دهد. این لیست شامل زبان اصلی است.

جنسیت دستوری masculine
feminine
neuter

جنسیت دستوری کاربر. برای زبان‌هایی که جنسیت دستوری دارند استفاده می‌شود.

برای مثال، اگر نیاز دارید منابع مختلفی را برای کاربران فرانسوی زبان فراهم کنید، می‌توانید از دایرکتوری‌هایی مانند زیر استفاده کنید:

res/
values-fr/
strings.xml (رشته‌های پیش‌فرض با جنسیت نامشخص)
values-fr-masculine/
strings.xml (رشته‌هایی با جنسیت مذکر)
values-fr-feminine/
strings.xml (رشته‌هایی با جنسیت مونث)
values-fr-neuter/
strings.xml (رشته‌هایی با جنسیت خنثی)

ببینید: صرف دستوری در اندروید.

همچنین به متد پیکربندی getGrammaticalGender() مراجعه کنید که جنسیت دستوری را نشان می‌دهد.

در سطح API 34 اضافه شد.

جهت چیدمان ldrtl
ldltr

جهت طرح‌بندی برنامه شما. ldrtl به معنی "جهت طرح‌بندی-راست به چپ" است. ldltr به معنی "جهت طرح‌بندی-چپ به راست" است و مقدار ضمنی پیش‌فرض است.

این می‌تواند برای هر منبعی، مانند طرح‌بندی‌ها، ترسیم‌پذیرها یا مقادیر، اعمال شود.

برای مثال، اگر می‌خواهید یک طرح‌بندی خاص برای زبان عربی و یک طرح‌بندی عمومی برای هر زبان «راست به چپ» دیگر، مانند فارسی یا عبری، ارائه دهید، از دایرکتوری‌هایی مانند موارد زیر استفاده می‌کنید:

res/
layout/
main.xml (طرح پیش‌فرض)
layout-ar/
main.xml (طرح‌بندی مخصوص زبان عربی)
layout-ldrtl/
main.xml (هر زبانی که از راست به چپ نوشته شده باشد به جز عربی، زیرا علامت توصیف زبان "ar" اولویت بالاتری دارد)

نکته: برای فعال کردن ویژگی‌های طرح‌بندی راست به چپ برای برنامه‌تان، باید SupportsRtl روی "true" تنظیم کنید و TargetSdkVersion روی ۱۷ ​​یا بالاتر تنظیم کنید.

در سطح API 17 اضافه شد.

کوچکترین عرض sw<N>dp

مثال‌ها:
sw320dp
sw600dp
sw720dp
و غیره

کوتاه‌ترین بُعد از مساحت صفحه نمایش که برای یک برنامه در دسترس است. به طور خاص، smallestWidth پنجره برنامه، کوتاه‌ترین ارتفاع و عرض موجود پنجره است. همچنین می‌توانید آن را به عنوان "کوچکترین عرض ممکن" برای پنجره در نظر بگیرید. می‌توانید از این توصیف‌کننده استفاده کنید تا برنامه شما حداقل <N> dps عرض برای رابط کاربری خود داشته باشد.

برای مثال، اگر طرح‌بندی شما ایجاب می‌کند که کوچکترین بُعد مساحت صفحه نمایش آن همیشه حداقل ۶۰۰ dp باشد، می‌توانید از این توصیف‌کننده برای ایجاد منابع طرح‌بندی در دایرکتوری res/layout-sw600dp/ استفاده کنید. سیستم فقط زمانی از این منابع استفاده می‌کند که کوچکترین بُعد صفحه نمایش موجود حداقل ۶۰۰ dp باشد، صرف نظر از اینکه ضلع ۶۰۰ dp ارتفاع یا عرض درک شده توسط کاربر باشد. کوچکترین عرض می‌تواند در صورت تغییر اندازه پنجره، تغییر عرض/ارتفاع موجود یا تغییر موقعیت، تغییر کند و به طور بالقوه باعث تغییر در insetهای سیستم شود.

استفاده از کوچکترین عرض برای تعیین اندازه کلی صفحه نمایش مفید است زیرا عرض اغلب عامل محرک در طراحی یک طرح بندی است. یک رابط کاربری اغلب به صورت عمودی پیمایش می شود، اما محدودیت های نسبتاً سختی در مورد حداقل فضای مورد نیاز به صورت افقی دارد.

عرض موجود همچنین عامل کلیدی در تعیین اینکه آیا از طرح‌بندی تک‌صفحه‌ای برای گوشی‌ها یا طرح‌بندی چندصفحه‌ای برای تبلت‌ها استفاده کنید، می‌باشد. بنابراین، احتمالاً بیشترین اهمیت را به کمترین عرض ممکن در هر دستگاه می‌دهید.

کوچکترین عرض یک دستگاه، تزئینات صفحه نمایش و رابط کاربری سیستم را در نظر می‌گیرد. برای مثال، اگر دستگاه دارای عناصر رابط کاربری دائمی روی صفحه باشد که فضای موجود در امتداد محور کوچکترین عرض را در نظر می‌گیرند، سیستم کوچکترین عرض را کوچکتر از اندازه واقعی صفحه نمایش اعلام می‌کند، زیرا این پیکسل‌های صفحه نمایش برای رابط کاربری شما در دسترس نیستند.

برخی از مقادیری که می‌توانید برای اندازه‌های رایج صفحه نمایش در اینجا استفاده کنید:

  • ۳۲۰، برای دستگاه‌هایی با تنظیمات صفحه نمایش مانند:
    • ۲۴۰x۳۲۰ ldpi (گوشی QVGA)
    • ۳۲۰x۴۸۰ پیکسل (برای گوشی)
    • ۴۸۰x۸۰۰ hdpi (گوشی با تراکم بالا)
  • ۴۸۰، برای صفحات نمایشی مانند ۴۸۰x۸۰۰ dpi (تبلت/گوشی)
  • ۶۰۰، برای صفحات نمایشی مانند ۶۰۰x۱۰۲۴ mdpi (تبلت ۷ اینچی)
  • ۷۲۰، برای صفحات نمایشی مانند ۷۲۰x۱۲۸۰ پیکسل (تبلت ۱۰ اینچی)

وقتی برنامه شما چندین دایرکتوری منبع با مقادیر مختلف برای smallestWidth ) ارائه می‌دهد، سیستم از دایرکتوری‌ای که به smallestWidth دستگاه نزدیک‌تر است (بدون اینکه از آن تجاوز کند) استفاده می‌کند.

در سطح API 13 اضافه شد.

همچنین به ویژگی android:requiresSmallestWidthDp مراجعه کنید که حداقل smallestWidth که برنامه شما با آن سازگار است، اعلام می‌کند و فیلد پیکربندی smallestScreenWidthDp که مقدار smallestWidth دستگاه را در خود نگه می‌دارد.

برای اطلاعات بیشتر در مورد طراحی برای صفحه نمایش‌های مختلف با استفاده از این توصیف‌کننده، به طراحی واکنش‌گرا/تطبیقی ​​با نماها مراجعه کنید.

عرض و ارتفاع موجود w<N>dp
h<N>dp

مثال‌ها:
w720dp
w1024dp
h720dp
h1024dp
و غیره

حداقل عرض یا ارتفاع صفحه نمایش موجود (در واحدهای dp که توسط مقدار <N> تعریف می‌شوند) را که در آن منبع استفاده می‌شود، مشخص می‌کند. این مقادیر پیکربندی با عرض و ارتفاع صفحه نمایش فعلی مقایسه می‌شوند، زیرا جهت دستگاه بین عمودی و افقی تغییر می‌کند، دستگاه تا می‌شود یا باز می‌شود، یا سیستم وارد حالت چند پنجره‌ای می‌شود یا از آن خارج می‌شود. در حالت چند پنجره‌ای، مقادیر، عرض و ارتفاع پنجره‌ای را که حاوی برنامه است، نشان می‌دهند، نه عرض و ارتفاع صفحه نمایش دستگاه. به طور مشابه، برای فعالیت‌های تعبیه‌شده، مقادیر مربوط به عرض و ارتفاع فعالیت‌های منفرد هستند، نه عرض و ارتفاع صفحه نمایش. برای اطلاعات بیشتر، به تعبیه فعالیت مراجعه کنید.

عرض و ارتفاع موجود اغلب برای تعیین اینکه آیا از طرح‌بندی چندبخشی استفاده شود یا خیر، مفید هستند، زیرا حتی در دستگاه تبلت نیز اغلب طرح‌بندی چندبخشی یکسانی را برای جهت‌گیری عمودی و افقی نمی‌خواهید. بنابراین، می‌توانید از این موارد برای مشخص کردن حداقل عرض و/یا ارتفاع مورد نیاز برای طرح‌بندی استفاده کنید، به جای اینکه از هر دو مشخصه اندازه صفحه و جهت‌گیری با هم استفاده کنید.

وقتی برنامه شما چندین دایرکتوری منبع با مقادیر مختلف برای این پیکربندی‌ها ارائه می‌دهد، سیستم از دایرکتوری‌ای استفاده می‌کند که به عرض صفحه نمایش فعلی دستگاه نزدیک‌تر باشد (بدون اینکه از آن تجاوز کند). نزدیکترین به با جمع کردن تفاوت‌های بین عرض واقعی صفحه نمایش و عرض مشخص شده به تفاوت بین ارتفاع واقعی صفحه نمایش و ارتفاع مشخص شده تعیین می‌شود، و ارتفاع‌ها و عرض‌های نامشخص مقدار ۰ دارند.

این مقادیر، ناحیه اشغال شده توسط Window insets را شامل نمی‌شوند، بنابراین اگر دستگاه دارای عناصر رابط کاربری دائمی در لبه‌های صفحه نمایش باشد، مقادیر عرض و ارتفاع کوچکتر از ابعاد واقعی صفحه نمایش هستند، حتی زمانی که برنامه با استفاده از Window.setDecorFitsSystemWindows یا WindowCompat.setDecorFitsSystemWindows از لبه به لبه نمایش داده می‌شود.

برخی از تزئینات عمودی صفحه که ثابت نیستند (مانند نوار وضعیت تلفن که می‌تواند در حالت تمام صفحه پنهان شود) و همچنین تزئینات پنجره مانند نوار عنوان یا نوار اکشن در اینجا در نظر گرفته نشده‌اند ، بنابراین برنامه‌ها باید برای کار با فضایی تا حدودی کوچکتر از آنچه مشخص می‌کنند، آماده باشند.

نکته: سیستم منبعی را انتخاب می‌کند که هم از نظر عرض و هم از نظر ارتفاع با هم مطابقت داشته باشند. بنابراین منبعی که هر دو را مشخص کند، نسبت به منبعی که فقط یکی از این دو را مشخص می‌کند، به شدت ترجیح داده می‌شود. برای مثال، اگر صفحه نمایش واقعی ۷۲۰ dp عرض و ۱۲۸۰ dp ارتفاع داشته باشد و یک منبع با w720dp و دیگری با w700dp-h1200dp توصیف شود، دومی انتخاب می‌شود، حتی اگر اولی دقیقاً با آنچه مشخص می‌کند مطابقت داشته باشد.

در سطح API 13 اضافه شد.

همچنین فیلدهای پیکربندی screenWidthDp و screenHeightDp را ببینید که عرض و ارتفاع فعلی صفحه نمایش را در خود نگه می‌دارند.

برای اطلاعات بیشتر در مورد طراحی برای صفحه نمایش‌های مختلف با استفاده از این توصیف‌کننده، به طراحی واکنش‌گرا/تطبیقی ​​با نماها مراجعه کنید.

اندازه صفحه نمایش small
normal
large
xlarge
  • 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
notlong
  • long : صفحه نمایش های طولانی مانند WQVGA، WVGA، FWVGA
  • notlong : صفحه های نه طولانی مانند QVGA، HVGA و VGA

در سطح API 4 اضافه شد.

این صرفاً بر اساس نسبت ابعاد صفحه نمایش است (یک صفحه نمایش long عریض‌تر است). این موضوع ربطی به جهت صفحه نمایش ندارد.

همچنین به فیلد پیکربندی screenLayout مراجعه کنید، که نشان می‌دهد آیا صفحه نمایش طویل است یا خیر.

صفحه نمایش گرد round
notround
  • round : صفحه نمایش‌های گرد، مانند یک دستگاه پوشیدنی گرد
  • notround : صفحه نمایش‌های مستطیلی، مانند تلفن‌ها یا تبلت‌ها

در سطح API 23 اضافه شد.

همچنین به متد پیکربندی isScreenRound() مراجعه کنید که نشان می‌دهد آیا صفحه نمایش گرد است یا خیر.

طیف رنگی گسترده widecg
nowidecg
  • widecg : نمایشگرهایی با طیف رنگی گسترده مانند Display P3 یا AdobeRGB
  • nowidecg : نمایشگرهایی با طیف رنگی محدود مانند sRGB

در سطح API 26 اضافه شد.

همچنین به متد پیکربندی isScreenWideColorGamut() مراجعه کنید، که نشان می‌دهد آیا صفحه نمایش دارای طیف رنگی وسیعی است یا خیر.

محدوده دینامیکی بالا (HDR) highdr
lowdr
  • highdr : نمایشگرهایی با محدوده دینامیکی بالا
  • lowdr : نمایشگرهایی با محدوده دینامیکی پایین/استاندارد

در سطح API 26 اضافه شد.

همچنین به متد پیکربندی isScreenHdr() مراجعه کنید، که نشان می‌دهد آیا صفحه نمایش دارای قابلیت‌های HDR است یا خیر.

جهت گیری صفحه نمایش port
land
  • port : دستگاه در جهت عمودی (پورت) قرار دارد
  • land : دستگاه در جهت افقی (لنداسکیپ) قرار دارد

این می‌تواند در طول اجرای برنامه شما تغییر کند، اگر کاربر صفحه را بچرخاند. برای اطلاعات بیشتر در مورد چگونگی تأثیر این موضوع بر برنامه شما در زمان اجرا، به بخش مدیریت تغییرات پیکربندی مراجعه کنید.

همچنین به فیلد پیکربندی orientation مراجعه کنید که جهت فعلی دستگاه را نشان می‌دهد.

حالت رابط کاربری car
desk
television
appliance
watch
vrheadset
  • car : دستگاه در جایگاه مخصوص ماشین نمایش داده می‌شود
  • desk : دستگاه در داک میز نمایش داده می‌شود
  • television : دستگاه روی تلویزیون نمایش داده می‌شود و یک تجربه "ده فوتی" را ارائه می‌دهد که در آن رابط کاربری روی یک صفحه نمایش بزرگ است که کاربر از آن دور است و این تجربه عمدتاً حول محور D-pad یا سایر تعاملات غیر اشاره‌گری متمرکز است.
  • appliance : دستگاه به عنوان یک دستگاه عمل می‌کند، بدون صفحه نمایش
  • watch : دستگاهی که صفحه نمایش دارد و روی مچ دست بسته می‌شود
  • vrheadset : دستگاه در یک هدست واقعیت مجازی نمایش داده می‌شود

در سطح API 8 اضافه شد؛ تلویزیون در API 13 اضافه شد؛ ساعت در API 20 اضافه شد.

برای کسب اطلاعات در مورد نحوه واکنش برنامه شما هنگام وارد کردن یا برداشتن دستگاه از داک، بخش تعیین و نظارت بر وضعیت و نوع داک را مطالعه کنید.

این می‌تواند در طول عمر برنامه شما تغییر کند اگر کاربر دستگاه را در یک داک قرار دهد. می‌توانید برخی از این حالت‌ها را با استفاده از UiModeManager فعال یا غیرفعال کنید. برای اطلاعات در مورد چگونگی تأثیر این موضوع بر برنامه شما در زمان اجرا، به Handle configuration changes مراجعه کنید.

حالت شب night
notnight
  • night : شب هنگام
  • notnight : روز

در سطح API 8 اضافه شد.

اگر حالت شب در حالت خودکار (پیش‌فرض) باقی بماند، این می‌تواند در طول عمر برنامه شما تغییر کند، که در این صورت حالت بر اساس زمان روز تغییر می‌کند. می‌توانید این حالت را با استفاده از UiModeManager فعال یا غیرفعال کنید. برای اطلاعات در مورد چگونگی تأثیر این موضوع بر برنامه شما در زمان اجرا، به Handle configuration changes مراجعه کنید.

تراکم پیکسل صفحه نمایش (dpi) ldpi
mdpi
hdpi
xhdpi
xxhdpi
xxxhdpi
nodpi
tvdpi
anydpi
nnn dpi
  • ldpi : صفحات نمایش با چگالی کم؛ تقریباً ۱۲۰ نقطه در اینچ.
  • mdpi : صفحات نمایش با چگالی متوسط ​​(در HVGA سنتی)؛ تقریباً 160 نقطه در اینچ.
  • hdpi : صفحات نمایش با چگالی بالا؛ تقریباً 240 dpi.
  • xhdpi : صفحات نمایش با چگالی بسیار بالا؛ تقریباً 320 dpi. در سطح API 8 اضافه شده است.
  • xxhdpi : صفحات نمایش با چگالی فوق‌العاده بالا؛ تقریباً ۴۸۰ نقطه در اینچ. در سطح API 16 اضافه شد.
  • xxxhdpi : با چگالی بسیار بسیار بالا (فقط آیکون لانچر - به پشتیبانی از چگالی‌های پیکسلی مختلف مراجعه کنید)؛ تقریباً ۶۴۰ نقطه در اینچ. در سطح API 18 اضافه شد.
  • nodpi : برای منابع بیت‌مپ که نمی‌خواهید برای مطابقت با چگالی دستگاه مقیاس‌بندی شوند، استفاده می‌شود.
  • tvdpi : صفحه نمایش‌هایی که جایی بین mdpi و hdpi قرار دارند؛ تقریباً ۲۱۳ dpi. این یک گروه چگالی «اصلی» محسوب نمی‌شود. این گروه عمدتاً برای تلویزیون‌های ۷۲۰p در نظر گرفته شده است و اکثر برنامه‌ها به آن نیازی ندارند. برای پنل‌های تلویزیون ۱۰۸۰p، از xhdpi و برای پنل‌های تلویزیون ۴K، از xxxhdpi استفاده کنید. در سطح API ۱۳ اضافه شده است.
  • anydpi : با تمام تراکم‌های صفحه نمایش مطابقت دارد و بر سایر توصیف‌کننده‌ها اولویت دارد. این برای ترسیم‌های برداری مفید است. در سطح API 21 اضافه شده است.
  • nnn dpi : برای نمایش تراکم‌های غیراستاندارد استفاده می‌شود، که در آن nnn یک عدد صحیح مثبت برای تراکم صفحه نمایش است. این در بیشتر موارد استفاده نمی‌شود. استفاده از سطل‌های تراکم استاندارد، سربار پشتیبانی از تراکم‌های صفحه نمایش دستگاه‌های مختلف موجود در بازار را تا حد زیادی کاهش می‌دهد.

نسبت مقیاس‌بندی ۳:۴:۶:۸:۱۲:۱۶ بین شش چگالی اولیه وجود دارد (با نادیده گرفتن چگالی tvdpi). بنابراین، یک بیت‌مپ ۹x۹ در ldpi، ۱۲x۱۲ در mdpi، ۱۸x۱۸ در hdpi، ۲۴x۲۴ در xhdpi و غیره است.

نکته: استفاده از یک توصیف‌کننده چگالی به این معنی نیست که منابع فقط برای صفحاتی با آن چگالی هستند. اگر منابع جایگزینی با توصیف‌کننده‌هایی که با پیکربندی دستگاه فعلی مطابقت بیشتری دارند ارائه ندهید، سیستم از منابعی که بهترین تطابق را دارند استفاده می‌کند.

برای اطلاعات بیشتر در مورد نحوه مدیریت تراکم‌های مختلف صفحه نمایش و اینکه چگونه اندروید ممکن است بیت‌مپ‌های شما را برای تطبیق با تراکم فعلی مقیاس‌بندی کند، به نمای کلی سازگاری صفحه نمایش مراجعه کنید.

نوع صفحه لمسی notouch
finger
  • notouch : دستگاه صفحه لمسی ندارد.
  • finger : دستگاه دارای صفحه لمسی است که برای استفاده از طریق تعامل جهت انگشت کاربر در نظر گرفته شده است.

همچنین به فیلد پیکربندی touchscreen مراجعه کنید که نوع صفحه لمسی دستگاه را نشان می‌دهد.

در دسترس بودن صفحه کلید keysexposed
keyshidden
keyssoft
  • keysexposed : دستگاه دارای صفحه‌کلید است. اگر دستگاه دارای صفحه‌کلید نرم‌افزاری فعال باشد (که احتمالاً چنین است)، این حتی زمانی که صفحه‌کلید سخت‌افزاری در دسترس کاربر نیست یا دستگاه صفحه‌کلید سخت‌افزاری ندارد، استفاده می‌شود. اگر هیچ صفحه‌کلید نرم‌افزاری ارائه نشده باشد یا غیرفعال باشد، این فقط زمانی استفاده می‌شود که صفحه‌کلید سخت‌افزاری در دسترس باشد.
  • keyshidden : دستگاه دارای یک صفحه کلید سخت‌افزاری است اما پنهان است و صفحه کلید نرم‌افزاری روی دستگاه فعال نیست .
  • keyssoft : دستگاه دارای یک صفحه‌کلید نرم‌افزاری فعال است، چه قابل مشاهده باشد چه نباشد.

اگر منابع keysexposed را ارائه دهید، اما منابع keyssoft ارائه ندهید، سیستم از منابع keysexposed صرف نظر از اینکه صفحه کلید قابل مشاهده باشد یا خیر، استفاده می‌کند، البته تا زمانی که سیستم صفحه کلید نرم‌افزاری را فعال کرده باشد.

این می‌تواند در طول اجرای برنامه شما تغییر کند، اگر کاربر یک صفحه کلید سخت‌افزاری را باز کند. برای اطلاعات بیشتر در مورد چگونگی تأثیر این موضوع بر برنامه شما در زمان اجرا، به بخش مدیریت تغییرات پیکربندی مراجعه کنید.

همچنین به فیلدهای پیکربندی hardKeyboardHidden و keyboardHidden مراجعه کنید که به ترتیب نشان‌دهنده‌ی قابلیت مشاهده‌ی یک صفحه‌کلید سخت‌افزاری و قابلیت مشاهده‌ی هر نوع صفحه‌کلید (از جمله نرم‌افزار) هستند.

روش ورودی متن اولیه nokeys
qwerty
12key
  • nokeys : دستگاه هیچ کلید سخت‌افزاری برای ورود متن ندارد.
  • qwerty : دستگاه دارای یک صفحه کلید QWERTY سخت‌افزاری است، چه برای کاربر قابل مشاهده باشد چه نباشد.
  • 12key : دستگاه دارای یک صفحه‌کلید سخت‌افزاری ۱۲ کلیدی است، چه برای کاربر قابل مشاهده باشد چه نباشد.

همچنین به فیلد پیکربندی keyboard مراجعه کنید، که روش ورودی متن اصلی موجود را نشان می‌دهد.

نسخه پلتفرم (سطح API) مثال‌ها:
v3
v4
v7
و غیره

سطح API پشتیبانی شده توسط دستگاه. به عنوان مثال، v1 برای API سطح 1 (دستگاه‌های دارای اندروید 1.0 یا بالاتر) و v4 برای API سطح 4 (دستگاه‌های دارای اندروید 1.6 یا بالاتر). برای اطلاعات بیشتر در مورد این مقادیر، به سند سطوح API اندروید مراجعه کنید.

توجه: همه نسخه‌های اندروید از همه توصیف‌کننده‌ها پشتیبانی نمی‌کنند. استفاده از یک توصیف‌کننده جدید، توصیف‌کننده نسخه پلتفرم را به طور ضمنی اضافه می‌کند تا دستگاه‌های قدیمی‌تر بتوانند آن را نادیده بگیرند. به عنوان مثال، استفاده از توصیف‌کننده w600dp به طور خودکار توصیف‌کننده v13 را شامل می‌شود، زیرا توصیف‌کننده available-width در سطح API 13 جدید بود. برای جلوگیری از هرگونه مشکل، همیشه مجموعه‌ای از منابع پیش‌فرض (مجموعه‌ای از منابع بدون توصیف‌کننده ) را در نظر بگیرید. برای اطلاعات بیشتر، به بخش « ارائه بهترین سازگاری دستگاه با منابع» مراجعه کنید.

قوانین نام واجد شرایط

در اینجا چند قانون در مورد استفاده از نام‌های توصیف‌کننده پیکربندی آمده است:

  • شما می‌توانید برای یک مجموعه از منابع، چندین توصیف‌کننده (qualifier) ​​تعیین کنید که با خط تیره از هم جدا شده‌اند. برای مثال، drawable-en-rUS-land برای دستگاه‌های US-English در جهت افقی (landscape) اعمال می‌شود.
  • ترتیب قرار گرفتن گزینه‌ها باید مطابق جدول ۲ باشد.
    • اشتباه: drawable-hdpi-port/
    • صحیح: drawable-port-hdpi/
  • دایرکتوری‌های منابع جایگزین را نمی‌توان تو در تو تعریف کرد. برای مثال، نمی‌توانید res/drawable/drawable-en/ داشته باشید.
  • مقادیر به حروف کوچک و بزرگ حساس نیستند. کامپایلر منابع، نام دایرکتوری‌ها را قبل از پردازش به حروف کوچک تبدیل می‌کند تا از بروز مشکلات در سیستم‌های فایل غیر حساس به حروف کوچک و بزرگ جلوگیری شود. هرگونه استفاده از حروف بزرگ در نام‌ها فقط برای افزایش خوانایی است.
  • فقط یک مقدار برای هر نوع توصیف‌گر پشتیبانی می‌شود. برای مثال، اگر می‌خواهید از فایل‌های drawable یکسان برای اسپانیا و فرانسه استفاده کنید، نمی‌توانید دایرکتوری به نام drawable-es-fr/ داشته باشید. در عوض، به دو دایرکتوری منبع، مانند drawable-es/ و drawable-fr/ ، نیاز دارید که شامل فایل‌های مناسب باشند. با این حال، لازم نیست فایل‌ها را در هر دو مکان کپی کنید. در عوض، می‌توانید یک نام مستعار برای یک منبع ایجاد کنید، همانطور که در بخش ایجاد منابع مستعار توضیح داده شده است.

پس از اینکه منابع جایگزین را در دایرکتوری‌هایی که با این توصیف‌کننده‌ها نامگذاری شده‌اند ذخیره کردید، اندروید به طور خودکار منابع را بر اساس پیکربندی فعلی دستگاه در برنامه شما اعمال می‌کند. هر بار که منبعی درخواست می‌شود، اندروید دایرکتوری‌های منابع جایگزین را که حاوی فایل منبع درخواستی هستند بررسی می‌کند، سپس بهترین منبع منطبق را پیدا می‌کند .

اگر هیچ منبع جایگزینی که با پیکربندی خاص دستگاه مطابقت داشته باشد، وجود نداشته باشد، اندروید از منابع پیش‌فرض مربوطه استفاده می‌کند - مجموعه‌ای از منابع برای یک نوع منبع خاص که شامل توصیف‌کننده پیکربندی نمی‌شود.

ایجاد منابع مستعار

وقتی منبعی دارید که می‌خواهید برای بیش از یک پیکربندی دستگاه از آن استفاده کنید اما نمی‌خواهید آن را به عنوان منبع پیش‌فرض ارائه دهید، نیازی نیست همان منبع را در بیش از یک دایرکتوری منبع جایگزین قرار دهید. در عوض، می‌توانید یک منبع جایگزین ایجاد کنید که به عنوان نام مستعار برای منبعی که در دایرکتوری منبع پیش‌فرض شما ذخیره شده است، عمل کند.

نکته: همه منابع مکانیزمی برای ایجاد نام مستعار برای منبع دیگر ارائه نمی‌دهند. به طور خاص، animation، menu، raw و سایر منابع نامشخص در دایرکتوری xml/ این ویژگی را ارائه نمی‌دهند.

برای مثال، تصور کنید که یک آیکون برنامه، icon.png ، دارید و به یک نسخه منحصر به فرد از آن برای زبان‌های مختلف نیاز دارید. با این حال، دو زبان، انگلیسی-کانادایی و فرانسوی-کانادایی، باید از یک نسخه استفاده کنند. نیازی نیست که تصویر یکسانی را برای هر دو زبان انگلیسی-کانادایی و فرانسوی-کانادایی در دایرکتوری منبع کپی کنید. در عوض، می‌توانید تصویری را که برای هر دو زبان استفاده می‌شود با نامی غیر از icon.png ، مانند icon_ca.png ، ذخیره کنید و آن را در دایرکتوری پیش‌فرض res/drawable/ قرار دهید. سپس یک فایل icon.xml در res/drawable-en-rCA/ و res/drawable-fr-rCA/ ایجاد کنید که با استفاده از عنصر <bitmap> به منبع icon_ca.png اشاره می‌کند. این به شما امکان می‌دهد فقط یک نسخه از فایل PNG و دو فایل XML کوچک که به آن اشاره می‌کنند را ذخیره کنید. برای جزئیات بیشتر به مثال‌های بخش‌های بعدی مراجعه کنید.

قابل ترسیم

برای ایجاد یک نام مستعار برای یک drawable موجود، از عنصر <drawable> استفاده کنید:

<?xml version="1.0" encoding="utf-8"?>
<resources>
    <drawable name="icon">@drawable/icon_ca</drawable>
</resources>

اگر این فایل را با نام icon.xml در یک دایرکتوری منبع جایگزین، مانند res/values-en-rCA/ ذخیره کنید، به منبعی کامپایل می‌شود که می‌توانید به عنوان R.drawable.icon به آن ارجاع دهید، اما در واقع یک نام مستعار برای منبع R.drawable.icon_ca است که در res/drawable/ ذخیره می‌شود.

طرح بندی

برای ایجاد یک نام مستعار برای یک طرح‌بندی موجود، از عنصر <include> که در یک <merge> قرار گرفته است، استفاده کنید:

<?xml version="1.0" encoding="utf-8"?>
<merge>
    <include layout="@layout/main_ltr"/>
</merge>

اگر این فایل را با نام main.xml ذخیره کنید، به منبعی کامپایل می‌شود که می‌توانید به عنوان R.layout.main به آن ارجاع دهید، اما در واقع یک نام مستعار برای منبع R.layout.main_ltr است.

رشته‌ها و سایر مقادیر ساده

برای ایجاد یک نام مستعار برای یک رشته موجود، از شناسه منبع رشته مورد نظر به عنوان مقدار رشته جدید استفاده کنید:

<?xml version="1.0" encoding="utf-8"?>
<resources>
    <string name="hello">Hello</string>
    <string name="hi">@string/hello</string>
</resources>

منبع R.string.hi اکنون یک نام مستعار برای R.string.hello است.

سایر مقادیر ساده نیز به همین روش کار می‌کنند، مانند رنگ‌ها:

<?xml version="1.0" encoding="utf-8"?>
<resources>
    <color name="red">#f00</color>
    <color name="highlight">@color/red</color>
</resources>

به منابع برنامه خود دسترسی پیدا کنید

Once you provide a resource in your application, you can apply it by referencing its resource ID. All resource IDs are defined in your project's R class, which the aapt tool automatically generates.

When your application is compiled, aapt generates the R class, which contains resource IDs for all the resources in your res/ directory. For each type of resource, there is an R subclass, such as R.drawable for all drawable resources. And for each resource of that type, there is a static integer, for example, R.drawable.icon . This integer is the resource ID that you can use to retrieve your resource.

Although the R class is where resource IDs are specified, you don't need to look there to discover a resource ID. A resource ID is always composed of the following:

  • The resource type : each resource is grouped into a "type," such as string , drawable , and layout . For more information about the different types, see Resource types overview .
  • The resource name , which is either the filename excluding the extension or the value in the XML android:name attribute, if the resource is a simple value, such as a string.

There are two ways you can access a resource:

  • In code: using a static integer from a subclass of your R class, such as:
    R.string.hello

    string is the resource type and hello is the resource name. There are many Android APIs that can access your resources when you provide a resource ID in this format. For more information, see the Access resources in code section.

  • In XML: using a special XML syntax that corresponds to the resource ID defined in your R class, such as:
    @string/hello

    string is the resource type and hello is the resource name. You can use this syntax in an XML resource any place where a value is expected that you provide in a resource. For more information, see the Access resources from XML section.

Access resources in code

You can use a resource in code by passing the resource ID as a method parameter. For example, you can set an ImageView to use the res/drawable/myimage.png resource using setImageResource() :

کاتلین

val imageView = findViewById(R.id.myimageview) as ImageView
imageView.setImageResource(R.drawable.myimage)

جاوا

ImageView imageView = (ImageView) findViewById(R.id.myimageview);
imageView.setImageResource(R.drawable.myimage);

You can also retrieve individual resources using methods in Resources , which you can get an instance of with getResources() .

نحو

Here's the syntax to reference a resource in code:

[<package_name>.]R.<resource_type>.<resource_name>
  • <package_name> is the name of the package in which the resource is located (not required when referencing resources from your own package).
  • <resource_type> is the R subclass for the resource type.
  • <resource_name> is either the resource filename without the extension or the android:name attribute value in the XML element, for simple values.

For more information about each resource type and how to reference them, see Resource types overview .

موارد استفاده

There are many methods that accept a resource ID parameter, and you can retrieve resources using methods in Resources . You can get an instance of Resources using Context.getResources() .

Here are some examples of accessing resources in code:

کاتلین

// Load a background for the current screen from a drawable resource.
window.setBackgroundDrawableResource(R.drawable.my_background_image)

// Set the Activity title by getting a string from the Resources object, because
//  this method requires a CharSequence rather than a resource ID.
window.setTitle(resources.getText(R.string.main_title))

// Load a custom layout for the current screen.
setContentView(R.layout.main_screen)

// Set a slide in animation by getting an Animation from the Resources object.
flipper.setInAnimation(AnimationUtils.loadAnimation(this,
        R.anim.hyperspace_in))

// Set the text on a TextView object using a resource ID.
val msgTextView = findViewById(R.id.msg) as TextView
msgTextView.setText(R.string.hello_message)

جاوا

// Load a background for the current screen from a drawable resource.
getWindow().setBackgroundDrawableResource(R.drawable.my_background_image) ;

// Set the Activity title by getting a string from the Resources object, because
//  this method requires a CharSequence rather than a resource ID.
getWindow().setTitle(getResources().getText(R.string.main_title));

// Load a custom layout for the current screen.
setContentView(R.layout.main_screen);

// Set a slide in animation by getting an Animation from the Resources object.
flipper.setInAnimation(AnimationUtils.loadAnimation(this,
        R.anim.hyperspace_in));

// Set the text on a TextView object using a resource ID.
TextView msgTextView = (TextView) findViewById(R.id.msg);
msgTextView.setText(R.string.hello_message);

Caution: Don't modify the R.java file by hand. It is generated by the aapt tool when your project is compiled. Any changes are overridden next time you compile.

Access resources from XML

You can define values for some XML attributes and elements using a reference to an existing resource. You often do this when creating layout files, to supply strings and images for your widgets.

For example, if you add a Button to your layout, use a string resource for the button text:

<Button
    android:layout_width="fill_parent"
    android:layout_height="wrap_content"
    android:text="@string/submit" />

نحو

Here is the syntax to reference a resource in an XML resource:

@[<package_name>:]<resource_type>/<resource_name>
  • <package_name> is the name of the package in which the resource is located (not required when referencing resources from the same package).
  • <resource_type> is the R subclass for the resource type.
  • <resource_name> is either the resource filename without the extension or the android:name attribute value in the XML element, for simple values.

For more information about each resource type and how to reference them, see Resource types overview .

موارد استفاده

In some cases, you must use a resource for a value in XML, such as to apply a drawable image to a widget, but you can also use a resource in XML any place that accepts a simple value. For example, if you have the following resource file that includes a color resource and a string resource :

<?xml version="1.0" encoding="utf-8"?>
<resources>
   <color name="opaque_red">#f00</color>
   <string name="hello">Hello!</string>
</resources>

You can use these resources in the following layout file to set the text color and text string:

<?xml version="1.0" encoding="utf-8"?>
<EditText xmlns:android="http://schemas.android.com/apk/res/android"
    android:layout_width="fill_parent"
    android:layout_height="fill_parent"
    android:textColor="@color/opaque_red"
    android:text="@string/hello" />

In this case, you don't need to specify the package name in the resource reference, because the resources are from your own package. To reference a system resource, you need to include the package name, as shown in the following example:

<?xml version="1.0" encoding="utf-8"?>
<EditText xmlns:android="http://schemas.android.com/apk/res/android"
    android:layout_width="fill_parent"
    android:layout_height="fill_parent"
    android:textColor="@android:color/secondary_text_dark"
    android:text="@string/hello" />

Note: Always use string resources, so that your application can be localized for other languages. For information about creating alternative resources (such as localized strings), see Provide alternative resources . For a complete guide to localizing your application for other languages, see Localize your app .

You can even use resources in XML to create aliases. For example, you can create a drawable resource that is an alias for another drawable resource:

<?xml version="1.0" encoding="utf-8"?>
<bitmap xmlns:android="http://schemas.android.com/apk/res/android"
    android:src="@drawable/other_drawable" />

This sounds redundant, but can be very useful when using alternative resource. For more information, see the section about creating alias resources .

Reference style attributes

A style attribute resource lets you reference the value of an attribute in the currently applied theme. Referencing a style attribute lets you customize the look of UI elements by styling them to match standard variations supplied by the current theme, instead of supplying a hardcoded value. Referencing a style attribute essentially says, "Use the style that is defined by this attribute in the current theme."

To reference a style attribute, the name syntax is almost identical to the normal resource format, but instead of the "at" symbol ( @ ), use a question mark ( ? ). The resource type portion is optional. So the reference syntax is as follows:

?[<package_name>:][<resource_type>/]<resource_name>

For example, here's how you can reference an attribute to set the text color to match the secondary text color of the system theme:

<EditText id="text"
    android:layout_width="fill_parent"
    android:layout_height="wrap_content"
    android:textColor="?android:textColorSecondary"
    android:text="@string/hello_world" />

Here, the android:textColor attribute specifies the name of a style attribute in the current theme. Android now uses the value applied to the android:textColorSecondary style attribute as the value for android:textColor in this widget. Because the system resource tool knows that an attribute resource is expected in this context, you do not need to explicitly state the type, which is ?android:attr/textColorSecondary . You can exclude the attr type.

Access original files

While uncommon, you might need access your original files and directories. If you do, then saving your files in res/ won't work for you, because the only way to read a resource from res/ is with the resource ID. Instead, you can save your resources in the assets/ directory.

Files saved in the assets/ directory are not given a resource ID, so you can't reference them through the R class or from XML resources. Instead, you can query files in the assets/ directory like a normal file system and read raw data using AssetManager .

However, if all you require is the ability to read raw data (such as a video or audio file), then save the file in the res/raw/ directory and read a stream of bytes using openRawResource() .

Access platform resources

Android contains a number of standard resources, such as styles, themes, and layouts. To access these resources, qualify your resource reference with the android package name. For example, Android provides a layout resource you can use for list items in a ListAdapter :

کاتلین

listAdapter = ArrayAdapter(this, android.R.layout.simple_list_item_1, myarray)

جاوا

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

In this example, simple_list_item_1 is a layout resource defined by the platform for items in a ListView . You can use this instead of creating your own layout for list items.

Provide the best device compatibility with resources

For your app to support multiple device configurations, it's very important that you always provide default resources for each type of resource that your app uses.

For example, if your app supports several languages, always include a values/ directory (in which your strings are saved) without a language and region qualifier . If you instead put all your string files in directories that have a language and region qualifier, then your app crashes when run on a device set to a language that your strings don't support.

As long as you provide default values/ resources, then your app runs properly, even if the user doesn't understand the language it presents. It's better than crashing.

Likewise, if you provide different layout resources based on the screen orientation, pick one orientation as your default. For example, instead of providing layout resources in layout-land/ for landscape and layout-port/ for portrait, leave one as the default, such as layout/ for landscape and layout-port/ for portrait.

Providing default resources is important not only because your app might run on a configuration you hadn't anticipated, but also because new versions of Android sometimes add configuration qualifiers that older versions don't support. If you use a new resource qualifier, but maintain code compatibility with older versions of Android, then when an older version of Android runs your app, it crashes if you don't provide default resources, because it can't use the resources named with the new qualifier.

For example, if your minSdkVersion is set to 4, and you qualify all of your drawable resources using night mode ( night or notnight , which were added in API level 8), then an API level 4 device can't access your drawable resources and crashes. In this case, you probably want notnight to be your default resources, so exclude that qualifier and put your drawable resources in either drawable/ or drawable-night/ .

In short, to provide the best device compatibility, always provide default resources for the resources your app needs to perform properly. Then create alternative resources for specific device configurations using configuration qualifiers.

There is one exception to this rule: If your app's minSdkVersion is 4 or greater, you don't need default drawable resources when you provide alternative drawable resources with the screen density qualifier. Even without default drawable resources, Android can find the best match among the alternative screen densities and scale the bitmaps as necessary. However, for the best experience on all types of devices, provide alternative drawables for all three types of density.

How Android finds the best-matching resource

When you request a resource for which you provide alternatives, Android selects which alternative resource to use at runtime, depending on the current device configuration. To demonstrate how Android selects an alternative resource, assume the following drawable directories each contain different versions of the same images:

drawable/
drawable-en/
drawable-fr-rCA/
drawable-en-port/
drawable-en-notouch-12key/
drawable-port-ldpi/
drawable-port-notouch-12key/

And assume the following is the device configuration:

Locale = en-GB
Screen orientation = port
Screen pixel density = hdpi
Touchscreen type = notouch
Primary text input method = 12key

By comparing the device configuration to the available alternative resources, Android selects drawables from drawable-en-port .

The system arrives at its decision for which resources to use with the following logic:

Figure 2. Flowchart of how Android finds the best-matching resource.

  1. Eliminate resource files that contradict the device configuration.

    The drawable-fr-rCA/ directory is eliminated, because it contradicts the en-GB locale.

    drawable/
    drawable-en/
    drawable-fr-rCA/
    drawable-en-port/
    drawable-en-notouch-12key/
    drawable-port-ldpi/
    drawable-port-notouch-12key/
    

    Exception: Screen pixel density is the one qualifier that is not eliminated due to a contradiction. Even though the screen density of the device is hdpi, drawable-port-ldpi/ isn't eliminated because every screen density is considered to be a match at this point. For information, see Screen compatibility overview .

  2. Find the next-highest-precedence qualifier in the list ( table 2 ). (Start with MCC.)
  3. Do any of the resource directories include this qualifier?
    • If no, return to step two and look at the next qualifier. In this example, the answer is "no" until the language qualifier is reached.
    • If yes, continue to step four.
  4. Eliminate resource directories that don't include this qualifier. In this example, the system next eliminates all the directories that don't include a language qualifier:
    drawable/
    drawable-en/
    drawable-en-port/
    drawable-en-notouch-12key/
    drawable-port-ldpi/
    drawable-port-notouch-12key/
    

    Exception: If the qualifier in question is screen pixel density, Android selects the option that most closely matches the device screen density. In general, Android prefers scaling down a larger original image to scaling up a smaller original image. For more information, see Screen compatibility overview .

  5. Repeat steps two, three, and four until only one directory remains. In this example, screen orientation is the next qualifier for which there are any matches. So, resources that don't specify a screen orientation are eliminated:
    drawable-en/
    drawable-en-port/
    drawable-en-notouch-12key/
    

    The remaining directory is drawable-en-port .

Though this procedure is executed for each resource requested, the system optimizes some aspects of it. One such optimization is that once the device configuration is known, it might eliminate alternative resources that can never match. For example, if the configuration language is English, then any resource directory that has a language qualifier set to something other than English is never included in the pool of resources checked (though a resource directory without the language qualifier is still included).

When selecting resources based on the screen size qualifiers, the system uses resources designed for a screen smaller than the current screen if there are no resources that better match. For example, a large-size screen uses normal-size screen resources if necessary.

However, if the only available resources are larger than the current screen, the system doesn't use them and your app crashes if no other resources match the device configuration. This happens, for example, if all layout resources are tagged with the xlarge qualifier, but the device is a normal-size screen.

Note: The precedence of the qualifier (in table 2 ) is more important than the number of qualifiers that exactly match the device. In the preceding example, at step four the last choice on the list includes three qualifiers that exactly match the device (orientation, touchscreen type, and input method), while drawable-en has only one parameter that matches (language). However, language has a higher precedence than these other qualifiers, so drawable-port-notouch-12key is eliminated.