תמיכה בחבילות APK מרובות

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

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

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

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

פרסום האפליקציה עם כמה חבילות APK מאפשר לכם:

• תמיכה בפורמטים שונים של דחיסת טקסטורות של OpenGL בכל חבילת APK.
• תמיכה בגדלים ובדחיסות שונים של מסכים בכל קובץ APK.
• תמיכה בקבוצות שונות של תכונות של מכשירים בכל קובץ APK.
• תמיכה בגרסאות שונות של פלטפורמות בכל קובץ APK.
• תמיכה בארכיטקטורות שונות של מעבדים (CPU) בכל קובץ APK (למשל, ARM או x86, אם האפליקציה משתמשת ב-Android NDK).
• לבצע אופטימיזציה למכשירים ברמה בסיסית, כמו מכשירים עם Android (מהדורת Go).

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

הערה: במאמר התמיכה הכנה והשקה של גרסאות מוסבר איך מכינים ומפרסמים חבילות APK ב-Google Play.

איך פועלות כמה חבילות APK

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

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

מסננים נתמכים

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

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

  האפשרות הזו מבוססת על הרכיבים <supports-gl-texture> בקובץ המניפסט.

  לדוגמה, כשמפתחים משחק שמשתמש ב-OpenGL ES, אפשר לספק קובץ APK אחד למכשירים שתומכים ב-ATI texture compression וקובץ APK נפרד למכשירים שתומכים ב-PowerVR compression (בין היתר).

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

  האפשרות הזו מבוססת על הרכיב <supports-screens> או <compatible-screens> בקובץ המניפסט. לעולם אל תשתמשו בשני הרכיבים, ותשתמשו רק ב-<supports-screens> כשהדבר אפשרי.

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

  כדי לתמוך בכל גודלי המסכים, כדאי לפעול לפי השיטות המומלצות הבאות:

  • מערכת Android מספקת תמיכה חזקה לאפליקציות כדי לתמוך בכל הגדרות המסך באמצעות קובץ APK יחיד. מומלץ להימנע משימוש בכמה חבילות APK כדי לתמוך במסכים שונים, אלא אם יש צורך בכך באופן מוחלט. במקום זאת, כדאי לפעול לפי ההוראות במדריך תמיכה במספר מסכים כדי שהאפליקציה תהיה גמישה ותוכל להתאים את עצמה לכל הגדרות המסך באמצעות חבילת APK אחת.
  • כברירת מחדל, כל המאפיינים של גודל המסך ברכיב <supports-screens> הם 'true', אלא אם מצהירים אחרת. עם זאת, מכיוון שהמאפיין android:xlargeScreens נוסף ב-Android 2.3 (רמת API 9), Google Play יסיק שהוא 'false' אם האפליקציה לא תגדיר את הערך android:minSdkVersion או את הערך android:targetSdkVersion לערך '9' או יותר.
  • אסור לשלב בקובץ המניפסט את הרכיבים <supports-screens> ו- <compatible-screens>. שימוש בשניהם מגביר את הסיכוי להופעת שגיאה עקב קונפליקט ביניהם. במאמר הפצה למסכים ספציפיים מוסבר איך להחליט באיזה מסך להשתמש. אם אי אפשר להימנע משימוש בשניהם, חשוב לדעת שבמקרה של התנגשויות בהסכם לגבי גודל נתון, הערך 'false' ינצח.

• קבוצות תכונות של מכשירים

  הנתון הזה מבוסס על הרכיבים של <uses-feature> בקובץ המניפסט.

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

• Android (Go edition)

  כדי לטרגט מכשירים עם Android (מהדורת Go), קובץ ה-APK צריך להצהיר על <uses-feature android:name="android.hardware.ram.low" android:required="true">, לטרגט לפחות לרמת API 26 ולכלול קוד גרסה גבוה יותר מקוד הגרסה של קובץ ה-APK מהמהדורה שאינה Go.

• רמת ה-API

  המידע הזה מבוסס על הרכיב <uses-sdk> בקובץ המניפסט. אפשר להשתמש גם במאפיין android:minSdkVersion וגם במאפיין android:maxSdkVersion כדי לציין תמיכה ברמות API שונות.

  לדוגמה, אפשר לפרסם את האפליקציה עם קובץ APK אחד שתומך ברמות API‏ 16 עד 19 (Android 4.1.x עד 4.4.4) – באמצעות ממשקי API שזמינים החל מרמת API‏ 16 ומטה – ועם קובץ APK נוסף שתומך ברמות API‏ 21 ומעלה (Android 5.0 ואילך) – באמצעות ממשקי API שזמינים החל מרמת API‏ 21 ומטה. במאמר הגדרת טעמי מוצרים מוסבר איך ליצור קובצי APK נפרדים, שכל אחד מהם מטרגט טווח אחר של ממשקי API.

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

  באופן כללי, מומלץ להימנע משימוש ב- android:maxSdkVersion, כי כל עוד האפליקציה פותחה בצורה תקינה באמצעות ממשקי API ציבוריים, היא תמיד תהיה תואמת לגרסאות עתידיות של Android. אם רוצים לפרסם APK שונה לרמות API גבוהות יותר, עדיין לא צריך לציין את הגרסה המקסימלית. אם הערך של android:minSdkVersion הוא "16" ב-APK אחד ו-"21" ב-APK אחר, מכשירים שתומכים ברמת API 21 ואילך תמיד יקבלו את ה-APK השני (כי קוד הגרסה שלו גבוה יותר, בהתאם להערה הקודמת).



• ארכיטקטורת CPU (ABI)

  חלק מהספריות הילידיות מספקות חבילות נפרדות לארכיטקטורות ספציפיות של מעבדים או לממשקי Application Binary (ABI). במקום לארוז את כל הספריות הזמינות בקובץ APK אחד, אפשר ליצור קובץ APK נפרד לכל ABI ולכלול רק את הספריות שנדרשות ל-ABI הזה. מידע נוסף על יצירת חבילות APK נפרדות על סמך ממשק ABI היעד זמין במאמר יצירת כמה חבילות APK.

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

כללים לכמה חבילות APK

לפני שמפרסמים כמה קובצי APK לאפליקציה, צריך להבין את הכללים הבאים:

• לכל חבילות ה-APK שאתם מפרסמים לאותה אפליקציה חייב להיות שם חבילה זהה, והן חייבות להיות חתומות באותו מפתח אישור.
• לכל קובץ APK חייב להיות קוד גירסה שונה, שמצוין במאפיין android:versionCode.
• אין צורך שכל חבילה תהיה זהה לחלוטין לתמיכה בתצורה של חבילה אחרת.

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

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

• לא ניתן להפעיל APK חדש עם קוד גרסה נמוך מקוד הגרסה של ה-APK שהוא מחליף. לדוגמה, נניח שיש לכם APK פעיל לגדלי מסך קטן עד רגיל עם קוד גרסה 0400, ואתם מנסים להחליף אותו ב-APK לאותו גודל מסך עם קוד גרסה 0300. כתוצאה מכך מתקבלת הודעת שגיאה, כי משתמשים של קובץ ה-APK הקודם לא יוכלו לעדכן את האפליקציה.
• לחבילת APK שנדרשת לה רמת API גבוהה יותר צריך להיות קוד גרסה גבוה יותר.

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

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

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

  הנה כמה דוגמאות:

  • אם קובץ ה-APK שהעליתם לרמות API ‏16 ואילך (Android 4.1.x ואילך) כולל קוד גרסה 0400, קובץ ה-APK לרמות API ‏21 ואילך (Android 5.0 ואילך) צריך לכלול קוד גרסה 0401 ואילך. במקרה כזה, רמת ה-API היא הסינון היחיד שנתמך, ולכן קוד הגרסה צריך לעלות בהתאם לתמיכה ברמת ה-API של כל APK, כדי שהמשתמשים יקבלו עדכון כשהם מקבלים עדכון מערכת.
  • אם יש לכם קובץ APK אחד לרמת API ‏16 (ומעלה) ו למסכים קטנים עד גדולים, וקובץ APK אחר לרמת API ‏21 (ומעלה) ו למסכים גדולים עד גדולים במיוחד, קודי הגרסה צריכים לעלות בהתאם לרמות ה-API. במקרה כזה, המסנן ברמת ה-API משמש להבדיל בין כל קובץ APK, אבל גם גודל המסך משמש לכך. מכיוון שגדלי המסכים חופפים (שני קובצי ה-APK תומכים במסכים גדולים), עדיין צריך להקפיד על הסדר של קודי הגרסאות. כך תוכלו להבטיח שמכשיר עם מסך גדול שמקבל עדכון מערכת לרמת API ‏21 יקבל עדכון ל-APK השני.
  • אם יש לכם קובץ APK אחד לרמת API ‏16 (ומעלה) וגם למסכים קטנים עד רגילים, וקובץ APK אחר לרמת API ‏21 (ומעלה) וגם למסכים גדולים עד גדולים במיוחד, אין צורך להגדיל את קודי הגרסה בהתאם לרמות ה-API. מכיוון שאין חפיפה בפילטר של גודל המסך, אין מכשירים שיכולים לעבור בין שתי חבילות ה-APK האלה, ולכן אין צורך להגדיל את קודי הגרסה מרמת ה-API הנמוכה לרמת ה-API הגבוהה.
  • אם יש לכם קובץ APK אחד שמיועד ל-API ברמה 16 (ומעלה) ו למעבדי ARMv7, וקובץ APK אחר שמיועד ל-API ברמה 21 (ומעלה) ו למעבדי ARMv5TE, קודי הגרסה צריכים לעלות בהתאם לרמות ה-API. במקרה כזה, המסנן ברמת ה-API משמש להבדיל בין כל קובץ APK, אבל גם ארכיטקטורת המעבד. מכיוון ש-APK עם ספריות ARMv5TE תואם למכשירים עם מעבד ARMv7, יש חפיפה בין חבילות ה-APK במאפיין הזה. לכן, קוד הגרסה של קובץ ה-APK שתומך ברמת API 21 ואילך צריך להיות גבוה יותר. כך מובטח שמכשיר עם מעבד ARMv7 שמקבל עדכון מערכת לרמת API‏ 21 יקבל עדכון לחבילת ה-APK השנייה שמיועדת לרמת API‏ 21. עם זאת, מכיוון שעדכון כזה גורם לשימוש במכשיר ARMv7 ב-APK שלא עבר אופטימיזציה מלאה עבור המעבד של המכשיר, צריך לספק קובץ APK גם לארכיטקטורה ARMv5TE וגם לארכיטקטורה ARMv7 בכל רמת API כדי לבצע אופטימיזציה של ביצועי האפליקציה בכל מעבד. הערה: ההשוואה הזו רלוונטית רק כשמשווים בין קובצי APK לספריות ARMv5TE ו-ARMv7, ולא כשמשווים בין ספריות מקומיות אחרות.

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

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

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

  הערה: אם אתם יוצרים קובצי APK נפרדים לארכיטקטורות שונות של מעבדים, חשוב לדעת שקובץ APK ל-ARMv5TE יחפיף על קובץ APK ל-ARMv7. כלומר, קובץ APK שמיועד ל-ARMv5TE תואם למכשיר ARMv7, אבל ההפך לא נכון (קובץ APK עם ספריות ARMv7 בלבד לא תואם למכשיר ARMv5TE).

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

יצירת כמה חבילות APK

אם תחליטו לפרסם כמה קובצי APK, סביר להניח שתצטרכו ליצור פרויקטים נפרדים ל-Android לכל קובץ APK שאתם מתכוונים לפרסם, כדי שתוכלו לפתח אותם בנפרד. כדי לעשות זאת, פשוט מעתיקים את הפרויקט הקיים ומעניקים לו שם חדש. (לחלופין, אפשר להשתמש במערכת build שיכולה להפיק משאבים שונים – כמו טקסטורות – על סמך הגדרת ה-build).

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

כשאתם יוצרים כמה פרויקטים לאותה אפליקציה, מומלץ לזהות כל אחד מהם בשם שמציין את הגבלות המכשיר שיחולו על קובץ ה-APK, כדי שתוכלו לזהות אותם בקלות. לדוגמה, 'HelloWorld_21' יכול להיות שם טוב לאפליקציה שמיועדת לרמת API 21 ומעלה.

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

הקצאת קודי גרסאות

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

הזמנה של קודי גרסאות

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

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

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

בנוסף, כשאתם יוצרים כמה קובצי APK שונים בהתאם לתמיכה בפורמטים שונים של דחיסת טקסטורות של OpenGL, חשוב לזכור שמכשירים רבים תומכים בכמה פורמטים. מכיוון שמכשיר מקבל את קובץ ה-APK עם קוד הגרסה הגבוה ביותר כשיש חפיפה בפריסה בין שתי חבילות APK, צריך למיין את קודי הגרסאות של חבילות ה-APK כך שקובץ ה-APK עם פורמט הקידוד המועדף יהיה בעל קוד הגרסה הגבוה ביותר. לדוגמה, יכול להיות שתרצו ליצור גרסאות build נפרדות לאפליקציה שלכם באמצעות פורמטים של דחיסה PVRTC,‏ ATITC ו-ETC1. אם אתם מעדיפים את הפורמטים האלה בסדר הזה, ל-APK שמשתמש ב-PVRTC צריך להיות קוד הגרסה הגבוה ביותר, ל-APK שמשתמש ב-ATITC צריך להיות קוד גרסה נמוך יותר ולגרסה עם ETC1 צריך להיות קוד הגרסה הנמוך ביותר. לכן, אם מכשיר תומך גם ב-PVRTC וגם ב-ETC1, הוא יקבל את קובץ ה-APK עם PVRTC כי יש לו את קוד הגרסה הגבוה ביותר.

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

שימוש בסכימה של קוד גרסה

כדי לאפשר לחבילות APK שונות לעדכן את קודי הגרסאות שלהן בנפרד מהאחרות (לדוגמה, כשמתקנים באג רק ב-APK אחד, כך שאין צורך לעדכן את כל חבילות ה-APK), צריך להשתמש בסכמה של קודי הגרסאות שמספקת מספיק מקום בין כל APK, כדי שתוכלו להגדיל את הקוד באחד בלי שתצטרכו להגדיל אותו באחרים. כדאי לכלול בקוד גם את שם הגרסה בפועל (כלומר הגרסה שגלויה למשתמשים ומוקצה ל-android:versionName), כדי שיהיה קל לשייך את קוד הגרסה לשם הגרסה.

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

מומלץ להשתמש בקוד גרסה עם 7 ספרות לפחות: מספרים שלמים שמייצגים את ההגדרות הנתמכות נמצאים בביטים ברמה הגבוהה יותר, ושם הגרסה (מ-android:versionName) נמצא בביטים ברמה הנמוכה יותר. לדוגמה, כששם גרסת האפליקציה הוא 3.1.0, קודי הגרסה של קובץ APK ברמת API 4 וקובץ APK ברמת API 11 יהיו דומים ל-0400310 ול-1100310, בהתאמה. שתי הספרות הראשונות מיועדות לרמת ה-API (4 ו-11, בהתאמה), שתי הספרות האמצעיות מיועדות לגדלי מסך או לפורמטים של טקסטורות GL (לא נעשה בהן שימוש בדוגמאות האלה), ושלוש הספרות האחרונות מיועדות לשם הגרסה של האפליקציה (3.1.0). באיור 1 מוצגות שתי דוגמאות לפיצול שמבוסס גם על גרסת הפלטפורמה (רמת ה-API) וגם על גודל המסך.

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

הסכימה הזו של קודי הגרסאות היא רק הצעה לאופן שבו כדאי ליצור דפוס שניתן להתאמה ככל שהאפליקציה תתפתח. באופן ספציפי, התוכנית הזו לא מציגה פתרון לזיהוי פורמטים שונים של דחיסת טקסטורות. אפשרות אחת היא להגדיר טבלה משלכם שמציינת מספר שלם שונה לכל אחד מפורמטי הדחיסה השונים שהאפליקציה תומכת בהם (לדוגמה, 1 עשוי להתאים ל-ETC1 ו-2 הוא ATITC וכן הלאה).

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