סקירה כללית על תאימות המכשיר

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

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

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

מה המשמעות של 'תאימות'?

בפיתוח ל-Android יש שני סוגים של תאימות: תאימות למכשיר ותאימות לאפליקציה.

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

כמפתחי אפליקציות, אתם לא צריכים לדאוג אם מכשיר מסוים תואם ל-Android, כי רק מכשירים שתואמים ל-Android כוללים את חנות Google Play. לכן, אם משתמש מתקין את האפליקציה שלכם מחנות Google Play, הוא משתמש במכשיר שתואם ל-Android.

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

שליטה בזמינות של האפליקציה למכשירים

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

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

• תכונות המכשיר
• גרסת הפלטפורמה
• הגדרת המסך

תכונות המכשיר

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

אם יש צורך בכך, אפשר למנוע ממשתמשים להתקין את האפליקציה כשבמכשירים שלהם אין תכונה נדרשת. כדי לעשות זאת, צריך להצהיר על התכונה באמצעות רכיב <uses-feature> בקובץ המניפסט של האפליקציה.

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

<manifest ... >
    <uses-feature android:name="android.hardware.sensor.compass"
                  android:required="true" />
    ...
</manifest>

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

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

if (!packageManager.hasSystemFeature(PackageManager.FEATURE_SENSOR_COMPASS)) {
    // This device doesn't have a compass. Turn off the compass feature.
    disableCompassFeature()
}

PackageManager pm = getPackageManager();
if (!pm.hasSystemFeature(PackageManager.FEATURE_SENSOR_COMPASS)) {
    // This device doesn't have a compass. Turn off the compass feature.
    disableCompassFeature();
}

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

גירסת פלטפורמה

יכול להיות שבמכשירים שונים פועלות גרסאות שונות של פלטפורמת Android, כמו Android 12 או Android 13. בכל גרסה עוקבת של הפלטפורמה נוספים ממשקי API שלא זמינים בגרסה הקודמת. כדי לציין אילו ממשקי API זמינים, כל גרסת פלטפורמה מציינת רמת API. לדוגמה, Android 12 היא רמת API‏ 31, ו-Android 13 היא רמת API‏ 33.

צריך לציין את הערכים minSdkVersion ו-targetSdkVersion בקובץ build.gradle:

android {
    defaultConfig {
        applicationId = "com.example.myapp"

        // Defines the minimum API level required to run the app.
        minSdkVersion(30)

        // Specifies the API level used to test the app.
        targetSdkVersion(36)
        ...
    }
}

android {
    defaultConfig {
        applicationId 'com.example.myapp'

        // Defines the minimum API level required to run the app.
        minSdkVersion 30

        // Specifies the API level used to test the app.
        targetSdkVersion 36
        ...
    }
}

מידע נוסף על הקובץ build.gradle זמין במאמר הגדרת ה-build.

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

עם זאת, אם האפליקציה משתמשת בממשקי API שנוספו בגרסה עדכנית יותר של הפלטפורמה, אבל היא לא זקוקה להם כדי לבצע את הפונקציות העיקריות שלה, צריך לבדוק את רמת ה-API בזמן הריצה ולבצע שדרוג הדרגתי של התכונות המתאימות כשרמת ה-API נמוכה מדי. במקרה כזה, צריך להגדיר את minSdkVersion לערך הנמוך ביותר שאפשר עבור הפונקציונליות הראשית של האפליקציה, ואז להשוות את גרסת המערכת הנוכחית, SDK_INT, לקבוע את שם הקוד ב-Build.VERSION_CODES שתואם לרמת ה-API שרוצים לבדוק, כמו שמוצג בדוגמה הבאה:

if (Build.VERSION.SDK_INT < Build.VERSION_CODES.HONEYCOMB) {
    // Running on something older than API level 11, so disable
    // the drag and drop features that use ClipboardManager APIs.
    disableDragAndDrop()
}

if (Build.VERSION.SDK_INT < Build.VERSION_CODES.HONEYCOMB) {
    // Running on something older than API level 11, so disable
    // the drag and drop features that use ClipboardManager APIs.
    disableDragAndDrop();
}

הגדרת תצורה של מסך

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

• ארבעה גדלים כלליים: קטן, רגיל, גדול וגדול במיוחד
• כמה צפיפויות כלליות: mdpi (בינונית), hdpi (גבוהה), xhdpi (גבוהה במיוחד), xxhdpi (גבוהה במיוחד) ועוד

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

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

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

שליטה בזמינות של האפליקציה מסיבות עסקיות

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

סינון לצורך תאימות טכנית – כמו רכיבי חומרה נדרשים – תמיד מבוסס על מידע שכלול בקובץ ה-APK או AAB. אבל סינון מסיבות לא טכניות – כמו מיקום גיאוגרפי – תמיד מתבצע ב-Google Play Console.

מקורות מידע נוספים:

סקירה כללית על משאבי אפליקציות

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

מסננים ב-Google Play

מידע על הדרכים השונות שבהן חנות Google Play יכולה למנוע את ההתקנה של האפליקציה במכשירים שונים.

הרשאות ב-Android

איך מערכת ההרשאות של Android מגבילה את הגישה של אפליקציות לממשקי API מסוימים, ומחייבת את המשתמשים להסכים לשימוש של האפליקציה בממשקי ה-API האלה.