APK 和測試群組

您可以使用 Google Play Developer API 上傳應用程式的新 APK，並發布至不同的發布測試群組。您可以藉此部署應用程式的 Alpha 版和 Beta 版，並提供給已獲准的使用者。您也可以藉此部署階段推出版本，系統會自動將該版本提供給少數應用程式使用者。發布階段推出版本後，您可以逐步增加取得該版本應用程式的使用者人數，直到最終將該版本部署為「正式版」。

新增及修改 APK

  1. 呼叫 Edits.apks: upload 方法，上傳一或多個 APK。

    這個方法會將 APK 上傳至儲存空間「儲存區」，並指派至「測試群組」，以便部署給使用者。(如果刪除或捨棄編輯內容，上傳至該編輯內容的任何 APK 也會遺失)。

  2. 呼叫 Edits.tracks: update，在「測試群組」中發布 APK。您可以在下列測試群組中發布 APK：

    • 測試群組，例如 "alpha" 和 "beta"

      應用程式的 Alpha 版和 Beta 版會部署給您指派給 Alpha 版和 Beta 版測試群組的使用者。您可以使用 Google Play 管理中心，將使用者指派給這些群組。

    • 內部測試群組："qa"

      應用程式的內部版本會部署到內部測試群組，如 Google Play 管理中心所設定。

    • 正式版群組："production"

      「正式版」群組中的版本會部署給所有使用者。您可以在「正式版」群組中採用階段性發布，先向一小部分正式版使用者發布版本，然後隨著對版本越來越有信心，逐步提高這個百分比，確保發布過程安全無虞。

    簡單模式使用者不應在任何測試群組中放置多個 APK。如果進階模式使用者支援多個 APK，可以為每個測試群組上傳零個、一個或多個 APK。

板型規格測試群組的測試群組名稱

表單因素軌的軌名稱會加上特定 ID 前置字串。

外型規格 前置字串
Android Automotive OS 汽車業
Wear OS Wear
Android TV 電視
Android XR android_xr
Google Play 遊戲電腦版 google_play_games_pc

如何計算特定外型規格軌的軌名稱？

正式版、公開測試和內部測試等常見群組類型都有已知的群組名稱。

追蹤類型 預設音軌名稱
正式版 製片
公開測試 Beta 版
內部測試 qa

特定板型規格軌的軌名稱可計算為： "[prefix]:defaultTrackName"。 舉例來說，Wear OS 裝置的測試群組名稱會是："wear:production"、"wear:beta" 和 "wear:qa"。

封閉測試群組是手動建立，且名稱可自訂。因此，如果表單因素的封閉測試群組名稱為「$name」，則群組名稱會是「"[prefix]:$name"」。

APK 工作流程範例

本節說明 Tracks API 的一般用法。在本例中，我們假設您要為每個測試群組上傳新版 APK，並指派一定數量的使用者接收階段性發布版本。(實際上，開發人員不太可能在同一項作業中執行所有這些動作；相反地，您可能會在某天更新 Beta 版，在另一天建立「正式版」的階段性發布版本，依此類推)。

  1. 按照「編輯工作流程」一文的說明，開啟新的編輯內容
  2. 針對要上傳的每個 APK，呼叫 Edits.apks: upload 方法。在方法的要求主體中傳遞 APK。(這會將 APK 放在儲存空間，但不會在測試群組中發布或部署。)這個方法會傳回您上傳的每個 APK 的版本代碼；您將使用這個版本代碼，在測試群組中發布 APK 時參照該 APK。

  3. 針對要發布 APK 的每個測試群組，呼叫 Edits.tracks: update 方法。在要求主體中，傳遞包含要推出版本的 Edits.tracks 資源。舉例來說，如要發布版本代碼為 88 的 APK，請執行下列操作：

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

    此時，使用者仍無法使用 APK。與其他編輯作業一樣，變更必須先經過確認才會生效。

  4. 呼叫「Edits: commit」方法，提交變更。完成後，各群組的使用者就會收到更新版 APK。(與所有編輯作業一樣，變更可能需要數小時才會生效)。

階段推出

如果您有新版 APK，想逐步部署，可以選擇以「階段性發布」版本發布。完成後，Google Play 會自動將應用程式部署至您指定比例的目標使用者。如果「發布」APK 沒有任何問題 (例如當機等)，您可以增加接收該版本的使用者比例；準備就緒後，即可將該 APK 部署為新的正式版。

本節說明逐步推出 APK，然後將其升級至正式版的步驟：

  1. 按照「編輯工作流程」一文中的說明建立編輯內容。

  2. 使用 Edits.apks: upload 方法，將新的 APK 上傳至編輯作業。

  3. 使用 Edits.tracks: update 方法，在正式版群組中啟動 "inProgress" 階段推出作業。選擇應接收新 APK 的使用者比例。此時，任何使用者都還無法使用 APK。

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

  4. 呼叫「Edits: commit」，在有效編輯中提交變更。新 APK 會在接下來幾小時內推出給使用者。所選使用者比例會收到新的 APK。

視階段推出結果而定，您可能會想提高可取得該版本的使用者百分比，或暫停發布。

提高階段性推出作業的使用者比例

假設您正在進行 5% 的階段性推出作業 (如上一節所述)，本節將說明在發布作業順利進行時，如何提高百分比：

  1. 如「編輯工作流程」一文所述，建立編輯內容。

  2. 使用 Edits.tracks: update 方法，變更正式版群組的"inProgress"階段推出設定。提高應接收新 APK 的使用者比例：

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

  3. 呼叫「Edits: commit」，在有效編輯中提交變更。新 APK 會在接下來幾小時內推出給使用者。所選使用者比例會收到新的 APK。

暫停階段推出作業

假設您正在進行 5% 的階段性推出作業 (如上一節所述)，本節將說明如何停止階段性推出作業 (如果您發現問題)：

  1. 按照「編輯工作流程」一文中的說明建立編輯內容。

  2. 使用 Edits.tracks: update 方法，變更正式版群組的"inProgress"階段推出設定。將狀態設為 "halted"。

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

  3. 呼叫「Edits: commit」，在有效編輯中提交變更。新使用者將無法再下載您的版本。

如果之後決定恢復已暫停發布的版本，請將狀態設回 "inProgress"。

完成階段推出

如果對階段推出結果感到滿意，並想向所有使用者推出版本，請將發布狀態設為 "completed"：

  1. 按照「編輯工作流程」一文中的說明建立編輯內容。

  2. 使用 Edits.tracks: update 方法，變更正式版群組的"inProgress"階段推出設定。將狀態設為 "completed"。

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

  3. 呼叫「Edits: commit」，在有效編輯中提交變更。新 APK 會在接下來幾小時內推出給使用者。所選使用者比例會收到新的 APK。

暫停已完成的階段推出

假設您已完成先前章節所述的發布程序，並將應用程式發布到某個測試群組，本節將說明如何停止發布程序 (如果發現問題)：

  1. 按照「編輯工作流程」中的說明建立編輯內容。

  2. 使用 Edits.tracks: update 方法，變更正式版群組中的「"completed"」版本。將狀態設為 "halted"。

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

  3. 呼叫「Edits: commit」，在有效編輯中提交變更。新使用者將無法再下載您的版本，現有使用者也無法升級至該版本。

系統將開始放送取代 "completed" 版本的版本，該版本是已發布且未暫停的先前 "completed" 版本。請注意，這表示只有在測試群組中已發布一或多個版本時，您才能暫停測試群組中的版本。"completed""completed"

如果 "completed" 版本停止發布時，您呼叫 GetTrack 或 ListTracks，「提供備用版本」會顯示為先前停止發布 "completed" 版本的軌道上已完成的版本。

舉例來說，假設您一開始的 alpha 軌跡如下：

{
  "track": "alpha",
  "releases": [
    {
      "name": "2 (2.0)",
      "versionCodes": [
        "2"
      ],
      "status": "completed"
    }
  ]
}

並按照本節中的步驟停止 "completed" 版本發布，則呼叫 alpha 軌會傳回類似下列內容：GetTrack

{
  "track": "alpha",
  "releases": [
    {
      "name": "2 (2.0)",
      "versionCodes": [
        "2"
      ],
      "status": "halted"
    },
    {
      "name": "1 (1.0)",
      "versionCodes": [
        "1"
      ],
      "status": "completed"
    }
  ]
}

如果之後決定恢復"completed"發布，請將狀態設回 "inProgress" 或 "completed"。請注意，您可以在 "completed" 版本上建立新的 "inProgress" 狀態版本，但之後只能將 "completed" 版本恢復為 100% (即 "completed" 狀態)。

草稿版本

您可以透過 API 自動上傳 APK 並建立草稿版本，之後再透過 Google Play 管理中心部署。如要在測試群組中建立草稿版本，請按照下列步驟操作：

  1. 按照「編輯工作流程」一文的說明，開啟新的編輯內容
  2. 針對要上傳的每個 APK，呼叫 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 管理中心或 API，檢查並推出草稿版本。

指定版本資訊

發布新版應用程式時，您可以在版本中指定版本資訊，向使用者說明新功能。

如要這麼做，請在將 Edits.tracks 資源提供給 Edits.tracks: update 方法時，使用 "releaseNotes" 欄位。 

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