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

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() כך:

KotlinJava
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:

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

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

KotlinJava
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, הוא מכלל את הווריאנטים האלה בקבוצות שגורמות להם קל יותר לטירגוט:

  • ארבעה גדלים כלליים: Small, Standard, Large ו-xlarge
  • כמה דחיסות כללית: mdpi (בינונית), hdpi (גבוהה), xhdpi (גבוהה גבוהה), xxhdpi (גבוהה במיוחד) ועוד

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

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

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

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

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

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

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

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