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

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

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

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

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

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

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

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

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

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

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

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

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

   {
   "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: לאתר כדי לשמור את השינויים. עכשיו אפשר לבדוק את גרסת הטיוטה ולהשיק אותה דרך 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."}
      ]
  }]
}