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

מערכת ההפעלה 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 האלה.