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

מערכת 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(33)
        ...
    }
}

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 33
        ...
    }
}

מידע נוסף על קובץ 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 האלה.