הכנת האפליקציה לגרסה

כדי להכין את האפליקציה לגרסה, צריך להגדיר, ליצור ולבדוק גרסה של האפליקציה. משימות ההגדרה כוללות קוד בסיסי משימות של ניקוי ושינוי קוד שיעזרו לבצע אופטימיזציה של האפליקציה. תהליך ה-build בדומה לתהליך ה-build של ניפוי הבאגים, וניתן לבצע אותה באמצעות הכלים של JDK ו-Android SDK.

בדיקה המשימות משמשות כבדיקה אחרונה שעוזרת להבטיח שהאפליקציה פועלת כמצופה בעולם האמיתי את התנאים וההגבלות. פלטפורמת Firebase מציעה קבוצה גדולה של מכשירי בדיקה פיזיים וגם מכשירים וירטואליים באמצעות Firebase Test Lab, שבהם משתמשים כדי לשפר את איכות האפליקציה.

בסיום הכנת האפליקציה להפצה, יש קובץ APK חתום, שאותו אפשר להפיץ ישירות למשתמשים או להפיץ זירת מסחר של אפליקציות, כמו Google Play.

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

הערה: מומלץ לוודא שהאפליקציה עומדת בכל גרסה של קריטריונים לפונקציונליות, ביצועים ויציבות לפני ביצוע המשימות המתוארות בדף הזה.

איור 1. ההכנה לפרסום היא תהליך פיתוח נדרש והוא השלב הראשון בתהליך הפרסום.

משימות שצריך להתכונן לקראת ההשקה

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

איור 2. יש חמש משימות עיקריות שיעזרו לכם להכין את האפליקציה גרסה חדשה.

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

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

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

איסוף חומרים ומשאבים

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

מפתחות קריפטוגרפיים

לפי דרישת Android, כל חבילות ה-APK חתומות דיגיטלית עם אישור לפני ההתקנה שלהן במכשיר או מעודכנת. בחנות Google Play, כל האפליקציות שנוצרו אחרי אוגוסט 2021 כדי להשתמש בהן חתימת אפליקציה של Play. אבל אם מעלים עדיין עליך לחתום על ה-AAB ל-Play Console באמצעות אישור המפתח שלך. בי"ס יסודי אפליקציות עדיין יכולות לבצע חתימה עצמית, אבל גם אם משתמשים בחתימת אפליקציה ב-Play וגם אם בחתימה עצמית, עליכם לחתום על האפליקציה לפני שתוכלו להעלות אותה.

למידע נוסף על הדרישות לקבלת אישורים, ראו חתימה את האפליקציה שלך.

חשוב: צריך לחתום על האפליקציה באמצעות הצפנה קריפטוגרפית מפתח שתקופת התוקף שלו מסתיימת אחרי 22 באוקטובר 2033.

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

סמל האפליקציה

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

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

הסכם הרישיון עם משתמש הקצה (EULA)

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

חומרים שונים

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

הגדרת האפליקציה לגרסה

אחרי שתאספו את כל החומרים התומכים תוכלו להתחיל להגדיר את האפליקציה להשקה. בקטע הזה מוצג סיכום של השינויים שמומלץ לבצע בהגדרות האישיות לקוד המקור, לקובצי המשאבים ולקובץ המניפסט של האפליקציה לפני השקת האפליקציה.

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

בחירת מזהה אפליקציה מתאים

חשוב לבחור מזהה אפליקציה שמתאים לכל משך החיים של האפליקציה. שלך לא יכול לשנות את מזהה האפליקציה לאחר הפצת האפליקציה למשתמשים. כדי להגדיר זאת, משתמשים במאפיין applicationId ברמת המודול קובץ build.gradle או build.gradle.kts. מידע נוסף זמין במאמר הבא: מגדירים את מזהה האפליקציה.

השבתת ניפוי באגים

כדי להגדיר אם ה-APK ניתן לניפוי באגים, יש להשתמש בדגל debuggable עבור גרובי או הדגל isDebuggable עבור סקריפט Kotlin:

Kotlin

  android {
    ...
    buildTypes {
      release {
        isDebuggable = false
        ...
      }
      debug {
        isDebuggable = true
        ...
      }
    }
    ...
  }
  

מגניב

  android {
    ...
    buildTypes {
      release {
        debuggable false
        ...
      }
      debug {
        debuggable true
        ...
      }
    }
    ...
  }

הפעלה והגדרה של כיווץ האפליקציה

אפשר לבצע הרבה מהאופטימיזציות הבאות באופן אוטומטי על-ידי הפעלת כיווץ ב-build של הגרסה. לדוגמה, אפשר להוסיף כללי ProGuard להסרת הצהרות יומן, וה-shrinker יזהה ויסיר קוד שלא נמצא בשימוש המשאבים. ה-shynker יכול גם להחליף שמות של מחלקות ומשתנים בשמות קצרים יותר להקטין את ה-DEX.

השבתת הרישום ביומן

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

בנוסף, יש להסיר את כל Debug מעקב אחרי שיחות שהוספתם לקוד, כמו startMethodTracing() ו stopMethodTracing() קריאות ל-method.

חשוב: הקפידו להשבית את ניפוי הבאגים עבור האפליקציה שלך אם משתמשים ב-WebView כדי להציג תוכן בתשלום או אם משתמשים בממשקי JavaScript, כי ניפוי הבאגים מאפשר למשתמשים ולחלץ תוכן באמצעות כלי הפיתוח ל-Chrome. כדי להשבית ניפוי באגים, משתמשים WebView.setWebContentsDebuggingEnabled() .

פינוי של ספריות הפרויקט

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

• בדיקת התוכן של cpp/, lib/ ו-src/ של ספריות. הספרייה cpp/ צריכה להכיל רק קובצי מקור שמשויכים אל Android NDK, למשל קובצי מקור מסוג C או C++, קובצי כותרות, או makefile. הספרייה lib/ צריכה להכיל רק קובצי ספרייה של צד שלישי, או של ספריות פרטיות, כולל ספריות משותפות וסטטיות מוכנות מראש. src/ צריכה להכיל רק את קובצי המקור של האפליקציה (Java, Kotlin ו-AIDL ). הספרייה src/ לא יכולה להכיל קובצי JAR.
• בודקים אם יש בפרויקט קובצי נתונים פרטיים או קנייניים שהאפליקציה לא משתמשת בהם ולהסיר אותם. לדוגמה, אפשר לחפש בספריית res/ של הפרויקט נתונים ישנים קבצים שניתנים להזזה, קובצי פריסה וקבצים עם ערכים שאתם כבר לא משתמשים בהם, ומוחקים אותם.
• מחפשים ספריות בדיקה בספרייה lib/, ואם לא, מסירים אותן כבר נמצא בשימוש באפליקציה.
• בדיקת התוכן של ספריית assets/ והres/raw/ שלך לספרייה לקובצי נכסים גולמיים וקבצים סטטיים שצריך לעדכן או להסיר לפני גרסה חדשה.

בדיקה ועדכון של הגדרות המניפסט ו-Gradle

צריך לוודא שהפריטים הבאים בקובצי המניפסט ובקובצי ה-build מוגדרים נכון:

• רכיב <uses-permission>

  לציין רק את ההרשאות שרלוונטיות ונדרשות אפליקציה.

• מאפיינים של android:icon ו-android:label

  צריך לציין ערכים למאפיינים האלה. הערכים האלה נמצאים <application> לרכיב מסוים.

• נכסים מסוג versionCode ו-versionName

  מומלץ לציין ערכים לנכסים האלה, שנמצאים באפליקציה build.gradle או build.gradle.kts ברמת המודול. לקבלת מידע נוסף מידע נוסף זמין במאמר גרסת האפליקציה.

יש כמה רכיבים נוספים בקובץ ה-build שאפשר להגדיר אם אתם משחררים את ב-Google Play. לדוגמה, minSdk ו- מאפייני targetSdk, שנמצאים ברמת מודול האפליקציה קובץ build.gradle או build.gradle.kts. לקבלת מידע נוסף על והגדרות אחרות של Google Play במאמר מסננים ב-Google הפעלה.

טיפול בבעיות תאימות

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

הוספת תמיכה בכמה הגדרות מסך.

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

אופטימיזציה של האפליקציה למסכים גדולים יותר.

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

כדאי להשתמש בספריות Jetpack.

Jetpack הוא חבילת ספריות של ספריות שעוזרות למפתחים לפעול לפי השיטות המומלצות ולצמצם את כמות הרכיבים הבוילרים ולכתוב קוד שפועל באופן עקבי בגרסאות ובמכשירים של Android.

עדכון כתובות URL לשרתים ולשירותים

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

הטמעת רישוי ב-Google Play

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

לקבלת מידע נוסף על שירות הרישוי של Google Play ועל אופן השימוש בו במאמר רישוי אפליקציות.

יצירת האפליקציה לגרסה

אחרי שתסיימו להגדיר את האפליקציה, תוכלו לפתח אותה כגרסה מוכנה להפצה קובץ APK חתום שעבר אופטימיזציה. ה-JDK כולל את הכלים לחתימה קובץ APK (Keytool ו-Jarsigner); ב-Android SDK יש כלים להידור לבצע אופטימיזציה של קובץ ה-APK. אם אתם משתמשים ב-Android Studio או אם אתם משתמשים את מערכת ה-build של Gradle, משורת הפקודה כך שניתן יהיה להפוך את תהליך ה-build כולו לאוטומטי. למידע נוסף על הגדרת גרסאות build של Gradle, ראו הגדרה של וריאציות build

אם אתם משתמשים באינטגרציה רציפה (CI) במערכת, אפשר להגדיר שמשימה תהפוך את תהליך ההפצה לאוטומטי. לא רק ומפתחים את ה-APK או ה-AAB להפצה. אפשר גם להגדיר אותו להעלות באופן אוטומטי את ה-build פריטי מידע שנוצרו בתהליך פיתוח(Artifact) ל-Play Console.

בנייה באמצעות Android Studio

אפשר להשתמש במערכת ה-build של Gradle, המשולבת עם Android Studio, כדי ליצור גרסה שמוכן לפרסום קובץ APK שנחתם באמצעות המפתח הפרטי שלכם ועבר אופטימיזציה. כדי ללמוד כיצד להגדיר להריץ גרסאות build מ-Android Studio. יצירה והפעלה של האפליקציה

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

הכנת שרתים ומשאבים חיצוניים

אם האפליקציה מסתמכת על שרת מרוחק, יש לוודא שהשרת מאובטח וש מוגדר לשימוש בסביבת הייצור. זה חשוב במיוחד אם אתם מטמיעים חיוב על רכישות באפליקציות באפליקציה, ביצוע שלב אימות החתימה בשרת מרוחק.

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

בדיקת האפליקציה לגרסה

בדיקה של גרסת ההפצה של האפליקציה עוזרת לוודא שהאפליקציה פועלת כמו שצריך. בתנאים מציאותיים של המכשיר והרשת. באופן אידיאלי, יש לבדוק את האפליקציה מכשיר אחד בגודל טלפון נייד ומכשיר אחד בגודל טאבלט כדי לאמת שהרכיבים של ממשק המשתמש שלך בגודל הנכון, ושהביצועים ויעילות הסוללה של האפליקציה קבילים. גם Firebase Test Lab יכול להועיל בדיקה במגוון מכשירים שונים וגרסאות Android OS.

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