יצירת כמה חבילות APK לגדלים שונים של מסכים

אם אתם מפרסמים את האפליקציה ב-Google Play, עליכם ליצור קובץ Android App Bundle ולהעלות אותו. לאחר מכן, Google Play יוצרת ומציגה באופן אוטומטי חבילות APK שעברו אופטימיזציה בהתאם לתצורת המכשיר של כל משתמש, כך שהם מורידים רק את הקוד והמשאבים שדרושים להם כדי להפעיל את האפליקציה. פרסום של חבילות APK מרובות שימושי אם לא מפרסמים מספר חבילות APK ב-Google Play, אבל חובה ליצור, לחתום ולנהל כל APK בעצמכם.

כשאתם מפתחים אפליקציה ל-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 – "small and all else" או "xlarge וכל השאר". הצביעה בטבלה גם מאפשרת תקשורת קלה יותר בין חברי הצוות – עכשיו אפשר פשוט להתייחס לכל קובץ APK כ'כחול', 'ירוק' או 'אדום', ללא קשר למספר סוגי המסכים השונים שהוא מכסה.

הקצאת כל הקוד והמשאבים הנפוצים בפרויקט ספרייה

גם אם אתם משנים אפליקציה קיימת ל-Android וגם אם אתם יוצרים אפליקציה חדשה מאפס, זה הדבר הראשון שצריך לעשות ל-Codebase, והכי חשוב. כל מה שמופיע בפרויקט הספרייה צריך להתעדכן רק פעם אחת (למשל, מחרוזות מותאמות לשפה, נושאי צבעים, באגים שתוקנו בקוד משותף). כך תוכלו לקצר את זמני הפיתוח ולהפחית את הסיכוי לשגיאות שאפשר היה למנוע בקלות.

הערה: פרטי ההטמעה של יצירת פרויקטים של ספריות והכללתם בפרויקטים אחרים לא נכללים בנושא של השיעור הזה, אבל תוכלו לקרוא את המאמר יצירת ספרייה ל-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 עם מספר הגרסה הגבוה ביותר

לצורך הדוגמה, ניקח את סדרת חבילות ה-APK המרובות שתוארו קודם לכן ונניח שכל APK הוגדר לתמוך בכל גודלי המסכים שגדולים מגודל היעד של מסך היעד שלו. אם ניקח את הנתונים בנפרד, הטווח האפשרי של כל APK ייראה כך:

קטנות	רגיל	גדולה	xlarge
קטנות	רגיל	גדולה	xlarge
קטנות	רגיל	גדולה	xlarge

עם זאת, אם נשתמש בכלל 'המספר הגבוה ביותר של הגרסה מנצח', ונגדיר את המאפיין versionCode בכל קובץ APK כך ש-red ≥ green ≥ blue, התרשים יתכווץ למעשה כך:

קטנות

רגיל

גדולה

xlarge

כעת נניח גם של-APK האדום יש דרישה כלשהי שלא חלה על שתי ה-APK האחרות. בדף מסננים ב-Google Play במדריך למפתחי Android יש רשימה שלמה של גורמים אפשריים. לצורך הדוגמה, נניח שאדום דורש מצלמה קדמית. למעשה, כל העניין של קובץ ה-APK האדום הוא לנצל את שטח המסך הנוסף שזמין כדי לעשות דברים משעשעים עם המצלמה הקדמית. אבל מסתבר שלחלק מהמכשירים בגודל xlarge אין אפילו מצלמה קדמית! אימה!

למרבה המזל, אם משתמש מעיין ב-Google Play ממכשיר כזה, Google Play תבחן את המניפסט, תראה ש-Red מציג את המצלמה הקדמית כדרישה, ומתעלם ממנה בשקט, לאחר שקובעים שאדום שהמכשיר הזה לא תואם לגן עדן דיגיטלי. הוא יראה שהצבע ירוק לא תואם רק למכשירים בגודל xlarge, אלא גם לא משנה אם יש מצלמה קדמית או לא! המשתמשים עדיין יכולים להוריד את האפליקציה מ-Google Play, כי למרות כל התקרית עם המצלמה הקדמית, עדיין היה קובץ APK שתומך בגודל המסך הספציפי הזה.

כדי לשמור את כל חבילות ה-APK ב'מסלולים' נפרדים, חשוב להשתמש בסכימה טובה של קודי גרסאות. הגרסה המומלצת מופיעה באזור Version Codes של המדריך למפתחים. מכיוון שקבוצת ה-APK לדוגמה מתייחסת רק לאחד מ-3 מאפיינים אפשריים, אפשר להספיק להפריד בין חבילות ה-APK ב-1,000 ולהוסיף אותן משם. זה עשוי להיראות כך:

כחול: 1001, 1002, 1003, 1004...
ירוק: 2001, 2002, 2003, 2004...
אדום:3001, 3002, 3003, 3004…

על סמך כל המידע הזה, המניפסטים של Android עשויים להיראות כך:

כחול:

<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) הוא חלק מתהליך ה-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 מטרגטים את המכשירים המיועדים.

מידע נוסף על פרסום כמה קובצי APK ב-Google Play זמין במאמר תמיכה בכמה קובצי APK.