אם אתם מפרסמים את האפליקציה ב-Google Play, עליכם ליצור ולהעלות קובץ Android App Bundle. כשעושים זאת, Google Play מופעל באופן אוטומטי יוצר ומציג חבילות 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. לנוחותך, הדף גרסאות פלטפורמה של האתר של מפתחי Android מספק נתונים על המספר היחסי של מכשירים פעילים שבהם פועל של פלטפורמת 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 | + |
אחרי שיוצרים את התרשים, אפשר להפיץ אותו לצוות שלכם. תקשורת בין חברי צוות בפרויקט עכשיו הוא פשוט יותר פשוט, מכיוון שבמקום לשאול "How’s the APK for API options 3 עד 6, er, " הכירו את Android 1.x. איך זה הולך?" אפשר פשוט לומר: "How’s the Blue APK coming. יחד?"
הקצאת כל הקוד והמשאבים הנפוצים בפרויקט ספרייה
לא משנה אם אתם משנים אפליקציה קיימת ל-Android או יוצרים אפליקציה מאפס, הדבר הראשון שצריך לעשות ל-codebase, ולרוב הדבר הכי חשוב. הכול שנכנסים לפרויקט הספרייה, צריך לעדכן אותם רק פעם אחת (למשל, מחרוזות שמתאימות לשפה מסוימת, עיצובים של צבעים, באגים שתוקנו בקוד משותף), שמשפרים את זמן הפיתוח ומפחיתים את לטעויות שניתן היה להימנע בקלות.
הערה: בעוד פרטים על ההטמעה כוללים פרויקטים של ספריות שלא נכללים בשיעור הזה, תוכלו להשיג אפשר לקרוא את המאמר יצירת ספריית Android.
אם אתם ממירים אפליקציה קיימת לשימוש בתמיכה ב-APK מרובים, לסרוק את ה-codebase לכל קובץ מחרוזת, רשימת ערכים ועיצוב שהותאמו לשוק המקומי. צבעים, סמלי תפריטים ופריסה שלא עומדים להשתנות ב-APKs, ולהוסיף בפרויקט הספרייה. קוד שלא עומד להשתנות הרבה גם בפרויקט הספרייה. סביר להניח שתצטרכו להרחיב מחלקות כדי להוסיף שיטה או שניים מ-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 בנפרד לא ליישם מחדש את "Universalversal" משימות כמו אתחול Analytics, הרצת בדיקות רישוי וכל פעולה אחרת הליכי אתחול שלא משתנים הרבה מ-APK ל-APK.
שינוי המניפסטים
כשמשתמש מוריד אפליקציה שמשתמשת בכמה חבילות APK דרך Google Play, בחירת ה-APK לשימוש בשני כללים פשוטים:
- במניפסט צריך להראות שחבילת APK מסוימת עומדת בדרישות
- מתוך חבילות ה-APK שעומדות בדרישות, מספר הגרסה הגבוה ביותר זוכה
לדוגמה, ניקח את סדרת ה-APKs המרובים שתוארו קודם לכן, ונניח שלא להגדיר רמת 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 תבחן את שימו לב שאדום מפרט את המצלמה הקדמית כדרישה, ומתעלמים ממנה בשקט, שאדום ומכשיר ההוא לא תואמים לגן עדן דיגיטלי. ואז הוא יראה את זה בצבע ירוק לא רק במכשירים עם API 11 (כיוון לא הוגדר maxSdkVersion), אבל גם לא משנה אם יש מצלמה קדמית או לא! עדיין אפשר להוריד את האפליקציה מ-Google Play על ידי המשתמש, כי למרות התקלה כולה במצלמה הקדמית, עדיין חבילת ה-APK שתומכת ברמת ה-API הספציפית הזו.
כדי להשאיר את כל חבילות ה-APK ב'מסלולים' נפרדים, חשוב להשתמש בקוד גרסה טוב scheme. הגרסה המומלצת נמצאת באזור Version Codes (קודי גרסאות) של במדריך למפתחים. מאחר שקבוצת ה-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 חופפות בגרסת הפלטפורמה, לאפליקציה עם ה-minSdkVersion הגבוה יותר צריך להיות קוד גרסה גבוה יותר
- בודקים שוב את מסנני המניפסט כדי לאתר מידע סותר (אף אחד לא יראה חבילת APK שתומכת רק בקאפקייק במסכי XLARGE)
- המניפסט של כל APK חייב להיות ייחודי לפחות לאחד מסך נתמך אחד, טקסטורת openGL או גרסת פלטפורמה אחת לפחות
- מומלץ לבדוק כל חבילת APK במכשיר אחד לפחות. מלבד זאת, יש לכם בעסק אחד מאמולטורים של מכשירים שניתן להתאים אישית בצורה הטובה ביותר. השתגע!
כדאי גם לבדוק את ה-APK המורכב לפני שדוחפים אותו לשוק, כדי לוודא שאין בו הפתעות שעלולות להסתיר את האפליקציה ב-Google Play. זה בעצם די פשוט באמצעות 'aapt' של Google. Aapt (הכלי לאריזת נכסים של Android) הוא חלק מתהליך ה-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, חשוב לוודא שאין לך ערכים מתנגשים תומך במסכים ובמסכים תואמים, ושאין לך מכשיר שמתכוון ל-'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 מטרגטות את המכשירים הרצויים. מזל טוב, סיימת!