מסננים ב-Google Play

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

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

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

איך פועלים המסננים ב-Google Play

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

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

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

אתם יכולים להשתמש בכל שילוב של המסננים הזמינים לאפליקציה. לדוגמה, אפשר להגדיר minSdkVersion עם "4" ולהגדיר smallScreens="false" באפליקציה. לאחר מכן, כשאתם מעלים את האפליקציה ל-Google Play, תוכלו לטרגט רק מדינות (ספקים) באירופה. כך, המסננים של Google Play ימנעו את הזמינות של האפליקציה בכל מכשיר שלא עומד בכל שלוש הדרישות האלה.

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

סינון באתר של Google Play

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

סינון לפי המניפסט של האפליקציה

רוב המסננים מופעלים על ידי רכיבים בקובץ המניפסט של האפליקציה, AndroidManifest.xml (אבל לא כל מה שקיים בקובץ המניפסט יכול להפעיל סינון). בטבלה 1 מפורטים רכיבי המניפסט שבהם צריך להשתמש כדי להפעיל את הסינון, ומוסבר איך פועל הסינון בכל רכיב.

טבלה 1. רכיבי מניפסט שמפעילים סינון ב-Google Play.

רכיב מניפסט שם המסנן כיצד זה עובד
<supports-screens> גודל מסך

כדי לציין את גדלי המסכים שהאפליקציה תומכת בהם, צריך להגדיר מאפיינים של הרכיב <supports-screens>. כשהאפליקציה תפורסם, מערכת Google Play תשתמש במאפיינים האלה כדי לקבוע אם להציג את האפליקציה למשתמשים, על סמך גדלי המסכים של המכשירים שלהם.

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

אם אפליקציה לא מצהירה על מאפיינים עבור <supports-screens>, Google Play משתמשת בערכי ברירת המחדל של המאפיינים האלה, שמשתנים בהתאם לרמת ה-API. פרטים נוספים:

  • באפליקציות שמגדירות את android: minSdkVersion או את android: targetSdkVersion ל-3 או פחות, הרכיב <supports-screens> עצמו לא מוגדר ואין מאפיינים זמינים. במקרה כזה, Google Play מניחה שהאפליקציה מיועדת למסכים בגודל רגיל, ומציגה אותה במכשירים עם מסכים בגודל רגיל או גדול יותר.
  • כשהערך של android: minSdkVersion או android: targetSdkVersion מוגדר ל-4 ומעלה, ברירת המחדל של כל המאפיינים היא "true". כך, האפליקציה נחשבת כתומכת בכל גדלי המסכים כברירת מחדל.

דוגמה 1
המניפסט מצהיר על <uses-sdk android:minSdkVersion="3"> ואינו כולל רכיב <supports-screens>. תוצאה: האפליקציה לא תוצג ב-Google Play למשתמש שמשתמש במכשיר עם מסך קטן, אבל תוצג למשתמשים במכשירים עם מסך רגיל או גדול, אלא אם חל מסנן אחר.

דוגמה 2
המניפסט מצהיר על <uses-sdk android:minSdkVersion="3" android:targetSdkVersion="4"> ולא כולל רכיב <supports-screens>. תוצאה: האפליקציה תוצג למשתמשים ב-Google Play בכל המכשירים, אלא אם יהיו מסננים אחרים שחלים עליה.

דוגמה 3
המניפסט מצהיר על <uses-sdk android:minSdkVersion="4"> ואינו כולל רכיב <supports-screens>. תוצאה: האפליקציה תוצג ב-Google Play לכל המשתמשים, אלא אם יהיו סינונים אחרים שחלים עליה.

למידע נוסף על הצהרת תמיכה בגדלי מסך באפליקציה, ראו <supports-screens> ותמיכה במספר מסכים.

<uses-configuration> הגדרת המכשיר:
מקלדת, ניווט, מסך מגע

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

דוגמה 1
המניפסט כולל את <uses-configuration android:reqFiveWayNav="true" />, ומשתמש מחפש אפליקציות במכשיר שאין בו פקדי ניווט לחמש כיוונים. תוצאה: האפליקציה לא תוצג למשתמש ב-Google Play.

דוגמה 2
המניפסט לא כולל רכיב <uses-configuration>. תוצאה: האפליקציה תוצג ב-Google Play לכל המשתמשים, אלא אם חל סינון אחר.

פרטים נוספים זמינים במאמר <uses-configuration>.

<uses-feature> תכונות המכשיר
(name)

יכול להיות שאפליקציה תדרוש תכונות מסוימות במכשיר. הפונקציונליות הזו הושקה ב-Android 2.0 (רמה 5 של API).

דוגמה 1
המניפסט כולל את <uses-feature android:name="android.hardware.sensor.light" />, ומשתמש מחפש אפליקציות במכשיר שאין בו חיישן אור. תוצאה: האפליקציה לא תוצג למשתמש ב-Google Play.

דוגמה 2
המניפסט לא כולל רכיב <uses-feature>. תוצאה: האפליקציה תוצג ב-Google Play לכל המשתמשים, אלא אם חל סינון אחר.

מידע מלא זמין במאמר <uses-feature> .

סינון על סמך תכונות משתמעות: במקרים מסוימים, Google Play מפרשת הרשאות שמבוקשות באמצעות רכיבי <uses-permission> כדרישות לתכונות שדומות לאלה שמוצהרות ברכיבי <uses-feature>. מידע נוסף זמין בקטע <uses-permission> בהמשך.

OpenGL-ES גרסה
(openGlEsVersion)

אפליקציה יכולה לדרוש שהמכשיר יתמוך בגרסה ספציפית של OpenGL-ES באמצעות המאפיין <uses-feature android:openGlEsVersion="int">.

דוגמה 1
אפליקציה מבקשת כמה גרסאות של OpenGL-ES על ידי ציון openGlEsVersion כמה פעמים במניפסט. תוצאה: מערכת Google Play מניחה שהאפליקציה דורשת את הגרסה הגבוהה ביותר מבין הגרסאות שצוינו.

דוגמה 2
אפליקציה מבקשת את OpenGL-ES בגרסה 1.1, ומשתמש מחפש אפליקציות במכשיר שתומך ב-OpenGL-ES בגרסה 2.0. תוצאה: האפליקציה תוצג למשתמש ב-Google Play, אלא אם יהיו מסננים אחרים שחלים עליה. אם מכשיר מדווח שהוא תומך ב-OpenGL-ES בגרסה X, Google Play יוצא מנקודת הנחה שהוא תומך גם בכל גרסה שקדמה ל-X.

דוגמה 3
משתמש מחפש אפליקציות במכשיר שלא מדווח על גרסת OpenGL-ES (לדוגמה, מכשיר עם Android 1.5 ואילך). תוצאה: Google Play מניחה שהמכשיר תומך רק ב-OpenGL-ES 1.0. ב-Google Play יוצגו רק אפליקציות של משתמשים שלא מציינות את openGlEsVersion, או אפליקציות שלא מציינות גרסת OpenGL-ES גבוהה מ-1.0.

דוגמה 4
במניפסט לא צוין openGlEsVersion. תוצאה: האפליקציה תוצג ב-Google Play לכל המשתמשים, אלא אם חל סינון אחר.

פרטים נוספים זמינים במאמר <uses-feature>.

<uses-library> ספריות תוכנה

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

דוגמה 1
אפליקציה דורשת את הספרייה com.google.android.maps, ומשתמש מחפש אפליקציות במכשיר שבו לא מותקנת הספרייה com.google.android.maps. תוצאה: האפליקציה לא תוצג למשתמש ב-Google Play.

דוגמה 2
המניפסט לא כולל רכיב <uses-library>. תוצאה: האפליקציה תוצג ב-Google Play לכל המשתמשים, אלא אם חל סינון אחר.

פרטים נוספים זמינים במאמר <uses-library>.

<uses-permission>  

למעשה, Google Play לא מסנן על סמך רכיבי <uses-permission>. עם זאת, הוא קורא את הרכיבים כדי לקבוע אם יש לאפליקציה דרישות למאפייני חומרה שלא הוגדרו כראוי ברכיבי <uses-feature>. לדוגמה, אם אפליקציה מבקשת את ההרשאה CAMERA אבל לא מצהירה על רכיב <uses-feature> עבור android.hardware.camera, מערכת Google Play מתייחסת לאפליקציה כאל אפליקציה שדורשת מצלמה, ואסור להציג אותה למשתמשים שהמכשירים שלהם לא כוללים מצלמה.

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

רשימה של הרשאות שמציינות תכונות חומרה מופיעה במסמכי התיעוד של האלמנט <uses-feature>.

<uses-sdk> גרסת המסגרת המינימלית (minSdkVersion)

אפליקציה יכולה לדרוש רמת API מינימלית.

דוגמה 1
המניפסט כולל את <uses-sdk android:minSdkVersion="3">, והאפליקציה משתמשת בממשקי API שהוצגו ברמת API 3. משתמש מחפש אפליקציות במכשיר עם רמת API 2. תוצאה: האפליקציה לא תוצג למשתמש ב-Google Play.

דוגמה 2
המניפסט לא כולל את minSdkVersion, והאפליקציה משתמשת בממשקי API שהוצגו ברמת API 3. משתמש מחפש אפליקציות במכשיר עם רמת API 2. תוצאה: מערכת Google Play מניחה שהערך של minSdkVersion הוא '1' והאפליקציה תואמת לכל הגרסאות של Android. האפליקציה מוצגת למשתמש ב-Google Play והמשתמש יכול להוריד אותה. האפליקציה קורסת בזמן הריצה.

כדי להימנע מהתרחיש השני, מומלץ תמיד להצהיר על minSdkVersion. פרטים נוספים זמינים במאמר android:minSdkVersion.

גרסת Framework מקסימלית (maxSdkVersion)

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

לא מומלץ להצהיר על maxSdkVersion. פרטים נוספים זמינים במאמר android:maxSdkVersion.

מסנני מניפסט מתקדמים

בנוסף לרכיבי המניפסט שמפורטים בטבלה 1, מערכת Google Play יכולה לסנן אפליקציות גם על סמך רכיבי המניפסט המתקדמים שמפורטים בטבלה 2.

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

טבלה 2. רכיבי מניפסט מתקדמים לסינון ב-Google Play.

רכיב מניפסטסיכום
<compatible-screens>

Google Play מסנן את האפליקציה אם גודל המסך וצפיפות המסך של המכשיר לא תואמים לאף אחת מההגדרות של המסך (שמוצגות על ידי רכיב <screen>) ברכיב <compatible-screens>.

זהירות: בדרך כלל לא מומלץ להשתמש ברכיב המניפסט הזה. השימוש ברכיב הזה יכול לצמצם באופן משמעותי את בסיס המשתמשים הפוטנציאלי של האפליקציה, על ידי החרגת כל השילובים של צפיפות וגודל המסך שלא ציינתם. במקום זאת, צריך להשתמש ברכיב המניפסט <supports-screens> (שתואר למעלה בטבלה 1) כדי להפעיל את מצב תאימות המסך עבור הגדרות מסך שלא תיחשבו באמצעות משאבים חלופיים.

<supports-gl-texture>

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

מסננים אחרים

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

טבלה 3 מאפייני האפליקציה והפרסום שמשפיעים על הסינון ב-Google Play.

שם המסנן כיצד זה עובד
סטטוס הפרסום

רק אפליקציות שפורסמו יופיעו בחיפושים ובגלישה ב-Google Play.

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

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

סטטוס מחיר

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

טירגוט לפי מדינה

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

ארכיטקטורת המעבד (ABI)

אפליקציה שכוללת ספריות מקוריות שמטרגטות ארכיטקטורה ספציפית של מעבד (לדוגמה, ARM EABI v7 או x86) גלויה רק במכשירים שתומכים בארכיטקטורה הזו. פרטים על NDK ועל שימוש בספריות מקומיות זמינים במאמר מהו Android NDK?

אפליקציות מוגנות בפני העתקה

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

פרסום כמה חבילות APK עם מסננים שונים

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

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

  • פורמטים של דחיסת טקסטורות ב-OpenGL

    באמצעות הרכיב <supports-gl-texture>.

  • גודל המסך (ואם רוצים, גם דחיסות המסך)

    באמצעות הרכיב <supports-screens> או <compatible-screens>.

  • רמת ממשק API:

    באמצעות הרכיב <uses-sdk>.

  • ארכיטקטורת המעבד (ABI)

    על ידי הכללת ספריות מקומיות שנוצרו באמצעות Android NDK ומיועדות לארכיטקטורת מעבד ספציפית (לדוגמה, ARM EABI v7 או x86).

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

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

מידע נוסף על פרסום כמה חבילות APK ב-Google Play זמין במאמר תמיכה בכמה חבילות APK.

למידע נוסף

  1. תאימות ל-Android
  2. תמיכה בכמה חבילות APK