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

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

הוספה ושינוי של חבילות APK

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

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

2. כדי לפרסם חבילות APK ב-"tracks", יש לקרוא ל-Edits.tracks: update. ניתן לפרסם חבילות APK במסלולים הבאים:

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

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

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

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

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

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

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

שם המעקב אחר מסלולים של גורם צורה

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

מבנה	קידומת
Android Automotive OS	כלי רכב
Wear OS	לבוש
Android TV	טלוויזיה

איך מחשבים את השם של מסלול הפצה שמוגדר לגורם צורה מסוים?

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

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

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

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

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

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

1. פותחים עריכה חדשה כמו שמוסבר במאמר Edits Workflow
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: commitment. לאחר מכן, משתמשים בכל מסלול יקבלו את הגרסה המעודכנת של ה-APK. (כמו בכל פעולת עריכה, ייתכן שיחלפו מספר שעות עד שהשינויים ייכנסו לתוקף).

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

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

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

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

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

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

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

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

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

הגדלת אחוז המשתמשים בהשקה מדורגת

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

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

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

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

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

עצירת השקה מדורגת

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

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

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

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

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

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

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

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

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

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

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

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

גרסאות טיוטה

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

1. פותחים עריכה חדשה כמו שמוסבר במאמר Edits Workflow
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: commitment. עכשיו אפשר לבדוק ולהשיק את גרסת הטיוטה דרך Google Play Console או ה-API.

ציון נתוני הגרסה

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

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

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