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

מערכת 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(), באופן הבא:

Kotlin

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

Java

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:

Kotlin

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

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

Kotlin

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()
}

Java

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 האלה.