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

מערכת ההפעלה 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 תוך שימוש בממשקי ה-API המתוועדים של Android.

עם זאת, אם האפליקציה שלכם משתמשת בממשקי 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 מכלה את הווריאציות האלה בקבוצות כדי שיהיה קל יותר לטרגט אותן:

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

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

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

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

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

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

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

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

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

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

מסננים ב-Google Play

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

הרשאות ב-Android

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