אם אתם מפרסמים את האפליקציה ב-Google Play, עליכם ליצור ולהעלות קובץ Android App Bundle. כשעושים זאת, Google Play מופעל באופן אוטומטי יוצר ומציג חבילות APK שעברו אופטימיזציה בהתאם לתצורת המכשיר של כל משתמש, כך שהמשתמשים מורידים רק את הקוד והמשאבים הדרושים להם כדי להפעיל את האפליקציה. פרסום של חבילות APK מרובות שימושי אם לא מפרסמים ב-Google Play, אבל עליכם ליצור, לחתום ולנהל כל APK בעצמכם.
כשמפתחים אפליקציה ל-Android כדי ליהנות מהיתרונות של חבילות APK מרובות ב-Google Play, חשוב לאמץ כמה שיטות מומלצות כבר מההתחלה כדי למנוע כאבי ראש מיותרים בשלב מתקדם יותר של תהליך הפיתוח. במדריך הזה נסביר איך יוצרים כמה קובצי APK של האפליקציה, כל אחד מהם מתאים לקטגוריה אחרת של גודל מסך. בנוסף, תלמדו על כלים שיעזרו לכם לשמור על קוד בסיס של כמה קובצי APK בצורה נוחה ככל האפשר.
מוודאים שצריך כמה חבילות APK
כשמנסים ליצור אפליקציה שפועלת במגוון העצום של מכשירי Android שזמינים שלך, באופן טבעי היית רוצה שהאפליקציה שלך תיראה במיטבה בכל מכשיר בנפרד. אתם צריכים: לנצל את השטח של מסכים גדולים ועדיין לעבוד על מסכים קטנים, כדי להשתמש ב-Android API החדש תכונות או מרקמים חזותיים שזמינים במכשירים מתקדמים, אבל לא נוטשים מכשירים ישנים יותר. ייתכן נראות בהתחלה כאילו שתמיכה ב-APK מרובים היא הפתרון הטוב ביותר, אבל לעיתים קרובות מותאמת אישית. השימוש במקום זאת, הקטע APK יחיד במדריך של מספר חבילות ה-APK כולל מידע שימושי שמסביר איך לעשות את כל זה באמצעות APK אחד, כולל שימוש בספריית התמיכה שלנו, וקישורים למקורות מידע שמופיעים במדריך למפתחי Android.
אם ניתן לנהל אותו, להגבלת האפליקציה ל-APK אחד יש מספר יתרונות: כולל:
- קל יותר לפרסם ולבדוק
- יש רק בסיס קוד אחד שצריך לשמור
- האפליקציה יכולה להתאים את עצמה לשינויים בהגדרות המכשיר
- שחזור האפליקציה בין מכשירים פשוט עובד
- לא צריך לדאוג לגבי העדפה בשוק, התנהגות מ"שדרוגים" מ-APK אחד הבא, או איזה APK מתאים לכל סוג של מכשירים
שאר השיעור מניח שאתם חקרתם את הנושא, במשאבים המקושרים, והגענו למסקנה שכמה חבילות APK הן המסלול המתאים תרגום מכונה.
איך מתכננים את הדרישות
בתור התחלה, יוצרים תרשים פשוט שעוזר להבין במהירות כמה חבילות APK צריך ואיזה מסך צריך הגדלים שנכללים בכל חבילת APK. למרבה המזל, קל ליצור תרשים של הדרישות במהירות ובקלות, וכך יהיה קל להיעזר בו מאוחר יותר. נניח שאתם רוצים לפצל את חבילות ה-APK בין שני מאפיינים - API וגודל המסך. יצירת טבלה עם שורה ועמודה לכל צמד אפשרי של ערכים וצבע בחלק מ'blobs', כל צבע מייצג APK אחד.
| 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | + | |
| קטנות | |||||||||||
| רגיל | |||||||||||
| גדולה | |||||||||||
| xlarge |
למעלה מוצגת דוגמה עם ארבע חבילות APK. כחול הוא לכל המכשירים עם מסך קטן/רגיל, ירוק הוא תצוגה גדולה של מכשירים בעלי מסך גדול, ו-Red הוא עבור מכשירים עם מסך גדול במיוחד, כשטווח ה-API שלהם הוא 3-10. סגול הוא זהו מקרה מיוחד לכל גדלי המסכים, אבל רק ל-API מגרסה 11 ואילך. ומעל לכך, פשוט בתרשים הזה אפשר לראות מיד איזה APK מכסה שילוב נתון של API/גודל מסך. בנוסף, לכל אחת מהן יש גם שמות קוד אופנתיים, כי קל יותר לשאול את ה-cubie "האם בדקנו את red ב-?" מאשר לשאול "האם בדקנו את ה-APK בגודל xlarge של 3 עד 10 מול Xoom?" מומלץ להדפיס את התרשים הזה ולתת אותו לכל מי שעובד על קוד הבסיס. החיים נהיו הרבה יותר קלים.
שמירת כל הקוד והמשאבים הנפוצים בפרויקט ספרייה
לא משנה אם אתם משנים אפליקציה קיימת ל-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-purple foo-red
אחרי שיוצרים את הפרויקטים, מוסיפים את פרויקט הספרייה כהפניה לכל פרויקט APK. אם המיקום אפשרית, להגדיר את הפעילות ההתחלתית שלך בפרויקט הספרייה ולהרחיב את הפעילות הזו ב-APK. פרויקט. לאחר הגדרת פעילות התחלתית בפרויקט הספרייה, יש לכם הזדמנות לשים את כל באתחול האפליקציה במקום אחד, כך שכל חבילת APK בנפרד לא ליישם מחדש את "Universalversal" משימות כמו אתחול Analytics, הרצת בדיקות רישוי וכל פעולה אחרת הליכי אתחול שלא משתנים הרבה מ-APK ל-APK.
שינוי המניפסטים
כשמשתמש מוריד אפליקציה שמשתמשת בכמה חבילות APK דרך Google Play, בחירת ה-APK לשימוש בשני כללים פשוטים:
- במניפסט צריך להראות שחבילת APK מסוימת עומדת בדרישות
- מתוך חבילות ה-APK שעומדות בדרישות, מספר הגרסה הגבוהה ביותר זוכה.
לדוגמה, ניקח את הקבוצה של חבילות ה-APK המרובות שתוארו קודם לכן, ונניח שכל אחת ה-APK הוגדר לתמוך בכל גודלי מסכים שגדולים מ"היעד" שלו גודל המסך. בואו נסתכל על מהתרשים לדוגמה הקודם:
| 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | + | |
| קטנות | |||||||||||
| רגיל | |||||||||||
| גדולה | |||||||||||
| xlarge |
זה בסדר אם הכיסוי יחפוף, לכן נוכל לתאר את האזור שכל חבילת APK מכסה, למשל כך:
- כחול מכסה את כל המסכים, minSDK 3.
- בצבע ירוק יש כיסויים למסכים גדולים ואילך, minSDK 3.
- האדום מכסה מסכים בגודל XLarge (בדרך כלל טאבלטים), עם minSDK של 9.
- סגול מכסה את כל המסכים, minSDK בגרסה 11.
חשוב לזכור שיש הרבה חפיפה בכללים האלה. לדוגמה, מכשיר גדול במיוחד עם API 11 יכול להריץ כל אחת מ-4 חבילות ה-APK שצוינו. עם זאת, באמצעות הכלל 'המספר הגבוה ביותר של הגרסה מנצח', אפשר להגדיר סדר העדפות באופן הבא:
סגול ≥ אדום ≥ ירוק ≥ כחול
למה לאפשר את כל החפיפה? נניח שיש דרישה לגבי ה-APK הסגול אבל השניים האחרים לא. הדף מסננים ב-Google Play במדריך למפתחים של Android יש רשימה מלאה של הסיבות האפשריות. לצורך הדוגמה, נניח שסגול דורש מצלמה קדמית. למעשה, כל המטרה של 'סגול' היא להשתמש בדברים בידור באמצעות המצלמה הקדמית! אבל מתברר שלא כל מכשירי API 11+ יש אפילו מצלמות קדמיות! איזה אימה!
למרבה המזל, אם משתמש מעיין ב-Google Play ממכשיר כזה, Google Play תבחן את שימו לב שסגול מציין שנדרשת חשיפה למצלמה הקדמית, ומתעלמים ממנה בשקט והגענו למסקנה שסגול והמכשיר הזה לא מתאימים לגן עדן דיגיטלי. לאחר מכן המערכת אדום לא תואם רק למכשירים גדולים במיוחד, אלא גם לא משנה אם יש מצלמה קדמית! המשתמשים עדיין יכולים להוריד את האפליקציה מ-Google Play, כי למרות כל התקלה במצלמה הקדמית, עדיין היה APK שתמך רמת ה-API.
כדי להשאיר את כל חבילות ה-APK ב'מסלולים' נפרדים, חשוב להשתמש בקוד גרסה טוב scheme. הגרסה המומלצת נמצאת באזור Version Codes (קודי גרסאות) של במדריך למפתחים. כדאי לקרוא את כל הקטע, אבל העקרונות הבסיסיים הם ב-APKs, נשתמש בשתי ספרות כדי לייצג את minSDK, שתיים כדי לייצג את גודל המסך המינימלי/המקסימלי ו-3 כדי לייצג את מספר ה-build. כך, כשהמכשיר שודרג לגרסה חדשה של Android, (למשל, מ-10 עד 11), כל חבילות ה-APK שעומדות בדרישות ומועדפות על פני ההתקנה הנוכחית המכשיר ייחשב כ"שדרוג". הסכימה של מספרי הגרסאות, כשהיא חלה על קבוצת ה-APK לדוגמה, עשויה להיראות כך:
כחול: 0304001, 0304002, 0304003…
ירוק: 0334001, 0334002, 0334003
אדום: 0344001, 0344002, 0344003...
סגול: 1104001, 1104002, 1104003...
בסופו של דבר, המניפסט של Android כנראה ייראה בערך כך הבאים:
כחול:
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
android:versionCode="0304001" android:versionName="1.0" package="com.example.foo">
<uses-sdk android:minSdkVersion="3" />
<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="0334001" android:versionName="1.0" package="com.example.foo">
<uses-sdk android:minSdkVersion="3" />
<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="0344001" android:versionName="1.0" package="com.example.foo">
<uses-sdk android:minSdkVersion="3" />
<supports-screens android:smallScreens="false"
android:normalScreens="false"
android:largeScreens="false"
android:xlargeScreens="true" />
...
סגול:
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
android:versionCode="1104001" android:versionName="1.0" package="com.example.foo">
<uses-sdk android:minSdkVersion="11" />
<supports-screens android:smallScreens="true"
android:normalScreens="true"
android:largeScreens="true"
android:xlargeScreens="true" />
...
חשוב לזכור שמבחינה טכנית, כמה קובצי APK יפעלו עם התג supports-screens או עם התג compatible-screens. בדרך כלל עדיף תמיכה במסכים, וזה ממש לא טוב להשתמש בשני הסוגים- זה הופך דברים למורכבים שלא לצורך, ומעלה את הסיכוי לשגיאות. כמו כן, חשוב לשים לב שבמקום לנצל את ערכי ברירת המחדל (ערכים קטנים ורגילים תמיד נכונים כברירת מחדל), המניפסטים מגדירים באופן מפורש את הערך של כל גודל מסך. כך תוכלו למנוע כאבי ראש בעתיד. לדוגמה, אם המניפסט כולל SDK יעד של פחות מ-9, הערך של xlarge יוגדר באופן אוטומטי כ-false כי הגודל הזה עדיין לא קיים. לכן, חשוב להתנסח בצורה מפורשת.
לבדיקת רשימת המשימות לפני השקה
לפני העלאה ל-Google Play, כדאי לבדוק שוב את הפריטים הבאים. חשוב לזכור שאלה רלוונטית באופן ספציפי למספר חבילות APK, ובשום אופן אינה מייצגת רשימת משימות מלאה אפליקציות שמועלות ל-Google Play.
- שם החבילה של כל קובצי ה-APK צריך להיות זהה.
- כל חבילות ה-APK צריכות להיות חתומות באמצעות אותו אישור.
- אם חבילות ה-APK חופפות בגרסת הפלטפורמה, החבילה עם ה-minSdkVersion הגבוהה יותר חייבת לכלול קוד גרסה גבוה יותר.
- בכל גודל מסך שבו אתם רוצים שה-APK יתמוך, יש להגדיר את הערך True במניפסט. כל גודל מסך שרוצים למנוע את השינוי, מגדירים את הערך False.
- בודקים היטב את מסנני המניפסט לאיתור מידע סותר (APK שתומך רק ב-APK אף אחד לא יראה את הקאפקייק במסכי XLARGE)
- מניפסט של כל APK חייב להיות ייחודי לפחות לאחד מסך נתמך, מרקם OpenGL או גרסת הפלטפורמה.
- נסו לבדוק כל חבילת APK במכשיר אחד לפחות. מלבד זאת, יש לכם אחד אמולטורים של מכשירים שניתן להתאים אישית בעסק, שממוקמים במכונת הפיתוח שלכם. השתגע!
כדאי גם לבדוק את ה-APK המורכב לפני שדוחפים אותו לשוק, כדי לוודא שאין בו הפתעות שעלולות להסתיר את האפליקציה ב-Google Play. זה בעצם די פשוט באמצעות 'aapt' של Google. 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, חשוב לוודא שאין לך ערכים מתנגשים תומך במסכים ובמסכים תואמים, ושאין לך מכשיר שמתכוון ל-'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 מטרגטות את המכשירים הרצויים. מזל טוב, סיימת!