חבילות APK ומסלולים

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

הוספה ושינוי של קובצי APK

1. מעלים קובץ APK אחד או יותר באמצעות הקריאה לשיטה Edits.apks: upload.

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

2. כדי לפרסם קובצי APK ב'מסלולים', צריך להתקשר אל Edits.tracks: update. אפשר לפרסם קובצי APK במסלולים הבאים:

   • מסלולי הפצה לבדיקה כמו "alpha" ו-"beta"

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

   • המסלול לבדיקה פנימית: "qa"

     גרסאות פנימיות של האפליקציה נפרסות במסלול הבדיקה הפנימית שהוגדר ב-Google Play Console.

   • המסלול לסביבת הייצור: "production"

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

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

שם הטראק של טראקים של גורמי צורה

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

מבנה	תחילית
Android Automotive OS	כלי רכב
Wear OS	לבוש
Android TV	טלוויזיה
Android XR	android_xr
‫Google Play Games במחשב	google_play_games_pc

איך מחשבים את שם הטראק עבור טראק של גורם צורה נתון?

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

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

אפשר לחשב את שם המסלול של גורם צורה מסוים באופן הבא: "[prefix]:defaultTrackName". לדוגמה, ב-Wear OS יהיו רצועות עם השמות: "wear:production",‏ "wear:beta" ו-"wear:qa".

מסלולי הפצה לבדיקות סגורות נוצרים באופן ידני ויש להם שמות בהתאמה אישית. לכן, מסלול בדיקות סגור לגורם צורה עם השם $name יקבל את שם המסלול "[prefix]:$name".

דוגמה לתהליך עבודה של APK

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

1. פותחים עריכה חדשה, כמו שמתואר בתהליך העבודה של עריכות
2. קוראים לשיטה Edits.apks: upload עבור כל קובץ APK שרוצים להעלות. מעבירים את ה-APK בגוף הבקשה של השיטה. (הפעולה הזו ממקמת את ה-APK באזור אחסון, אבל לא משיקה אותו במסלול הפצה או פורסת אותו). השיטה מחזירה קוד גרסה לכל חבילת APK שמעלים. קוד הגרסה הזה משמש להתייחסות לחבילת ה-APK כשמשיקים אותה במסלול.

3. קוראים לשיטה Edits.tracks: update לכל מסלול שרוצים לפרסם בו קובצי APK. בגוף הבקשה, מעבירים משאב Edits.tracks שמכיל את הפריט שרוצים להשיק. לדוגמה, כדי לפרסם APK עם קוד גרסה 88:

   {
   "releases": [{
     "versionCodes": ["88"],
     "status": "completed"
   }]
   }

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

4. קוראים לשיטה Edits: commit כדי לבצע את השינויים. אחרי שתעשו את זה, המשתמשים בכל מסלול יקבלו את הגרסה המעודכנת של ה-APK. (כמו בכל עריכה, יכול להיות שיחלפו כמה שעות עד שהשינויים ייכנסו לתוקף).

השקות מדורגות

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

בקטע הזה מוסבר איך לבצע השקה מדורגת של קובץ APK, ואז להעביר אותו לסביבת הייצור:

1. יוצרים עריכה, כמו שמתואר במאמר בנושא תהליך העבודה של עריכות.

2. מעלים APK חדש לעריכה באמצעות ה-method‏ Edits.apks: upload.

3. מתחילים "inProgress" השקה מדורגת במסלול הייצור באמצעות ה-method‏ Edits.tracks: update. בוחרים את החלק היחסי של המשתמשים שיקבלו את קובץ ה-APK החדש. בשלב הזה, קובץ ה-APK עדיין לא זמין למשתמשי הקצה.

   {
   "releases": [{
     "versionCodes": ["99"],
     "userFraction": 0.05,
     "status": "inProgress"
   }]
   }

4. מבצעים את השינויים בעריכה הפעילה על ידי קריאה ל-Edits: commit. במהלך השעות הקרובות, חבילת ה-APK החדשה תושק למשתמשים. חלק המשתמשים שתבחרו יקבלו את חבילת ה-APK החדשה.

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

הגדלת שיעור המשתמשים בהשקה מדורגת

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

1. יוצרים עריכה, כמו שמתואר במאמר תהליך העבודה של עריכות.

2. משנים את "inProgress" ההפצה בשלבים במסלול לסביבת הייצור באמצעות השיטה Edits.tracks: update. הגדלת שיעור המשתמשים שיקבלו את קובץ ה-APK החדש:

   {
   "releases": [{
     "versionCodes": ["99"],
     "userFraction": 0.1,
     "status": "inProgress"
   }]
   }

3. מבצעים את השינויים בעריכה הפעילה על ידי קריאה ל-Edits: commit. במהלך השעות הקרובות, חבילת ה-APK החדשה תושק למשתמשים. חלק המשתמשים שתבחרו יקבלו את חבילת ה-APK החדשה.

הפסקה של השקה מדורגת

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

1. יוצרים עריכה, כמו שמתואר במאמר בנושא תהליך העבודה של עריכות.

2. משנים את "inProgress" ההפצה בשלבים במסלול לסביבת הייצור באמצעות השיטה Edits.tracks: update. מגדירים את הסטטוס לערך "halted".

   {
   "releases": [{
     "versionCodes": ["99"],
     "status": "halted"
   }]
   }

3. מבצעים את השינויים בעריכה הפעילה על ידי קריאה ל-Edits: commit. הגרסה לא תהיה זמינה יותר למשתמשים חדשים.

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

השלמת השקה מדורגת

אחרי שאתם מרוצים מההשקה המדורגת ורוצים להשיק את הגרסה ל-100% מהמשתמשים, אתם יכולים להגדיר את סטטוס ההשקה ל"completed":

1. יוצרים עריכה, כמו שמתואר במאמר בנושא תהליך העבודה של עריכות.

2. משנים את "inProgress" ההפצה בשלבים במסלול לסביבת הייצור באמצעות השיטה Edits.tracks: update. מגדירים את הסטטוס לערך "completed".

   {
   "releases": [{
     "versionCodes": ["99"],
     "status": "completed"
   }]
   }

3. מבצעים את השינויים בעריכה הפעילה על ידי קריאה ל-Edits: commit. במהלך השעות הקרובות, חבילת ה-APK החדשה תושק למשתמשים. חלק המשתמשים שתבחרו יקבלו את חבילת ה-APK החדשה.

הפסקת השקה שהושלמה

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

1. יוצרים עריכה, כמו שמתואר במאמר בנושא תהליך העבודה של עריכות.

2. משנים את הגרסה של "completed" במסלול לסביבת הייצור באמצעות ה-method‏ Edits.tracks: update. הגדרת הסטטוס ל"halted".

   {
   "releases": [{
     "versionCodes": ["99"],
     "status": "halted"
   }]
   }

3. מבצעים את השינויים בעריכה הפעילה על ידי קריאה ל-Edits: commit. הגרסה לא תהיה יותר זמינה למשתמשים חדשים או למשתמשים קיימים לשדרוג.

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

אם מתקשרים אל GetTrack או אל ListTracks בזמן שהפצת גרסת "completed" מושהית, הגרסה שמוצגת במסלול שבו הופצה קודם גרסת "completed" תהיה 'הפצת גרסת חזרה'.

לדוגמה, אם היה לכם טראק alpha שנראה כך:

{
  "track": "alpha",
  "releases": [
    {
      "name": "2 (2.0)",
      "versionCodes": [
        "2"
      ],
      "status": "completed"
    }
  ]
}

והפסקתם את ההפצה של "completed" בהתאם לשלבים שמופיעים בקטע הזה, התקשרות אל GetTrack עבור מסלול alpha תחזיר משהו כזה:

{
  "track": "alpha",
  "releases": [
    {
      "name": "2 (2.0)",
      "versionCodes": [
        "2"
      ],
      "status": "halted"
    },
    {
      "name": "1 (1.0)",
      "versionCodes": [
        "1"
      ],
      "status": "completed"
    }
  ]
}

אם תחליטו בהמשך לחדש את "completed" ההפצה, תוכלו לעשות זאת על ידי שינוי הסטטוס שלה בחזרה ל"inProgress" או ל"completed". שימו לב שאפשר ליצור גרסת סטטוס חדשה של "inProgress" על בסיס גרסת "completed", אבל אז תוכלו רק להמשיך את ההשקה של גרסת "completed" עד ל-100% (כלומר, עד לסטטוס של "completed").

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

גרסאות טיוטה

גרסאות טיוטה מאפשרות להעלות קובצי APK באופן אוטומטי וליצור גרסה באמצעות ממשק ה-API, שאפשר לפרוס אותה מאוחר יותר באמצעות Google Play Console. כדי ליצור גרסת טיוטה במסלול הפצה:

1. פותחים עריכה חדשה, כמו שמתואר בתהליך העבודה של עריכות
2. קוראים לשיטה Edits.apks: upload עבור כל קובץ APK שרוצים להעלות. מעבירים את ה-APK בגוף הבקשה של השיטה. השיטה מחזירה קוד גרסה לכל APK שמעלים. קוד הגרסה הזה משמש להתייחסות ל-APK כשמקצים אותו לגרסה.

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

   {
   "releases": [{
     "name": "My draft release",
     "versionCodes": ["88"],
     "status": "draft"
   }]
   }

4. קוראים לשיטה Edits: commit כדי לבצע את השינויים. מעכשיו אפשר לבדוק את טיוטת הגרסה ולהשיק אותה באמצעות Google Play Console או API.

קביעת נתוני הגרסה

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

כדי לעשות את זה, צריך להשתמש בשדה "releaseNotes" כשמספקים Edits.tracks resource לשיטה Edits.tracks: update.

{
  "releases": [{
      "name": "Release with notes",
      "versionCodes": ["88"],
      "status": "completed",
      "releaseNotes": [
        {"language": "en-US", "text": "Describe what's new in this release."}
      ]
  }]
}