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

מערכת 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" ולבדוק את התכונה במכשיר בזמן הריצה. אם תכונה מסוימת באפליקציה לא זמינה במכשיר הנוכחי, צריך להפחית את התכונה המתאימה באפליקציה בצורה חיננית (graceful degradation). לדוגמה, אתם יכולים לבדוק אם תכונה מסוימת זמינה באמצעות קריאה ל-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 של גרסאות קודמות של הפלטפורמה. לכן, אם אתם משתמשים בממשקי ה-API המתועדים של Android, האפליקציה שלכם תואמת לגרסאות עתידיות של 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 מכלילה את הווריאציות האלה בקבוצות שמקלות על הטירגוט שלהן:

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

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

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

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

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

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

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

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

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

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

מסננים ב-Google Play

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

הרשאות ב-Android

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