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

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

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

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

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

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

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

משימות שצריך לבצע כדי להתכונן לפרסום

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

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

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

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

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

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

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

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

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

מידע על דרישות האישור מופיע במאמר חתימה על האפליקציה.

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

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

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

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

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

הסכם רישיון למשתמש קצה

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

חומרים שונים

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

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

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

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

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

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

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

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

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

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

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

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

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

בנוסף, צריך להסיר את כל הקריאות למעקב Debug שנוספו לקוד, כמו startMethodTracing() וקריאות לשיטות stopMethodTracing().

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

פינוי מקום בספריות הפרויקט

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

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

בדיקה ועדכון של קובץ המניפסט והגדרות ה-build של 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 Play.

בעיות תאימות של כתובות

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

הוספת תמיכה בהגדרות של כמה מסכים.

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

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

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

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

‫

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

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

איך יוצרים אפליקציות באמצעות Android Studio

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

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

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

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

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

בדיקת האפליקציה לפני הפרסום

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

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