אם אתם מפרסמים את האפליקציה ב-Google Play, עליכם ליצור קובץ Android App Bundle ולהעלות אותו. כשעושים זאת, Google Play יוצרת ומציגה באופן אוטומטי חבילות APK שעברו אופטימיזציה לכל תצורת מכשיר של משתמש, כך שהם מורידים רק את הקוד והמשאבים הנדרשים להפעלת האפליקציה. פרסום של כמה חבילות APK שימושי אם אתם לא מפרסמים ב-Google Play, אבל עליכם ליצור, לחתום ולנהל כל אחת מהן בעצמכם.
כשאתם מפתחים אפליקציה ל-Android כדי לנצל את היתרונות של כמה קובצי APK ב-Google Play, חשוב לאמץ כמה שיטות מומלצות כבר מההתחלה כדי למנוע כאבי ראש מיותרים בהמשך תהליך הפיתוח. במדריך הזה תלמדו איך ליצור כמה קובצי APK של האפליקציה, שכל אחד תומך בקבוצת משנה אחרת של פורמטים של טקסטורות ב-OpenGL. בנוסף, תלמדו על כלים שיעזרו לכם לשמור על קוד בסיס של כמה קובצי APK בצורה נוחה ככל האפשר.
מוודאים שצריך כמה חבילות APK
כשמנסים ליצור אפליקציה שפועלת בכל המכשירים הזמינים מבוססי Android, ברור שהרצון שלכם להראות את האפליקציה בצורה הטובה ביותר בכל מכשיר בנפרד, גם אם לא כולם תומכים באותה קבוצה של טקסטורות GL. בהתחלה אולי נראה שתמיכה בכמה חבילות APK היא הפתרון הטוב ביותר, אבל ברוב המקרים זה לא המצב. בקטע שימוש ב-APK יחיד במדריך למפתחים של חבילות APK מרובות, תוכלו למצוא מידע שימושי כיצד להשתלב ב-APK יחיד, כולל איך לזהות פורמטים נתמכים של טקסטורה בזמן ריצה. בהתאם למצב שלכם, יכול להיות שיהיה קל יותר לצרף את כל הפורמטים לאפליקציה ולבחור פשוט את הפורמט שבו רוצים להשתמש בזמן הריצה.
אם אתם יכולים לעשות זאת, יש כמה יתרונות להגבלת האפליקציה לחבילת APK אחת, כולל:
- פרסום ובדיקה בקלות רבה יותר
- יש רק בסיס קוד אחד שצריך לתחזק
- האפליקציה יכולה להתאים את עצמה לשינויים בהגדרות המכשיר
- שחזור האפליקציה בין מכשירים פשוט עובד
- אתם לא צריכים לדאוג לגבי העדפות השוק, ההתנהגות של משתמשים לאחר 'שדרוגים' מחבילת APK אחת לזו הבאה או איזו חבילת APK מתאימה לאילו סוגים של מכשירים.
בהמשך השיעור נניח שערכתם מחקר בנושא, שקראתם בעיון את החומר במשאבים המקושרים והחלטתם ששימוש בכמה קובצי APK הוא הדרך הנכונה לאפליקציה שלכם.
תרשים של הדרישות
במדריך למפתחי Android יש מידע שימושי על חלק מהטקסטורות הנפוצות הנתמכות, בדף supports-gl-texture. בדף הזה מפורטות גם כמה רמזים לגבי הטלפונים (או משפחות הטלפונים) שתומכים בפורמטים מסוימים של טקסטורות. חשוב לזכור שכדאי שאחד מחבילות ה-APK יתמוך ב-ETC1, כי כל מכשירי Android שתומכים במפרט OpenGL ES 2.0 תומכים בפורמט הטקסטורה הזה.
מאחר שרוב המכשירים עם Android תומכים ביותר מפורמט טקסטורה אחד, צריך לקבוע סדר העדפות. יוצרים תרשים שכולל את כל הפורמטים שהאפליקציה תתמוך בהם. התא הימני ביותר יקבל את העדיפות הנמוכה ביותר (סביר להניח שהוא יהיה ETC1, ברירת מחדל קבועה מאוד מבחינת ביצועים ותאימות). לאחר מכן צבע בתרשים כך שכל תא מייצג APK.
| ETC1 | ATI | PowerVR |
הצביעה בטבלה לא רק הופכת את המדריך לפחות מונוכרומטי, אלא גם עוזרת לשפר את התקשורת בתוך הצוות. עכשיו אפשר פשוט להתייחס לכל קובץ APK כ'כחול', 'ירוק' או 'אדום', במקום 'הקובץ שתומך בפורמטים של טקסטורות ETC1' וכו'.
הקצאת כל הקוד והמשאבים הנפוצים בפרויקט ספרייה
בין שאתם משנים אפליקציית 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 נתמך במכשיר שזמין בשוק, המכשיר נחשב מתאים
בנוגע ל-GL Textures, הכלל האחרון חשוב. לדוגמה, צריך להיות מאוד זהירים כשמשתמשים בפורמטים שונים של GL באותה אפליקציה. אם תשתמשו ב-PowerVR ב-99% מהמקרים, אבל תשתמשו ב-ETC1, למשל, במסך הפתיחה… במקרה כזה, המניפסט יציין תמיכה בשני הפורמטים. מכשיר שתומך רק ב-ETC1 ייחשב כתואם, תתבצע הורדה של האפליקציה שלכם והמשתמש יראה הודעות קריסה מרגשות. במקרה הנפוץ, אם משתמשים בכמה חבילות APK במיוחד כדי לטרגט מכשירים שונים על סמך תמיכה בטקסטורות של GL, יהיה פורמט טקסטורה אחד לכל חבילת APK.
לכן, התמיכה בטקסטורות שונה במקצת משתי התכונות האחרות של קובצי APK מרובים: רמת ה-API וגודל המסך. לכל מכשיר יש רק רמת API אחת וגודל מסך אחד, וכל ה-APK יכול לתמוך במגוון כזה. עם טקסטורות, ה-APK יתמוך בדרך כלל בטקסטורה אחת, והמכשיר יתמוך בהרבה טקסטורות. לעיתים קרובות תהיה חפיפה מבחינת מכשיר אחד שתומך ב-APKs רבים, אבל הפתרון הוא זהה: קודי גרסאות.
לדוגמה, כדאי לקחת כמה מכשירים ולבדוק כמה מחבילות ה-APK שהוגדרו קודם לכן מתאימות לכל מכשיר.
| FooPhone | Nexus S | Evo |
| ETC1 | ETC1 | ETC1 |
| PowerVR | ATI TC |
בהנחה שפורמטים של PowerVR ו-ATI מועדפים על פני ETC1 כשהם זמינים, בהתאם לכלל 'המספר הגבוה ביותר של הגרסה מנצח', אם נגדיר את המאפיין versionCode בכל קובץ APK כך ש-red ≥ green ≥ blue, תמיד ייבחרו אדום וירוק על פני כחול במכשירים שתומכים בהם. אם בעתיד יופיע מכשיר שתומך גם באדום וגם בירוק, ייבחרו אדום.
כדי לשמור את כל חבילות ה-APK ב'מסלולים' נפרדים, חשוב להשתמש בסכימה טובה של קודי גרסאות. הקוד המומלץ מופיע בקטע 'קודי גרסאות' במדריך למפתחים שלנו. מכיוון שקבוצת הדוגמאות של חבילות ה-APK עוסקת רק באחד מ-3 המאפיינים האפשריים, מספיק להפריד כל חבילת APK ב-1,000 ולהגדיל ממנה. הדוגמה הזו יכולה להיראות כך:
כחול: 1001, 1002, 1003, 1004…
ירוק: 2001, 2002, 2003, 2004...
אדום:3001, 3002, 3003, 3004…
כשמרכזים את כל הנתונים האלה, קובצי ה-Android Manifests אמורים להיראות בערך כך:
כחול:
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
android:versionCode="1001" android:versionName="1.0" package="com.example.foo">
<supports-gl-texture android:name="GL_OES_compressed_ETC1_RGB8_texture" />
...
ירוק:
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
android:versionCode="2001" android:versionName="1.0" package="com.example.foo">
<supports-gl-texture android:name="GL_AMD_compressed_ATC_texture" />
...
אדום:
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
android:versionCode="3001" android:versionName="1.0" package="com.example.foo">
<supports-gl-texture android:name="GL_IMG_texture_compression_pvrtc" />
...
בדיקת רשימת המשימות לפני ההשקה
לפני ההעלאה ל-Google Play, חשוב לבדוק את הפריטים הבאים. חשוב לזכור שההנחיות האלה רלוונטיות במיוחד לכמה קובצי APK, והן לא מהוות רשימת משימות מלאה לכל האפליקציות שמעלים ל-Google Play.
- לכל קובצי ה-APK צריך להיות אותו שם חבילה.
- כל חבילות ה-APK חייבות להיות חתומות באותו אישור
- בודקים היטב את המסננים של המניפסט כדי לאתר מידע סותר (קובץ 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. אם רוב המכשירים המוגדלים (אם לא כולם) הם טאבלטים שאין בהם חומרת טלפוניה, במקרים כאלה מערכת Google Play תסנן את ה-APK הזה, עד שמכשירים עתידיים יהיו גדולים מספיק כדי לדווח כמסך גדול במיוחד ומחזיקים בחומרת טלפוניה.
למרבה המזל, אפשר לפתור את הבעיה בקלות על ידי הוספת הקוד הבא למניפסט:
<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 מטרגטים את המכשירים המיועדים. זהו, סיימתם!