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

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

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

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

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

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

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

לפני שם הטראק של מסלול הטופס מופיע מזהה ספציפי.

גורם צורה	קידומת
Android Automotive OS	כלי רכב
Wear OS	לבוש

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

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

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

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

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

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

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

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