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

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

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

1. כדי להעלות APK אחד או יותר, מפעילים את Edits.APKs: upload (העלאה).

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

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	טלוויזיה

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

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

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

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

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

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

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

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

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

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

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

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

השקות בשלבים

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

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

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

2. מעלים APK חדש לעריכה באמצעות Edits.APKs: upload (העלאה).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

גרסאות טיוטה

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

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

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

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

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