אם אתם מפרסמים את האפליקציה ב-Google Play, עליכם ליצור קובץ Android App Bundle ולהעלות אותו. כשעושים זאת, מערכת Google Play יוצרת ומציגה באופן אוטומטי חבילות APK שעברו אופטימיזציה לכל הגדרת מכשיר של משתמש, כך שהם מורידים רק את הקוד והמשאבים הנחוצים להפעלת האפליקציה. פרסום של כמה חבילות APK שימושי אם אתם לא מפרסמים ב-Google Play, אבל עליכם ליצור, לחתום ולנהל כל אחת מהן בעצמכם.
כשאתם מפתחים אפליקציה ל-Android כדי לנצל את היתרונות של כמה קובצי APK ב-Google Play, חשוב לאמץ כמה שיטות מומלצות כבר מההתחלה כדי למנוע כאבי ראש מיותרים בהמשך תהליך הפיתוח. במדריך הזה תלמדו איך ליצור כמה קובצי APK של האפליקציה, שכל אחד מהם מכסה טווח שונה במקצת של רמות API. בנוסף, תלמדו על כמה כלים שיעזרו לכם לשמור על קוד בסיס של כמה קובצי APK בצורה נוחה ככל האפשר.
איך בודקים אם צריך כמה חבילות APK
כשאתם מנסים ליצור אפליקציה שתעבוד במספר דורות של פלטפורמת Android, אתם רוצים שהאפליקציה תנצל את התכונות החדשות במכשירים חדשים, בלי להקריב את התאימות לאחור. בהתחלה אולי נראה שתמיכה בכמה קובצי APK היא הפתרון הטוב ביותר, אבל בדרך כלל זה לא המצב. בקטע שימוש ב-APK יחיד במקום זאת במדריך למפתחים בנושא חבילות APK מרובות מפורט מידע שימושי על האופן שבו אפשר לעשות זאת באמצעות APK יחיד, כולל שימוש בספריית התמיכה שלנו. ב מאמר הזה מוסבר גם איך לכתוב קוד שפועל רק ברמות API מסוימות בחבילת APK אחת, בלי להשתמש בשיטות יקרות מבחינה חישובית כמו רפלקציה.
אם אתם יכולים לעשות זאת, יש כמה יתרונות להגבלת האפליקציה לחבילת APK אחת, כולל:
- פרסום ובדיקה קלים יותר
- יש רק קוד בסיס אחד שצריך לתחזק
- האפליקציה יכולה להתאים את עצמה לשינויים בהגדרות המכשיר
- שחזור אפליקציות במכשירים שונים פשוט עובד
- אתם לא צריכים לדאוג לגבי העדפות השוק, ההתנהגות של משתמשים לאחר 'שדרוגים' מחבילת APK אחת לזו הבאה, או איזו חבילת APK מתאימה לאילו סוגים של מכשירים.
בהמשך השיעור נניח שבדקתם את הנושא, שקראתם בעיון את החומר במשאבים המקושרים והגעתם למסקנה שמספר קובצי APK הם הדרך הנכונה לאפליקציה שלכם.
הצגת הדרישות בתרשים
כדי להתחיל, כדאי ליצור תרשים פשוט כדי לקבוע במהירות כמה ערכות APK אתם צריכים, ומה טווח ה-API שכל ערכת APK מכסה. כדאי לדעת: בדף Platform Versions באתר Android Developer מוצגים נתונים על המספר היחסי של מכשירים פעילים שפועלת בהם גרסה מסוימת של פלטפורמת Android. בנוסף, למרות שזה נשמע קל בהתחלה, קשה מאוד לעקוב אחרי קבוצת רמות ה-API שאליהם כל קובץ APK יתמקד, במיוחד אם תהיה חפיפה מסוימת (לרוב יש). למרבה המזל, קל ליצור תרשים של הדרישות במהירות ובקלות, וכך יהיה לכם מסמך עזר שימושי לשימוש עתידי.
כדי ליצור תרשים של כמה חבילות APK, מתחילים בשורה של תאים שמייצגים את רמות ה-API השונות של פלטפורמת Android. מוסיפים תא נוסף בסוף כדי לייצג גרסאות עתידיות של Android.
| 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | + |
עכשיו פשוט צובעים את התרשים כך שכל צבע מייצג קובץ APK. הנה דוגמה אחת לאופן שבו אפשר להחיל כל קובץ APK על טווח מסוים של רמות API.
| 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | + |
אחרי שיוצרים את התרשים הזה, אפשר לשלוח אותו לצוות. התקשורת בצוות של הפרויקט הפכה פשוטה יותר באופן מיידי, כי במקום לשאול "איך נראה קובץ ה-APK לרמות API 3 עד 6, אה, זה של Android 1.x. איך זה מתקדם?" אפשר פשוט לומר "How's the Blue APK coming along?"
שמירת כל המשאבים והקודים הנפוצים בפרויקט ספרייה
בין שאתם משנים אפליקציית 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 שתיארנו למעלה, ונניח שלא הגדרנו רמת API מקסימלית לאף אחת מחבילות ה-APK. אם נבחן כל אחת מהן בנפרד, הטווח האפשרי של כל חבילת APK ייראה כך:
| 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | + |
| 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | + |
| 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | + |
מכיוון שחבילות APK עם minSdkVersion גבוה יותר חייבות לכלול גם קוד גרסה גבוה יותר, אנחנו יודעים שבמונחים של ערכי versionCode, האדומה גדולה מהירוקה והירוקה גדולה מהכחולה. לכן אפשר לכווץ את התרשים כך שייראה כך:
| 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | + |
עכשיו נניח גם של-APK האדום יש דרישה כלשהי שלא קיימת בשני האחרים. בדף מסננים ב-Google Play במדריך למפתחי Android יש רשימה שלמה של גורמים אפשריים. לדוגמה, נניח שהצבע האדום מחייב מצלמה קדמית. למעשה, כל העניין של קובץ ה-APK האדום הוא לשלב את המצלמה הקדמית עם פונקציונליות חדשה ומגניבה שנוספה ב-API 11. אבל מסתבר שלא בכל המכשירים שתומכים ב-API 11 יש אפילו מצלמה קדמית! איזה אימה!
למרבה המזל, אם משתמש יבקר ב-Google Play ממכשיר כזה, מערכת Google Play תבדוק את המניפסט, תראה ש-Red מציינת את המצלמה הקדמית כדרישה ותתעלם ממנה בשקט, לאחר שהיא תגיע למסקנה ש-Red והמכשיר הזה לא מתאימים זה לזה. לאחר מכן, המערכת תזהה שהגרסה של Green תואמת לאחור למכשירים עם API 11 (כי לא הוגדרה maxSdkVersion), אבל גם לא משנה לה אם יש מצלמה קדמית או לא. המשתמשים עדיין יכולים להוריד את האפליקציה מ-Google Play, כי למרות כל התקרית עם המצלמה הקדמית, עדיין היה קובץ APK שתומך ברמת ה-API הספציפית הזו.
כדי לשמור את כל חבילות ה-APK ב'מסלולים' נפרדים, חשוב להשתמש בסכימה טובה של קודי גרסאות. הגרסה המומלצת מופיעה בקטע קודי גרסאות במדריך למפתחים. מכיוון שקבוצת הדוגמאות של חבילות ה-APK עוסקת רק באחד מ-3 המאפיינים האפשריים, מספיק להפריד כל חבילה של APK ב-1, 000, להגדיר את הספרות הראשונות ל-minSdkVersion של חבילת ה-APK הספציפית הזו ולהגדיל את הערך משם. זה יכול להיראות כך:
כחול: 03001, 03002, 03003, 03004…
ירוק: 07001, 07002, 07003, 07004…
אדום: 11001, 11002, 11003, 11004…
אם משלבים את כל זה, מניפסטים של Android ייראו בערך כך:
כחול:
<manifest xmlns:android="http://schemas.android.com/apk/res/android" android:versionCode="03001" android:versionName="1.0" package="com.example.foo"> <uses-sdk android:minSdkVersion="3" /> ...
ירוק:
<manifest xmlns:android="http://schemas.android.com/apk/res/android" android:versionCode="07001" android:versionName="1.0" package="com.example.foo"> <uses-sdk android:minSdkVersion="7" /> ...
אדום:
<manifest xmlns:android="http://schemas.android.com/apk/res/android" android:versionCode="11001" android:versionName="1.0" package="com.example.foo"> <uses-sdk android:minSdkVersion="11" /> ...
בדיקת רשימת המשימות לפני ההשקה
לפני ההעלאה ל-Google Play, חשוב לבדוק את הפריטים הבאים. חשוב לזכור שההנחיות האלה רלוונטיות במיוחד לכמה חבילות APK, והן לא מהוות רשימת משימות מלאה לכל האפליקציות שמעלים ל-Google Play.
- לכל קובצי ה-APK צריך להיות אותו שם חבילה.
- כל חבילות ה-APK חייבות להיות חתומות באותו אישור
- אם יש חפיפה בין חבילות ה-APK לגבי גרסת הפלטפורמה, קוד הגרסה של חבילת ה-APK עם הערך הגבוה יותר של minSdkVersion חייב להיות גבוה יותר
- בודקים היטב את מסנני המניפסט כדי לאתר מידע סותר (קובץ 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: 'small' 'normal' 'large' 'xlarge' supports-any-density: 'true' locales: '--_--' densities: '120' '160' '240'
כשבודקים את הפלט של aapt, חשוב לוודא שאין ערכים סותרים של supports-screens ו-compatible-screens, ושאין ערכים לא רצויים של uses-feature שנוספו כתוצאה מהרשאות שהגדרתם במניפסט. בדוגמה שלמעלה, קובץ ה-APK לא יהיה גלוי למכשירים רבים.
למה? הוספת ההרשאה הנדרשת SEND_SMS הוסיפה באופן משתמע את דרישת התכונה android.hardware.telephony. מאחר ש-API 11 הוא Honeycomb (גרסת Android שעברה אופטימיזציה במיוחד לטאבלטים), ואין מכשירי Honeycomb עם חומרה טלפונית, Google Play יסנן את קובץ ה-APK הזה בכל המקרים, עד שיופיעו מכשירים עתידיים עם רמת API גבוהה יותר וגם עם חומרה טלפונית.
למרבה המזל, אפשר לפתור את הבעיה בקלות על ידי הוספת הקוד הבא למניפסט:
<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 מטרגטים את המכשירים המיועדים. כל הכבוד, סיימתם!