יצירת חבילות APK מרובות עם מספר מאפיינים

אם אתם מפרסמים את האפליקציה ב-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/גודל מסך. שפת תרגום יש לכם גם שמות קוד מגניבים לכל אחד מהם, כי "האם בדקנו את הצבע האדום?" זה הרבה קל יותר לשאול את הקובייה מאשר "האם בדקנו את ה-APK בגודל 3-10 גדול יותר בהשוואה ל-Xoom?" הדפסת הפריט ליצור תרשים ולתת אותו לכל מי שעובד על ה-codebase שלכם. החיים הופכים עכשיו לקלים יותר.

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

לא משנה אם אתם משנים אפליקציה קיימת ל-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.
  • הצבע האדום מתייחס למסכים גדולים במיוחד (בדרך כלל טאבלטים), 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 יפעלו עם התג 'מסכים שתומכים' או עם תואם למסכים תואמים. בדרך כלל עדיף תמיכה במסכים, וזה ממש לא טוב להשתמש בשני הסוגים- זה הופך דברים למורכבים שלא לצורך, ומעלה את הסיכוי לשגיאות. כמו כן, חשוב לשים לב שבמקום לנצל את ערכי ברירת המחדל (ערכים קטנים ורגילים תמיד נכונים כברירת מחדל), המניפסטים מגדירים באופן מפורש את הערך של כל גודל מסך. הפעולה הזו יכולה לחסוך לך דאגות בהמשך – למשל, מניפסט עם יעד SDK של < 9 יהיה גדול יותר מוגדר באופן אוטומטי כ-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) הוא חלק מתהליך ה-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 מטרגטות את המכשירים הרצויים. מזל טוב, סיימת!

הקודם
יצירת כמה חבילות APK למרקמים שונים של GL
הבא
תמיכה בשפות ותרבויות שונות