אם אתם מפרסמים את האפליקציה ב-Google Play, עליכם ליצור קובץ Android App Bundle ולהעלות אותו. כשעושים זאת, Google Play יוצרת ומציגה באופן אוטומטי חבילות APK שעברו אופטימיזציה לכל תצורת מכשיר של משתמש, כך שהם מורידים רק את הקוד והמשאבים הנדרשים להפעלת האפליקציה. פרסום של כמה חבילות APK שימושי אם אתם לא מפרסמים ב-Google Play, אבל עליכם ליצור, לחתום ולנהל כל אחת מהן בעצמכם.
כשאתם מפתחים אפליקציה ל-Android כדי לנצל את היתרונות של כמה קובצי APK ב-Google Play, חשוב לאמץ כמה שיטות מומלצות כבר מההתחלה כדי למנוע כאבי ראש מיותרים בהמשך תהליך הפיתוח. במדריך הזה תלמדו איך ליצור כמה קובצי APK של האפליקציה, כל אחד מהם מותאם לקטגוריה אחרת של גודל מסך. בנוסף, תלמדו על כלים שיעזרו לכם לשמור על קוד בסיס של כמה קובצי APK בצורה נוחה ככל האפשר.
איך בודקים אם צריך כמה חבילות APK
כשאתם מנסים ליצור אפליקציה שתעבוד במכשירי Android בגדלים שונים, אתם רוצים שהאפליקציה תנצל את כל המרחב הזמין במכשירים גדולים יותר, בלי להתפשר על תאימות או על נוחות השימוש במסכים קטנים יותר. בהתחלה אולי נראה שאפשרות התמיכה בכמה חבילות APK היא הפתרון הטוב ביותר, אבל בדרך כלל זה לא המצב. בקטע שימוש ב-APK יחיד במקום זאת במדריך למפתחים בנושא חבילות APK מרובות מפורט מידע שימושי על האופן שבו אפשר לעשות זאת באמצעות APK יחיד, כולל שימוש בספריית התמיכה שלנו. מומלץ גם לקרוא את המדריך בנושא תמיכה במספר מסכים. יש גם ספריית תמיכה שאפשר להוריד באמצעות Android SDK, ומאפשרת להשתמש בקטעי קוד במכשירים מדור קודם ל-Honeycomb (כך קל יותר לתמוך במספר מסכים בחבילת APK אחת).
אם אתם יכולים לעשות זאת, יש כמה יתרונות להגבלת האפליקציה לחבילת APK אחת, כולל:
- פרסום ובדיקה קלים יותר
- יש רק בסיס קוד אחד שצריך לתחזק
- האפליקציה יכולה להתאים את עצמה לשינויים בהגדרות המכשיר
- שחזור אפליקציות במכשירים שונים פשוט עובד
- אתם לא צריכים לדאוג לגבי העדפות השוק, ההתנהגות של משתמשים לאחר 'שדרוגים' מחבילת APK אחת לזו הבאה או איזו חבילת APK מתאימה לאילו סוגים של מכשירים.
בהמשך השיעור נניח שערכתם מחקר בנושא, שקראתם בעיון את החומר במשאבים המקושרים והחלטתם ששימוש בכמה קובצי APK הוא הדרך הנכונה לאפליקציה שלכם.
הצגת הדרישות בתרשים
כדי להתחיל, כדאי ליצור תרשים פשוט כדי לקבוע במהירות כמה קבצי APK אתם צריכים, ואילו גדלי מסך כל קבץ APK מכסה. למרבה המזל, קל ליצור תרשים של הדרישות במהירות ובקלות, ולשמור אותו לשימוש עתידי. מתחילים עם שורה של תאים שמייצגים את גדלי המסך השונים שזמינים בפלטפורמת Android.
| קטנות | רגיל | גדולה | xlarge |
עכשיו פשוט צובעים את התרשים כך שכל צבע מייצג קובץ APK. הנה דוגמה אחת לאופן שבו אפשר להחיל כל קובץ APK על טווח מסוים של גדלי מסך.
| קטנות | רגיל | גדולה | xlarge |
בהתאם לצרכים שלכם, תוכלו גם ליצור שני קובצי APK, 'קטן וכל השאר' או 'גדול במיוחד וכל השאר'. הצביעה בתרשים גם מאפשרת תקשורת קלה יותר בתוך הצוות – עכשיו אפשר פשוט להתייחס לכל קובץ APK בתור 'כחול', 'ירוק' או 'אדום', לא משנה כמה סוגי מסכים הוא מכסה.
שמירת כל המשאבים והקודים הנפוצים בפרויקט ספרייה
בין שאתם משנים אפליקציית Android קיימת ובין שאתם מתחילים אפליקציה מאפס, זהו הדבר הראשון שצריך לעשות בקוד, והוא החשוב ביותר. כל מה שמופיע בפרויקט הספרייה צריך להתעדכן רק פעם אחת (למשל, מחרוזות מותאמות לשפה, נושאי צבעים, באגים שתוקנו בקוד המשותף). כך תוכלו לקצר את זמני הפיתוח ולהפחית את הסיכוי לשגיאות שאפשר היה למנוע בקלות.
הערה: פרטי ההטמעה של יצירת פרויקטים של ספריות והכללתם בפרויקטים אחרים לא נכללים בנושא של השיעור הזה, אבל תוכלו לקרוא את המאמר יצירת ספרייה ל-Android כדי להתעדכן.
אם אתם ממירים אפליקציה קיימת כך שתשתמש בתמיכה בכמה חבילות APK, עליכם לחפש בקוד כל קובץ מחרוזת, רשימת ערכים, צבעי נושא, סמלי תפריט ועיצוב שתואמים לשוק המקומי ולא ישתנו בחבילות ה-APK, ולהעביר את כולם לפרויקט הספרייה. כדאי גם להוסיף לפרויקט הספרייה קוד שלא צפוי להשתנות הרבה. סביר להניח שתצטרכו להרחיב את הכיתות האלה כדי להוסיף שיטה או שתיים מ-APK ל-APK.
לעומת זאת, אם אתם יוצרים את האפליקציה מאפס, נסו לכתוב קוד בפרויקט הספרייה קודם, ואז להעביר אותו לקובץ APK נפרד רק אם יש צורך. כך קל יותר לנהל את הקבצים בטווח הארוך, מאשר להוסיף אותם לספרייה אחת, ואז לספרייה אחרת, ואז לספרייה אחרת, ואז חודשים לאחר מכן לנסות להבין אם אפשר להעביר את ה-blob הזה לקטע הספרייה בלי לגרום לשגיאות.
יצירת פרויקטים חדשים של קובצי APK
צריך להיות פרויקט Android נפרד לכל קובץ APK שאתם מתכננים להשיק. כדי לארגן את הדברים בקלות, כדאי למקם את פרויקט הספרייה ואת כל פרויקטי ה-APK הרלוונטיים באותה תיקיית הורה. חשוב גם לזכור שלכל קובץ APK צריך להיות אותו שם חבילה, אבל אין צורך לשתף את שם החבילה עם הספרייה. אם יש לכם 3 חבילות APK לפי התכנון שמתואר למעלה, ספריית השורש עשויה להיראות כך:
alexlucas:~/code/multi-apks-root$ ls foo-blue foo-green foo-lib foo-red
אחרי שיוצרים את הפרויקטים, מוסיפים את פרויקט הספרייה כהפניה לכל פרויקט APK. אם אפשר, כדאי להגדיר את הפעילות המתחילה בפרויקט הספרייה ולהרחיב את הפעילות הזו בפרויקט ה-APK. הגדרת פעילות התחלה בפרויקט הספרייה מאפשרת לכם למקם את כל תהליך האינטראקציה הראשונית של האפליקציה במקום אחד, כך שלא תצטרכו להטמיע מחדש משימות 'אוניברסליות' בכל חבילת APK בנפרד, כמו הפעלת Analytics, בדיקות רישוי וכל תהליך אינטראקציה ראשוני אחר שלא משתנה הרבה מחבילת APK אחת לאחרת.
שינוי המניפסטים
כשמשתמש מוריד אפליקציה שמשתמשת בכמה חבילות APK דרך Google Play, מערכת Google בוחרת את חבילת ה-APK הנכונה לשימוש לפי שני כללים פשוטים:
- המניפסט צריך להראות ש-APK מסוים עומד בדרישות
- מבין חבילות ה-APK שעומדות בדרישות, חבילת ה-APK עם מספר הגרסה הגבוה ביותר היא הזוכה
לדוגמה, ניקח את הקבוצה של כמה קובצי APK שתיארנו קודם, ונניח שכל קובץ APK הוגדר לתמוך בכל גודלי המסכים שגדולים מגודל המסך 'היעד' שלו. אם נבחן כל אחת מהן בנפרד, הטווח האפשרי של כל חבילת APK ייראה כך:
| קטנות | רגיל | גדולה | xlarge |
| קטנות | רגיל | גדולה | xlarge |
| קטנות | רגיל | גדולה | xlarge |
עם זאת, אם נשתמש בכלל 'המספר הגבוה ביותר של הגרסה מנצח', ונגדיר את המאפיין versionCode בכל קובץ APK כך ש-red ≥ green ≥ blue, התרשים יתכווץ למעשה כך:
| קטנות | רגיל | גדולה | xlarge |
עכשיו נניח של-APK האדום יש דרישה כלשהי שלא קיימת בשני האחרים. בדף מסננים ב-Google Play במדריך למפתחי Android יש רשימה שלמה של גורמים אפשריים. לדוגמה, נניח שהצבע האדום מחייב מצלמה קדמית. למעשה, כל העניין של קובץ ה-APK האדום הוא לנצל את שטח המסך הנוסף שזמין כדי לעשות דברים משעשעים עם המצלמה הקדמית. אבל מסתבר שלחלק מהמכשירים בגודל xlarge אין אפילו מצלמה קדמית! איזה אימה!
למרבה המזל, אם משתמש יבקר ב-Google Play ממכשיר כזה, מערכת Google Play תבדוק את המניפסט, תראה ש-Red מציינת את המצלמה הקדמית כדרישה ותתעלם ממנה בשקט, לאחר שהיא תגיע למסקנה ש-Red והמכשיר הזה לא מתאימים זה לזה. לאחר מכן, המערכת תזהה שהתכונה 'ירוק' תואמת לא רק למכשירים בגודל xlarge, אלא גם לא משנה אם יש מצלמה קדמית או לא. המשתמשים עדיין יכולים להוריד את האפליקציה מ-Google Play, כי למרות כל התקרית עם המצלמה הקדמית, עדיין היה קובץ APK שתומך בגודל המסך הספציפי הזה.
כדי לשמור את כל חבילות ה-APK ב'מסלולים' נפרדים, חשוב להשתמש בסכימה טובה של קודי גרסאות. הגרסה המומלצת מופיעה בקטע קודי גרסאות במדריך למפתחים. מכיוון שקבוצת ה-APK לדוגמה עוסקת רק באחד מ-3 המאפיינים האפשריים, מספיק להפריד כל APK ב-1,000 ולהוסיף ממנו. זה יכול להיראות כך:
כחול: 1001, 1002, 1003, 1004…
ירוק: 2001, 2002, 2003, 2004...
אדום:3001, 3002, 3003, 3004…
כשמרכזים את כל הנתונים האלה, קובצי ה-Android Manifests אמורים להיראות בערך כך:
כחול:
<manifest xmlns:android="http://schemas.android.com/apk/res/android" android:versionCode="1001" android:versionName="1.0" package="com.example.foo"> <supports-screens android:smallScreens="true" android:normalScreens="true" android:largeScreens="true" android:xlargeScreens="true" /> ...
ירוק:
<manifest xmlns:android="http://schemas.android.com/apk/res/android" android:versionCode="2001" android:versionName="1.0" package="com.example.foo"> <supports-screens android:smallScreens="false" android:normalScreens="false" android:largeScreens="true" android:xlargeScreens="true" /> ...
אדום:
<manifest xmlns:android="http://schemas.android.com/apk/res/android" android:versionCode="3001" android:versionName="1.0" package="com.example.foo"> <supports-screens android:smallScreens="false" android:normalScreens="false" android:largeScreens="false" android:xlargeScreens="true" /> ...
חשוב לזכור שמבחינה טכנית, כמה קובצי APK יפעלו עם התג supports-screens או עם התג compatible-screens. בדרך כלל עדיף להשתמש בתג Supports-screens, ובדרך כלל לא מומלץ להשתמש בשני התגים באותו מניפסט. היא רק מסבכת את התהליך ומגדילה את הסיכוי לשגיאות. חשוב גם לזכור שבמקום להשתמש בערכי ברירת המחדל (small ו-normal תמיד מוגדרים כ-true כברירת מחדל), ב-manifests מוגדר באופן מפורש הערך לכל גודל מסך. כך תוכלו לחסוך כאבי ראש בעתיד. לדוגמה, במניפסט עם גרסת SDK יעד של פחות מ-9, הערך של xlarge יוגדר אוטומטית כ-false כי הגודל הזה עדיין לא היה קיים. לכן, חשוב להבהיר את הנושא.
בדיקת רשימת המשימות לפני ההשקה
לפני ההעלאה ל-Google Play, חשוב לבדוק את הפריטים הבאים. חשוב לזכור שההנחיות האלה רלוונטיות במיוחד לכמה קובצי APK, והן לא מהוות רשימת משימות מלאה לכל האפליקציות שמעלים ל-Google Play.
- לכל קובצי ה-APK צריך להיות אותו שם חבילה.
- כל חבילות ה-APK חייבות להיות חתומות באותו אישור
- כל גודל מסך שרוצים ש-APK יתמוך בו, מגדירים כ-true במניפסט. כל גודל מסך שרוצים להימנע ממנו, מגדירים כ-false
- בודקים היטב את המסננים של המניפסט כדי לאתר מידע סותר (קובץ APK שתומך רק ב-Cupcake במסכים בגודל XLARGE לא יוצג לאף אחד)
- המניפסט של כל קובץ APK חייב להיות ייחודי לפחות לגרסה אחת של מסך, מרקם OpenGL או פלטפורמה נתמכים
- נסו לבדוק כל חבילת APK במכשיר אחד לפחות. מלבד זאת, במכונה שלכם לפיתוח יש אחד מחקימי המכשירים הכי ניתנים להתאמה אישית בתחום. תהנו!
מומלץ גם לבדוק את קובץ ה-APK המהדר לפני שמעבירים אותו לשוק, כדי לוודא שאין הפתעות שעלולות להסתיר את האפליקציה ב-Google Play. זה פשוט מאוד באמצעות הכלי aapt. Aapt (Android Asset Packaging Tool) הוא חלק מתהליך ה-build ליצירה ולאריזה של אפליקציות Android, והוא גם כלי שימושי מאוד לבדיקה שלהן.
>aapt dump badging package: name='com.example.hello' versionCode='1' versionName='1.0' sdkVersion:'11' uses-permission:'android.permission.SEND_SMS' application-label:'Hello' application-icon-120:'res/drawable-ldpi/icon.png' application-icon-160:'res/drawable-mdpi/icon.png' application-icon-240:'res/drawable-hdpi/icon.png' application: label='Hello' icon='res/drawable-mdpi/icon.png' launchable-activity: name='com.example.hello.HelloActivity' label='Hello' icon='' uses-feature:'android.hardware.telephony' uses-feature:'android.hardware.touchscreen' main supports-screens: 'xlarge' supports-any-density: 'true' locales: '--_--' densities: '120' '160' '240'
כשבודקים את הפלט של aapt, חשוב לוודא שאין ערכים סותרים של supports-screens ו-compatible-screens, ושאין ערכים לא רצויים של uses-feature שנוספו כתוצאה מההרשאות שהגדרתם במניפסט. בדוגמה שלמעלה, קובץ ה-APK יהיה בלתי גלוי ברוב המכשירים, אם לא בכל המכשירים.
למה? הוספת ההרשאה הנדרשת SEND_SMS הוסיפה באופן משתמע את דרישת התכונה android.hardware.telephony. מאחר שרוב המכשירים בגודל xlarge (אם לא כולם) הם טאבלטים ללא חומרה טלפונית, מערכת Google Play תסנן את קובץ ה-APK הזה במקרים כאלה, עד שיופיעו מכשירים עתידיים שיהיו גדולים מספיק כדי לדווח על מסך בגודל xlarge וגם יכילו חומרה טלפונית.
למרבה המזל, אפשר לפתור את הבעיה בקלות על ידי הוספת הקוד הבא למניפסט:
<uses-feature android:name="android.hardware.telephony" android:required="false" />
גם הדרישה android.hardware.touchscreen נוספת באופן משתמע. אם אתם רוצים שה-APK יהיה גלוי בטלוויזיות שהן לא מכשירים עם מסך מגע, עליכם להוסיף את הפרטים הבאים למניפסט:
<uses-feature android:name="android.hardware.touchscreen" android:required="false" />
אחרי שתסיימו את רשימת המשימות לקראת ההשקה, תוכלו להעלות את קובצי ה-APK ל-Google Play. יכול להיות שיחלוף קצת זמן עד שהאפליקציה תופיע כשאתם גולשים ב-Google Play, אבל כשהיא תופיע, כדאי לבצע בדיקה אחרונה. מורידים את האפליקציה לכל מכשירי הבדיקה שיש לכם כדי לוודא שקבצי ה-APK מטרגטים את המכשירים המיועדים.
מידע נוסף על פרסום כמה קובצי APK ב-Google Play זמין במאמר תמיכה בכמה קובצי APK.