APK とトラック

Google Play Developer API では、アプリの新しい APK を複数アップロードして、それぞれを別のリリーストラックとしてリリースできます。これにより、承認済みのユーザーを対象にアルファ版やベータ版のアプリをデプロイするといったことが可能になります。また、少数のアプリユーザーのみに自動的に提供される、段階的な公開バージョンをデプロイすることもできます。段階的な公開バージョンをリリースしたら、そのバージョンを提供するユーザーの数を徐々に増やしていき、最終的にそのバージョンを「製品版」としてデプロイできます。

APK の追加と変更

1 つ以上の APK をアップロードするには、Edits.apks: upload メソッドを呼び出します。

このメソッドは、APK をストレージの「バケット」にアップロードします。バケットでは、APK をユーザーにデプロイするために「トラック」に割り当てます（編集を削除または破棄すると、その編集にアップロードされた APK も失われます）。
APK を「トラック」にリリースするには、Edits.tracks: update を呼び出します。次のトラックに APK をリリースできます。
- テストトラック（"alpha"、"beta" など）
  
  アルファ版とベータ版のアプリは、アルファ版とベータ版のテストグループに割り当てたユーザーにデプロイされます。これらのグループにユーザーを割り当てるには、Google Play Console を使用します。
- 内部テストトラック（"qa"）
  
  内部バージョンのアプリは、Google Play Console で構成された内部テストトラックにデプロイされます。
- 製品版トラック（"production"）
  
  「製品版」トラックへのリリースは、すべてのユーザーにデプロイされます。「製品版」トラックへの段階的リリースを利用すると、最初は少数の製品版ユーザーにリリースを安全にデプロイし、リリースの信頼性の評価が高まるにつれて段階的に製品版ユーザーの割合を増やすことができます。
シンプルモードのユーザーは、どのトラックにも複数の APK をアップロードできません。複数 APK のサポートを使用しているアドバンスモードのユーザーは、各トラックに 0 個、1 個、または複数の APK をアップロードできます。

フォームファクタトラックのトラック名

フォームファクタトラックのトラック名には、接頭辞として特定の識別子が付加されています。

フォームファクタ	接頭辞
Android Automotive OS	automotive
Wear OS	wear
Android TV	tv

特定のフォームファクタトラックのトラック名を計算する方法

製品版、オープンテスト、内部テストトラックなどの一般的なトラックタイプには、よく知られたトラック名が付いています。

トラックタイプ	デフォルトのトラック名
製品版	production
オープンテスト	beta
内部テスト	qa

特定のフォームファクタトラックのトラック名は、"[prefix]:defaultTrackName" として計算できます。たとえば、Wear OS のフォームファクタには、"wear:production"、"wear:beta"、"wear:qa" という名前のトラックがあります。

クローズドテストトラックは手動で作成され、カスタム名が付けられます。そのため、$name という名前のフォームファクタのクローズドテストトラックには "[prefix]:$name" というトラック名が付けられます。

APK ワークフローの例

このセクションでは、Tracks API の一般的な使い方について説明します。この例では、各トラックに新しいバージョンの APK をアップロードして、段階的な公開バージョンを受け取るユーザー数を割り当てます（実際には、ここで説明するアクションのすべてを同じオペレーションで一度に行うことはまれです。たとえば、ある日ベータ版を更新し、別の日に「製品版」トラックで段階的リリースを作成するという進め方がより現実的です）。

編集ワークフローに沿って新しい編集を開きます。
アップロードする APK ごとに、Edits.apks: upload メソッドを呼び出します。メソッドのリクエスト本文で APK を渡します（これにより APK はストレージ領域にアップロードされますが、トラックにリリースされたりデプロイされたりすることはありません）。このメソッドは、アップロードした各 APK のバージョンコードを返します。このコードは、APK をトラックにリリースする際に APK を参照するために使用します。
APK をリリースするトラックごとに、Edits.tracks: update メソッドを呼び出します。リクエスト本文で、ロールアウトするリリースを含む Edits.tracks リソースを渡します。たとえば、バージョンコード 88 の APK をリリースするには、次のコードを使用します。
```
{
"releases": [{
  "versionCodes": ["88"],
  "status": "completed"
}]
}
```
この時点では、ユーザーはまだ APK を利用できません。他の編集と同様に、変更は commit するまで反映されません。
Edits: commit メソッドを呼び出して変更を commit します。これにより、各トラックのユーザーに更新版の APK が提供されます（他の編集と同様に、変更が反映されるまで数時間かかることがあります）。

段階的な公開

新しいバージョンの APK を段階的にデプロイする場合は、「段階的な公開」バージョンとしてリリースします。この方法を選択すると、Google Play は指定した割合のアプリユーザーに自動的に APK をデプロイします。ロールアウトした APK に問題（クラッシュなど）がなければ、そのバージョンを提供するユーザーの割合を増やします。準備が整ったら、その APK を新しい製品版としてデプロイできます。

このセクションでは、APK の段階的な公開を実行し、その後製品版に昇格させる手順について説明します。

編集ワークフローに沿って編集を作成します。
Edits.apks: upload メソッドを使用して、編集に新しい APK をアップロードします。
Edits.tracks: update メソッドを使用して、製品版トラックで "inProgress" の段階的リリースを開始します。新しい APK を受け取るユーザーの割合を選択します。この時点では、エンドユーザーはまだ APK を利用できません。
```
{
"releases": [{
  "versionCodes": ["99"],
  "userFraction": 0.05,
  "status": "inProgress"
}]
}
```
Edits: commit を呼び出して、アクティブな編集内の変更を commit します。その後、数時間かけて新しい APK がユーザーにロールアウトされます。選択された割合のユーザーが新しい APK を受け取ります。

段階的な公開が成功したかどうかによって、そのリリースを受け取るユーザーの割合を増やすか、リリースを中止します。

段階的な公開でユーザーの割合を増やす

このセクションでは、前述の方法で 5% のユーザーに段階的な公開を行っていると仮定して、リリースが順調に進んだ場合にユーザーの割合を増やす方法について説明します。

編集ワークフローに沿って編集を作成します。
Edits.tracks: update メソッドを使用して、製品版トラックで "inProgress" の段階的リリースを変更します。新しい APK を受け取るユーザーの割合を増やすには、次のコードを使用します。
```
{
"releases": [{
  "versionCodes": ["99"],
  "userFraction": 0.1,
  "status": "inProgress"
}]
}
```
Edits: commit を呼び出して、アクティブな編集内の変更を commit します。その後、数時間かけて新しい APK がユーザーにロールアウトされます。選択された割合のユーザーが新しい APK を受け取ります。

段階的な公開を中止する

このセクションでは、前述の方法で 5% のユーザーに段階的な公開を行っているとして、問題を発見した場合に段階的な公開を中止する方法について説明します。

編集ワークフローに沿って編集を作成します。
Edits.tracks: update メソッドを使用して、製品版トラックで "inProgress" の段階的リリースを変更します。ステータスを "halted" に設定します。
```
{
"releases": [{
  "versionCodes": ["99"],
  "status": "halted"
}]
}
```
Edits: commit を呼び出して、アクティブな編集内の変更を commit します。リリースは新しいユーザーに提供されなくなります。

中止したリリースを後で再開する場合は、ステータスを "inProgress" に戻します。

段階的な公開を完了する

段階的な公開が成功したと評価し、100% のユーザーにリリースをロールアウトする場合は、リリースのステータスを "completed" に設定します。

編集ワークフローに沿って編集を作成します。
Edits.tracks: update メソッドを使用して、製品版トラックで "inProgress" の段階的リリースを変更します。ステータスを "completed" に設定します。
```
{
"releases": [{
  "versionCodes": ["99"],
  "status": "completed"
}]
}
```
Edits: commit を呼び出して、アクティブな編集内の変更を commit します。その後、数時間かけて新しい APK がユーザーにロールアウトされます。選択された割合のユーザーが新しい APK を受け取ります。

未公開のリリース

未公開のリリースでは、後で Google Play Console からデプロイできる状態の API を使用して、自動的に APK をアップロードしてリリースを作成できます。未公開のリリースをトラックに作成する手順は次のとおりです。

編集ワークフローに沿って新しい編集を開きます。
アップロードする APK ごとに、Edits.apks: upload メソッドを呼び出します。メソッドのリクエスト本文で APK を渡します。このメソッドは、アップロードした各 APK のバージョンコードを返します。このコードは、APK をリリースに割り当てる際に APK を参照するために使用します。
リリースするトラックごとに、Edits.tracks: update メソッドを呼び出します。リクエスト本文で、作成する未公開のリリースを含む Edits.tracks リソースを渡します。次に例を示します。
```
{
"releases": [{
  "name": "My draft release",
  "versionCodes": ["88"],
  "status": "draft"
}]
}
```
Edits: commit メソッドを呼び出して変更を commit します。以上により、Google Play Console または API で未公開のリリースを検査およびロールアウトできるようになります。

リリースノートを指定する

新しいバージョンのアプリをリリースする際に、リリースにリリースノートを指定して、新機能をユーザーに明確に知らせることができます。

これを行うには、Edits.tracks: update メソッドに Edits.tracks リソースを渡す際に、"releaseNotes" フィールドを使用します。

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