חבילות 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."}
      ]
  }]
}