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

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

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.

הערה: חלק מההרשאות המערכתיות מחייבות באופן משתמע את הזמינות של תכונה במכשיר. לדוגמה, אם האפליקציה מבקשת הרשאת גישה ל-BLUETOOTH, היא דורשת באופן משתמע את תכונת המכשיר FEATURE_BLUETOOTH. כדי להשבית את הסינון על סמך התכונה הזו ולהפוך את האפליקציה לזמינה למכשירים ללא Bluetooth, מגדירים את המאפיין required לערך "false" בתג <uses-feature>. למידע נוסף על תכונות המכשיר הנדרשות באופן משתמע, קראו את המאמר הרשאות שמציינות דרישות תכונות.

גירסת פלטפורמה

במכשירים שונים יכולות לפעול גרסאות שונות של פלטפורמת 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(33)
        ...
    }
}

Groovy

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.

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

עם זאת, אם האפליקציה שלכם משתמשת בממשקי 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 (גבוה במיוחד במיוחד) ועוד

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

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

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

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

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

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

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

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

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

מסננים ב-Google Play

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

הרשאות ב-Android

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