אם רוצים לפרסם את האפליקציה ב-Google Play, צריך ליצור ולהעלות קובץ Android App Bundle. לאחר מכן, Google Play יוצרת ומציגה באופן אוטומטי חבילות APK שעברו אופטימיזציה בהתאם לתצורת המכשיר של כל משתמש, כך שהם מורידים רק את הקוד והמשאבים שדרושים להם כדי להפעיל את האפליקציה. פרסום של חבילות APK מרובות שימושי אם לא מפרסמים מספר חבילות APK ב-Google Play, אבל חובה ליצור, לחתום ולנהל כל APK בעצמכם.
כשמפתחים אפליקציה ל-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.
שינוי המניפסטים
כשמשתמש מורייד אפליקציה שמשתמשת בכמה חבילות APK דרך Google Play, מערכת Google בוחרת את חבילת ה-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 האדום יש דרישה כלשהי שלא חלה על שתי ה-APK האחרות. בדף מסננים ב-Google Play במדריך למפתחי Android יש רשימה שלמה של גורמים אפשריים. לדוגמה, נניח שהצבע האדום מחייב שימוש במצלמה הקדמית. למעשה, כל העניין של קובץ ה-APK האדום הוא לשלב את המצלמה הקדמית עם פונקציונליות חדשה ומגניבה שנוספה ב-API 11. אבל מסתבר שלא בכל המכשירים שתומכים ב-API 11 יש אפילו מצלמות קדמיות! איזה אימה!
למרבה המזל, אם משתמש מעיין ב-Google Play ממכשיר כזה, Google Play תבחן את המניפסט, תראה ש-Red מציג את המצלמה הקדמית כדרישה, ומתעלם ממנה בשקט, לאחר שקובעים שאדום שהמכשיר הזה לא תואם לגן עדן דיגיטלי. לאחר מכן, המערכת תזהה שהאפליקציה של גרין לא רק תואמת לעתיד למכשירים עם API 11 (כי לא הוגדרה maxSdkVersion), אלא גם לא משנה לה אם יש מצלמה קדמית או לא. המשתמש עדיין יכול להוריד את האפליקציה מ-Google Play, כי למרות התקלה במצלמה הקדמית, עדיין הייתה חבילת APK שתומכת ברמת ה-API הספציפית הזו.
כדי לשמור את כל חבילות ה-APK ב'מסלולים' נפרדים, חשוב להשתמש בסכימה טובה של קודי גרסאות. הגרסה המומלצת מופיעה בקטע קודי גרסאות במדריך למפתחים שלנו. מאחר שקבוצת ה-APK לדוגמה עוסקת רק באחד מ-3 מאפיינים אפשריים, אפשר להספיק להפריד בין חבילות ה-APK ב-1000, להגדיר את שתי הספרות הראשונות כ-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 מטרגטים את המכשירים המיועדים. זהו, סיימתם!