סקירה כללית של משאבי האפליקציה (תצוגות)

ספרייה

Resource Type

animator/

קובצי XML שמגדירים אנימציות של מאפיינים.

anim/

קובצי XML שמגדירים אנימציות Tween. אפשר לשמור בספרייה הזו גם אנימציות של מאפיינים, אבל עדיף לשמור אותן בספרייה animator/ כדי להבחין בין שני הסוגים.

color/

קובצי XML שמגדירים רשימת צבעים של מצב. מידע נוסף זמין במאמר בנושא משאב של רשימת מצבי צבע.

drawable/

קובצי מפת סיביות (PNG,‏ ‎.9.png,‏ JPG או GIF) או קובצי XML שעברו קומפילציה לסוגי המשנה הבאים של פריטים גרפיים שניתנים להזזה:

• קובצי מפת סיביות
• תמונות 9-patch (מפות סיביות שניתן לשנות את הגודל שלהן)
• רשימות של מדינות
• צורות
• נכסי אנימציה מסוג drawable
• רכיבים אחרים שאפשר לצייר

מידע נוסף זמין במאמר משאבים מסוג 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/ מתארים כמה משאבים. לכל קובץ בספרייה הזו, כל צאצא של רכיב מגדיר משאב יחיד. לדוגמה, רכיב יוצר משאב R.string, ורכיב יוצר משאב R.color.

כל משאב מוגדר באמצעות רכיב XML משלו, כך שאפשר לתת לקובץ כל שם שרוצים ולכלול בו סוגים שונים של משאבים. עם זאת, לשם הבהרה, כדאי להציב סוגים ייחודיים של משאבים בקבצים שונים. לדוגמה, אלה מוסכמות לשמות קבצים של משאבים שאפשר ליצור בספרייה הזו:

• ‫arrays.xml למערכי משאבים (מערכים מוקלדים)
• colors.xml לגבי ערכי צבע
• ‫dimens.xml לערכי מאפיינים
• ‫strings.xml לערכי מחרוזת
• styles.xml לסגנונות

מידע נוסף זמין במאמרים משאבי מחרוזות, משאבי סגנון וסוגים נוספים של משאבים.

xml/

קובצי XML שרירותיים שאפשר לקרוא בזמן הריצה על ידי קריאה ל-Resources.getXML(). צריך לשמור כאן קובצי תצורה שונים של XML.

font/

קובצי גופנים עם סיומות כמו TTF, ‏ OTF או TTC, או קובצי XML שכוללים אלמנט . מידע נוסף על גופנים כמשאבים זמין במאמר הוספת גופן כמשאב XML.

הגדרות אישיות

ערכי מגדיר

תיאור

קוד MCC וקוד MNC

דוגמאות:

mcc310

mcc310-mnc004

mcc208-mnc00

קוד מדינה של רשת סלולרית (MCC), שאחריו יכול להופיע קוד הרשת הסלולרית (MNC) מכרטיס ה-SIM במכשיר. לדוגמה, mcc310 היא ארה"ב בכל ספק, mcc310-mnc004 היא ארה"ב ב-Verizon ו-mcc208-mnc00 היא צרפת ב-Orange.

אם המכשיר משתמש בחיבור רדיו (כלומר, אם זה טלפון GSM), ערכי ה-MCC וה-MNC מגיעים מכרטיס ה-SIM.

אפשר גם להשתמש רק ב-MCC, למשל כדי לכלול באפליקציה משאבים משפטיים שספציפיים למדינה. אם אתם צריכים לציין על סמך השפה בלבד, אתם יכולים להשתמש במקום זאת במאפיין המסווג שפה, סקריפט (אופציונלי) ואזור (אופציונלי). אם אתם משתמשים במזהה MCC ובמזהה MNC כמאפייני סינון, עליכם לעשות זאת בזהירות ולבדוק שהם פועלים כמצופה.

אפשר גם לראות את שדות ההגדרה mcc ו-mnc, שמציינים את קוד המדינה של רשת סלולרית ואת קוד הרשת הסלולרית (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-2{:.external}, שאחריו יכול להיות קוד אזור בן שתי אותיות לפי ISO 3166-1-alpha-2{:.external} (לפניו האותיות הקטנות r).

הקודים לא תלויי אותיות רישיות (case-sensitive). הקידומת r משמשת להבחנה בין החלקים של האזור. אי אפשר לציין רק אזור.

ב-Android 7.0 (רמת API ‏24) נוספה תמיכה בתגי שפה של BCP 47{:.external}, שאפשר להשתמש בהם כדי להגדיר משאבים ספציפיים לשפה ולאזור. תג שפה מורכב מרצף של תגי משנה אחד או יותר, וכל אחד מהם מצמצם או משפר את טווח השפה שמזוהה על ידי התג הכולל. מידע נוסף על תגי שפה זמין במאמר תגים לזיהוי שפות{:.external}.

כדי להשתמש בתג שפה לפי BCP 47, צריך לשרשר את b+ ואת קוד השפה ISO 639-2{:.external} בן שתי האותיות, ואפשר להוסיף אחריו תגי משנה נוספים שמופרדים באמצעות +.

תג השפה יכול להשתנות במהלך השימוש באפליקציה אם המשתמשים משנים את השפה בהגדרות המערכת. מידע על ההשפעה של השינוי הזה על האפליקציה במהלך זמן הריצה זמין במאמר טיפול בשינויים בהגדרות.

מדריך מלא להתאמת האפליקציה לשפות אחרות זמין במאמר התאמת האפליקציה לשוק המקומי.

אפשר גם לעיין ב-method‏ getLocales, שמספק את רשימת הלוקאלים המוגדרת. הרשימה הזו כוללת את הלוקאל הראשי.

המגדר הדקדוקי של המשתמש. משמש לשפות שיש בהן מגדר דקדוקי.

לדוגמה, אם אתם צריכים לספק משאבים שונים למשתמשים דוברי צרפתית, אתם יכולים להשתמש בספריות כמו אלה:

res/
  values-fr/
    strings.xml (default strings with unspecified gender)
  values-fr-masculine/
    strings.xml (strings with masculine gender)
  values-fr-feminine/
    strings.xml (strings with feminine gender)
  values-fr-neuter/
    strings.xml (strings with neutral gender)

מידע נוסף מופיע בקטע לשון פנייה ב-Android.

אפשר גם לעיין בשיטת ההגדרה getGrammaticalGender(), שבה מצוין המגדר הדקדוקי.

נוסף ברמת API‏ 34.

כיוון הפריסה

ldrtl

ldltr

כיוון הפריסה של האפליקציה. ldrtl פירושו 'כיוון הפריסה מימין לשמאל'. ‫ldltr פירושו 'כיוון הפריסה משמאל לימין', וזהו ערך ברירת המחדל המרומז.

ההגדרה הזו יכולה לחול על כל משאב, כמו פריסות, משאבים שניתנים לציור או ערכים.

לדוגמה, אם רוצים לספק פריסה ספציפית לשפה הערבית ופריסה כללית לכל שפה אחרת שמוצגת מימין לשמאל, כמו פרסית או עברית, אפשר להשתמש בספריות כמו אלה:

‫res/
layout/
main.xml (פריסת ברירת מחדל)
layout-ar/
main.xml (פריסה ספציפית לערבית)
layout-ldrtl/
main.xml (כל שפה שנקראת מימין לשמאל, חוץ מערבית, כי לפרמטר להגדרת שפה 'ar' יש עדיפות גבוהה יותר)

הערה: כדי להפעיל תכונות של פריסה מימין לשמאל באפליקציה, צריך להגדיר את SupportsRtl לערך true ואת TargetSdkVersion לערך 17 ומעלה.

נוסף ברמת API‏ 17.

הרוחב הקטן ביותר

swdp

דוגמאות:

sw320dp

sw600dp

sw720dp

וכו'

המימד הקצר ביותר של אזור המסך שזמין לאפליקציה. באופן ספציפי, smallestWidth של חלון האפליקציה הוא הקצר מבין הגובה והרוחב הזמינים של החלון. אפשר גם לחשוב על זה כעל 'הרוחב המינימלי האפשרי' של החלון. אתם יכולים להשתמש במגביל הזה כדי להבטיח שרוחב ממשק המשתמש של האפליקציה יהיה לפחות dps.

לדוגמה, אם הפריסה שלכם דורשת שהמימד הקטן ביותר של אזור המסך יהיה לפחות 600dp בכל זמן, אתם יכולים להשתמש במאפיין הזה כדי ליצור את משאבי הפריסה בספרייה res/layout-sw600dp/. המערכת משתמשת במשאבים האלה רק כשהממד הקטן ביותר של המסך הזמין הוא לפחות 600dp, בלי קשר לשאלה אם הצד של 600dp הוא הגובה או הרוחב שנתפסים על ידי המשתמש. הרוחב הכי קטן יכול להשתנות אם משנים את הגודל של החלון, מה שמשנה את הרוחב או הגובה הזמינים, או אם משנים את המיקום שלו, מה שעשוי לשנות את השוליים הפנימיים של המערכת.

שימוש ברוחב הקטן ביותר כדי לקבוע את הגודל הכללי של המסך הוא שימושי, כי הרוחב הוא לרוב הגורם המניע בתכנון פריסה. בדרך כלל הממשק משתנה אנכית, אבל יש מגבלות די קשיחות לגבי המרחב המינימלי שהוא צריך אופקית.

הרוחב הזמין הוא גם הגורם העיקרי שקובע אם להשתמש בפריסת חלונית אחת בטלפונים ניידים או בפריסת חלונות מרובים בטאבלטים. לכן, סביר להניח שהכי חשוב לכם לדעת מה הרוחב הקטן ביותר האפשרי בכל מכשיר.

הרוחב הקטן ביותר של מכשיר לוקח בחשבון את הקישוטים של המסך ואת ממשק המשתמש של המערכת. לדוגמה, אם במכשיר יש רכיבי ממשק משתמש קבועים במסך שתופסים מקום לאורך הציר של הרוחב הקטן ביותר, המערכת תגדיר את הרוחב הקטן ביותר כקטן יותר מגודל המסך בפועל, כי אלה פיקסלים במסך שלא זמינים לממשק המשתמש שלכם.

כמה ערכים שאפשר להשתמש בהם כאן לגדלים נפוצים של מסכים:

• ‫320, למכשירים עם הגדרות מסך כמו:
• ‫240x320 ldpi (מכשיר QVGA)
• ‫320x480 mdpi (טלפון נייד)
• ‫‎480x800 hdpi (מכשיר נייד עם צפיפות גבוהה)
• ‫480, למסכים כמו 480x800 mdpi (טאבלט/טלפון)
• ‫600, למסכים כמו 600x1024 mdpi (טאבלט בגודל 7 אינץ')
• ‫720, למסכים כמו mdpi‏ 720x1280 (טאבלט בגודל 10 אינץ')

כשהאפליקציה מספקת כמה ספריות משאבים עם ערכים שונים של המסווג smallestWidth, המערכת משתמשת בספרייה שהערך שלה הכי קרוב לערך של smallestWidth במכשיר (בלי לחרוג ממנו).

נוסף ברמת API‏ 13.

אפשר גם לעיין במאפיין android:requiresSmallestWidthDp, שמצהיר על smallestWidth המינימלית שאיתה האפליקציה תואמת, ובשדה ההגדרה smallestScreenWidthDp, שמכיל את ערך smallestWidth של המכשיר.

מידע נוסף על עיצוב למסכים שונים באמצעות התנאי הזה זמין במאמר עיצוב רספונסיבי/אדפטיבי באמצעות תצוגות.

רוחב וגובה זמינים

wdp

hdp

דוגמאות:

w720dp

w1024dp

h720dp

h1024dp

וכו'

המאפיין הזה מציין את הרוחב או הגובה המינימליים של המסך (בdp יחידות שמוגדרות על ידי הערך ) שבהם נעשה שימוש במשאב. ערכי ההגדרה האלה מושווים לרוחב ולגובה הנוכחיים של המסך כשהכיוון של המכשיר משתנה בין לאורך לרוחב, כשהמכשיר מתקפל או נפתח, או כשהמערכת נכנסת למצב ריבוי חלונות או יוצאת ממנו. במצב ריבוי חלונות, הערכים משקפים את הרוחב והגובה של החלון שמכיל את האפליקציה, ולא את הרוחב והגובה של מסך המכשיר. באופן דומה, לגבי פעילויות מוטמעות, הערכים מתייחסים לרוחב ולגובה של הפעילויות הספציפיות, ולא לרוחב ולגובה של המסך. מידע נוסף זמין במאמר בנושא הטמעת פעילות.

הרוחב והגובה הזמינים שימושיים בדרך כלל כדי לקבוע אם להשתמש בפריסה מרובת חלונות, כי גם בטאבלט לרוב לא רוצים להשתמש באותה פריסה מרובת חלונות עבור מצב אנכי ועבור מצב אופקי. לכן, אפשר להשתמש בהם כדי לציין את הרוחב ו/או הגובה המינימליים שנדרשים לפריסה, במקום להשתמש בשני המסננים של גודל המסך והכיוון ביחד.

אם האפליקציה מספקת כמה ספריות משאבים עם ערכים שונים להגדרות האלה, המערכת משתמשת בספרייה שהערך שלה הכי קרוב לרוחב המסך הנוכחי של המכשיר (בלי לחרוג ממנו). הערך הכי קרוב ל- נקבע על ידי חיבור ההפרשים בין רוחב המסך בפועל לבין הרוחב שצוין, לבין ההפרש בין גובה המסך בפועל לבין הגובה שצוין. אם לא צוינו גובה ורוחב, הערך הוא 0.

הערכים לא כוללים את האזור שמוקצה לשוליים של חלון, כך שאם במכשיר יש רכיבי ממשק משתמש קבועים בקצוות המסך, הערכים של הרוחב והגובה קטנים יותר מהמידות האמיתיות של המסך, גם כשהאפליקציה מוצגת מקצה לקצה באמצעות Window.setDecorFitsSystemWindows או WindowCompat.setDecorFitsSystemWindows.

חלק מהקישוטים של המסך במצב אנכי שלא קבועים (כמו שורת הסטטוס של הטלפון שאפשר להסתיר אותה במסך מלא) לא נכללים כאן, וגם לא קישוטי חלונות כמו סרגל הכותרת או סרגל הפעולות. לכן, האפליקציות צריכות להיות מוכנות להתמודד עם שטח קטן יותר ממה שהן מציינות.

הערה: המערכת בוחרת את הנכס שתואם גם לרוחב וגם לגובה. לכן, עדיף להשתמש במשאב שמציין את שניהם מאשר במשאב שמציין רק אחד מהם. לדוגמה, אם המסך בפועל הוא ברוחב של 720dp ובגובה של 1280dp, ומשאב אחד מוגדר כ-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, שבה מצוין אם המסך עגול.

Wide Color Gamut

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: המכשיר מוצג בטלוויזיה, ומספק חוויה של צפייה ממרחק של 3 מטרים, שבה ממשק המשתמש מוצג על מסך גדול שהמשתמש נמצא רחוק ממנו, והחוויה מבוססת בעיקר על שימוש בכפתורי החיצים (D-pad) או באינטראקציה אחרת שאינה מבוססת על הצבעה
• ‫appliance: המכשיר משמש כמכשיר ביתי, ללא מסך
• ‫watch: למכשיר יש תצוגה והוא נלבש על פרק כף היד
• ‫vrheadset: המכשיר מוצג במשקפי מציאות מדומה

נוסף ברמת API‏ 8; טלוויזיה נוספה ב-API‏ 13; מכשיר ביתי נוסף ב-API‏ 16; שעון נוסף ב-API‏ 20; משקפי VR נוספו ב-API‏ 26.

לקבלת מידע על האופן שבו האפליקציה יכולה להגיב כשהמכשיר מוכנס או מוצא מאביזר עגינה, קראו את קביעת מצב וסוג העגינה ומעקב אחריהם.

הערך הזה יכול להשתנות במהלך השימוש באפליקציה אם המשתמש מניח את המכשיר במעמד. אפשר להפעיל או להשבית חלק מהמצבים האלה באמצעות UiModeManager. מידע על ההשפעה של השינוי הזה על האפליקציה במהלך זמן הריצה זמין במאמר טיפול בשינויים בהגדרות.

מצב לילה

night

notnight

• ‫night: בלילה
• ‫notnight: שעות היום

נוספה ברמת API‏ 8.

ההגדרה הזו יכולה להשתנות במהלך חיי האפליקציה אם מצב הלילה מוגדר למצב אוטומטי (ברירת מחדל). במקרה כזה, המצב משתנה בהתאם לשעה ביום. אפשר להפעיל או להשבית את המצב הזה באמצעות UiModeManager. מידע על ההשפעה של השינוי הזה על האפליקציה במהלך זמן הריצה זמין במאמר טיפול בשינויים בהגדרות.

צפיפות פיקסלים במסך (dpi)

ldpi

mdpi

hdpi

xhdpi

xxhdpi

xxxhdpi

nodpi

tvdpi

anydpi

nnndpi

• ‫ldpi: מסכים עם צפיפות פיקסלים נמוכה; בערך ‎120 dpi.
• ‫mdpi: מסכים בצפיפות בינונית (ב-HVGA מסורתי); בערך 160 dpi.
• ‫hdpi: מסכים עם צפיפות פיקסלים גבוהה; בערך 240 dpi.
• ‫xhdpi: מסכים עם צפיפות גבוהה במיוחד; בערך 320 dpi. נוספה ברמת API‏ 8.
• ‫xxhdpi: מסכים עם צפיפות גבוהה במיוחד; בערך 480 dpi. נוספה ברמת API‏ 16.
• ‫xxxhdpi: שימוש בצפיפות גבוהה במיוחד (רק בסמל של מרכז האפליקציות – ראו תמיכה בצפיפות פיקסלים שונה); בערך 640 dpi. נוסף ברמת API‏ 18.
• ‫nodpi: משמש למשאבי מפת סיביות שלא רוצים לשנות את הגודל שלהם כך שיתאים לצפיפות הפיקסלים של המכשיר.
• ‫tvdpi: מסכים ברזולוציה שבין mdpi ל-hdpi; בערך ‎213 dpi. הקבוצה הזו לא נחשבת לקבוצת צפיפות 'ראשונית'. היא מיועדת בעיקר לטלוויזיות באיכות 720p, ורוב האפליקציות לא צריכות אותה. במסכי טלוויזיה של 1080p, משתמשים ב-xhdpi, ובמסכי טלוויזיה של 4K, משתמשים ב-xxxhdpi. נוסף ברמת API‏ 13.
• ‫anydpi: מתאים לכל ערכי הדחיסות של המסך ויש לו עדיפות על פני מסננים אחרים. האפשרות הזו שימושית לפריטים גרפיים וקטוריים שניתנים לשרטוט. נוסף ברמת API‏ 21.
• ‫nnndpi: משמש לייצוג צפיפויות לא תקניות, כאשר nnn הוא מספר שלם חיובי של צפיפות המסך. ברוב המקרים לא משתמשים בזה. שימוש בדליים של צפיפות רגילה מפחית באופן משמעותי את התקורה של תמיכה בצפיפויות המסך השונות של המכשירים בשוק.

יש יחס קנה מידה של 3:4:6:8:12:16 בין שש הצפיפויות העיקריות (בלי להתייחס לצפיפות tvdpi). לכן, מפת סיביות בגודל 9x9 ב-ldpi היא 12x12 ב-mdpi,‏ 18x18 ב-hdpi,‏ 24x24 ב-xhdpi וכן הלאה.

הערה: שימוש במגדיר צפיפות לא מרמז שהמשאבים מיועדים רק למסכים עם הצפיפות הזו. אם לא מספקים משאבים חלופיים עם מסננים שתואמים יותר להגדרת המכשיר הנוכחית, המערכת משתמשת במשאבים שהם ההתאמה הטובה ביותר.

מידע נוסף על טיפול בדחיסויות מסך שונות ועל האופן שבו מערכת Android עשויה לשנות את קנה המידה של מפות הביטים כדי להתאים לדחיסות הנוכחית זמין במאמר סקירה כללית על תאימות מסך.

סוג מסך המגע

notouch

finger

• ‫notouch: למכשיר אין מסך מגע.
• ‫finger: למכשיר יש מסך מגע שמיועד לשימוש באמצעות אינטראקציה ישירה של האצבע של המשתמש.

אפשר גם לעיין בשדה ההגדרה touchscreen, שמציין את סוג מסך המגע במכשיר.

זמינות המקלדת

keysexposed

keyshidden

keyssoft

• ‫keysexposed: במכשיר יש מקלדת זמינה. אם במכשיר מופעלת מקלדת וירטואלית (מה שסביר להניח), המקלדת הזו תשמש גם אם המקלדת הפיזית לא מוצגת למשתמש או אם למכשיר אין מקלדת פיזית. אם לא מסופקת מקלדת וירטואלית או שהיא מושבתת, נעשה שימוש בהגדרה הזו רק כשהמקלדת הפיזית חשופה.
• ‫keyshidden: במכשיר יש מקלדת חומרה זמינה, אבל היא מוסתרת וגם במכשיר לא מופעלת מקלדת וירטואלית.
• ‫keyssoft: במכשיר מופעלת מקלדת וירטואלית, בין אם היא גלויה ובין אם לא.

אם מציינים משאבי keysexposed אבל לא משאבי keyssoft, המערכת משתמשת במשאבי keysexposed בלי קשר לשאלה אם המקלדת גלויה, כל עוד מופעלת במערכת מקלדת וירטואלית.

ההגדרה הזו יכולה להשתנות במהלך השימוש באפליקציה אם המשתמש פותח מקלדת חומרה. מידע על ההשפעה של השינוי הזה על האפליקציה במהלך זמן הריצה זמין במאמר טיפול בשינויים בהגדרות.

אפשר גם לעיין בשדות ההגדרה hardKeyboardHidden ו-keyboardHidden, שמציינים את רמת החשיפה של מקלדת חומרה ושל כל סוג של מקלדת (כולל תוכנה), בהתאמה.

שיטת קלט הטקסט העיקרית

nokeys

qwerty

12key

• ‫nokeys: למכשיר אין מקשי חומרה להזנת טקסט.
• ‫qwerty: למכשיר יש מקלדת QWERTY פיזית, בין אם היא גלויה למשתמש ובין אם לא.
• ‫12key: למכשיר יש מקלדת עם 12 מקשים, בין אם היא גלויה למשתמש ובין אם לא.

אפשר גם לעיין בשדה ההגדרה keyboard, שבו מצוינת שיטת הזנת הטקסט העיקרית שזמינה.

זמינות מקשי הניווט

navexposed

navhidden

• ‫navexposed: מקשי הניווט זמינים למשתמש.
• ‫navhidden: מקשי הניווט לא זמינים (למשל, אם המחשב נייד והמסך סגור).

ההגדרה הזו יכולה להשתנות במהלך השימוש באפליקציה אם המשתמש חושף את מקשי הניווט. מידע על ההשפעה של השינוי הזה על האפליקציה במהלך זמן הריצה זמין במאמר טיפול בשינויים בהגדרות.

אפשר גם לעיין בשדה ההגדרה navigationHidden, שבו מצוין אם מקשי הניווט מוסתרים.

שיטת הניווט העיקרית שאינה מבוססת על מגע

nonav

dpad

trackball

wheel

• ‫nonav: במכשיר אין אפשרות ניווט מלבד שימוש במסך המגע.
• ‫dpad: למכשיר יש כפתורי החיצים (D-pad) לניווט.
• ‫trackball: למכשיר יש כדור עקיבה לניווט.
• ‫wheel: למכשיר יש גלגל או גלגלים לניווט (לא נפוץ).

אפשר גם לעיין בשדה ההגדרה navigation, שבו מצוין סוג שיטת הניווט שזמינה.

גרסת פלטפורמה (רמת API)

דוגמאות:

v3

v4

v7

וכו'

רמת ה-API שנתמכת על ידי המכשיר. לדוגמה, v1 לרמת API‏ 1 (מכשירים עם Android 1.0 ומעלה) ו-v4 לרמת API‏ 4 (מכשירים עם Android 1.6 ומעלה). מידע נוסף על הערכים האלה זמין במאמר רמות Android API.