Mit der Google Play Developer API können Sie neue APKs für Ihre Apps hochladen und sie für verschiedene Release-Tracks freigeben. So können Sie Alpha- und Betaversionen Ihrer App bereitstellen, die genehmigten Nutzern zur Verfügung gestellt werden. Sie haben dann auch die Möglichkeit, eine Version mit gestaffeltem Rollout bereitzustellen, die automatisch einer kleinen Anzahl von App-Nutzern zur Verfügung gestellt wird. Nachdem Sie die Version für den gestaffelten Roll-out veröffentlicht haben, können Sie die Anzahl der Nutzer, die diese Version der App erhalten, nach und nach erhöhen, bis Sie sie schließlich als Produktionsversion bereitstellen.
APKs hinzufügen und ändern
Laden Sie ein oder mehrere APKs hoch, indem Sie die Methode Edits.apks: upload aufrufen.
Bei dieser Methode wird das APK in einen Speicher-Bucket hochgeladen, wo es einem Track zugewiesen werden kann, um es für Nutzer bereitzustellen. Wenn die Änderung gelöscht oder verworfen wird, gehen auch alle APKs verloren, die für diese Änderung hochgeladen wurden.
Veröffentlichen Sie APKs in „Tracks“, indem Sie Edits.tracks: update aufrufen. Sie können APKs auf den folgenden Tracks veröffentlichen:
Test-Tracks wie
"alpha"und"beta"Alpha- und Betaversionen der App werden für die Nutzer bereitgestellt, die Sie den Alpha- und Betatestgruppen zuweisen. Sie weisen Nutzer über die Google Play Console diesen Gruppen zu.
Der interne Test-Track:
"qa"Interne Versionen Ihrer App werden auf dem internen Test-Track bereitgestellt, der in der Google Play Console konfiguriert ist.
Der Produktions-Track:
"production"Releases im Produktions-Track werden für alle Nutzer bereitgestellt. Sie können gestaffelte Releases im Produktions-Track verwenden, um Ihren Release zuerst für einen kleinen Prozentsatz der Produktionsnutzer bereitzustellen und diesen Prozentsatz dann schrittweise zu erhöhen, wenn Sie sich sicher sind, dass der Release funktioniert.
Nutzer im einfachen Modus sollten nicht mehr als ein APK in einen Track einfügen. Nutzer im erweiterten Modus, die Unterstützung für mehrere APKs verwenden, können für jeden Track null, ein oder mehrere APKs hochladen.
Track-Name für Formfaktor-Tracks
Der Trackname für einen Formfaktor-Track hat ein bestimmtes Präfix.
| Formfaktor | Präfix |
|---|---|
| Android Automotive OS | Automobil |
| Wear OS | Wear |
| Android TV | Fernseher |
| Android XR | android_xr |
| Google Play Spiele auf dem PC | google_play_games_pc |
Wie wird der Name eines Tracks für einen bestimmten Formfaktor berechnet?
Gängige Tracktypen wie Produktions-, offener Test- und interner Test-Track haben einen bekannten Tracknamen.
| Tracking-Typ | Standard-Trackname |
|---|---|
| Produktion | Produktion |
| Offene Tests | Beta |
| Interner Test | qa |
Der Track-Name für einen bestimmten Formfaktor-Track kann so berechnet werden:
"[prefix]:defaultTrackName".
Bei Wear OS-Geräten sind das beispielsweise die Tracks mit den Namen "wear:production", "wear:beta" und "wear:qa".
Geschlossene Test-Tracks werden manuell erstellt und haben benutzerdefinierte Namen. Ein geschlossener Testlauf für einen Formfaktor mit dem Namen $name hat also den Namen "[prefix]:$name".
Beispiel für APK-Workflow
In diesem Abschnitt wird beschrieben, wie die Tracks API in der Regel verwendet wird. In diesem Fall gehen wir davon aus, dass Sie für jeden Track neue Versionen des APK hochladen und eine bestimmte Anzahl von Nutzern zuweisen möchten, die eine Version für die gestaffelte Einführung erhalten sollen. In der Praxis ist es unwahrscheinlich, dass ein Entwickler alle diese Aktionen im selben Vorgang ausführt. Stattdessen wird er vielleicht an einem Tag die Betaversion aktualisieren, an einem anderen Tag eine stufenweise Einführung in der Produktionsversion erstellen usw.
- Öffnen Sie eine neue Bearbeitung, wie unter Bearbeitungs-Workflow beschrieben.
- Rufen Sie die Methode Edits.apks: upload für jedes APK auf, das Sie hochladen möchten. Übergeben Sie das APK im Anfragetext der Methode. Dadurch wird das APK in einem Speicherbereich abgelegt, aber nicht in einem Track veröffentlicht oder bereitgestellt. Die Methode gibt einen Versionscode für jedes hochgeladene APK zurück. Sie verwenden diesen Versionscode, um auf das APK zu verweisen, wenn Sie es in einem Track veröffentlichen.
Rufen Sie die Methode Edits.tracks: update für jeden Track auf, für den Sie APKs veröffentlichen möchten. Übergeben Sie im Anfragetext eine Edits.tracks-Ressource mit dem Release, das Sie einführen möchten. Wenn Sie beispielsweise ein APK mit dem Versionscode 88 veröffentlichen möchten, gehen Sie so vor:
{ "releases": [{ "versionCodes": ["88"], "status": "completed" }] }Zu diesem Zeitpunkt sind die APKs für Nutzer noch nicht verfügbar. Wie bei anderen Änderungen werden die Änderungen erst übernommen, wenn Sie sie bestätigen.
Rufen Sie die Methode Edits: commit auf, um die Änderungen zu übernehmen. Danach erhalten Nutzer in den einzelnen Tracks die aktualisierte Version des APKs. Wie bei allen Änderungen kann es einige Stunden dauern, bis die Änderungen wirksam werden.
Gestaffelte Roll-outs
Wenn Sie eine neue Version Ihres APK haben, die Sie nach und nach bereitstellen möchten, können Sie sie als Version mit gestaffelter Einführung veröffentlichen. Wenn Sie das tun, wird die App automatisch für den von Ihnen angegebenen Prozentsatz der App-Nutzer bereitgestellt. Wenn das Rollout-APK keine Probleme (z. B. Abstürze) aufweist, können Sie den Anteil der Nutzer erhöhen, die diese Version erhalten. Wenn Sie bereit sind, können Sie dieses APK als neue Produktionsversion bereitstellen.
In diesem Abschnitt wird beschrieben, wie Sie einen stufenweisen Roll-out einer APK-Datei durchführen und sie dann in die Produktion übertragen:
Erstellen Sie eine Änderung, wie unter Workflow für Änderungen beschrieben.
Laden Sie ein neues APK für die Bearbeitung mit der Methode Edits.apks: upload hoch.
Starten Sie einen gestaffelten Release von
"inProgress"im Produktions-Track mit der Methode Edits.tracks: update. Wählen Sie den Prozentsatz der Nutzer aus, die das neue APK erhalten sollen. Zu diesem Zeitpunkt ist das APK noch nicht für Endnutzer verfügbar.{ "releases": [{ "versionCodes": ["99"], "userFraction": 0.05, "status": "inProgress" }] }Übernehmen Sie die Änderungen im aktiven Bearbeitungsvorgang mit dem Aufruf von Edits: commit. In den nächsten Stunden wird das neue APK für Nutzer eingeführt. Der von Ihnen ausgewählte Bruchteil der Nutzer erhält das neue APK.
Je nachdem, wie erfolgreich der gestaffelte Rollout ist, können Sie den Prozentsatz der Nutzer, die für diesen Release infrage kommen, erhöhen oder den Release anhalten.
Erhöhen des Nutzeranteils für einen gestaffelten Roll-out
Angenommen, Sie haben einen laufenden stufenweisen Roll-out mit 5%, wie im vorherigen Abschnitt beschrieben. In diesem Abschnitt wird beschrieben, wie Sie den Prozentsatz erhöhen, wenn die Veröffentlichung gut läuft:
Erstellen Sie eine Änderung, wie unter Workflow für Änderungen beschrieben.
Ändern Sie den gestaffelten Release von
"inProgress"im Produktions-Track mit der Methode Edits.tracks: update. Anteil der Nutzer erhöhen, die das neue APK erhalten sollen:{ "releases": [{ "versionCodes": ["99"], "userFraction": 0.1, "status": "inProgress" }] }Übernehmen Sie die Änderungen im aktiven Bearbeitungsvorgang mit dem Aufruf von Edits: commit. In den nächsten Stunden wird das neue APK für Nutzer eingeführt. Der von Ihnen ausgewählte Bruchteil der Nutzer erhält das neue APK.
Gestaffelten Roll-out anhalten
Angenommen, Sie haben einen laufenden stufenweisen Roll-out mit 5%, wie im vorherigen Abschnitt beschrieben. In diesem Abschnitt wird beschrieben, wie Sie den stufenweisen Roll-out anhalten, wenn Sie ein Problem feststellen:
Erstellen Sie eine Änderung, wie unter Workflow für Änderungen beschrieben.
Ändern Sie den gestaffelten Release von
"inProgress"im Produktions-Track mit der Methode Edits.tracks: update. Legen Sie den Status auf"halted"fest.{ "releases": [{ "versionCodes": ["99"], "status": "halted" }] }Übernehmen Sie die Änderungen im aktiven Bearbeitungsvorgang mit dem Aufruf von Edits: commit. Ihr Release ist dann nicht mehr für neue Nutzer verfügbar.
Wenn Sie die Veröffentlichung eines angehaltenen Release später fortsetzen möchten, können Sie den Status auf "inProgress" zurücksetzen.
Gestaffelten Roll-out abschließen
Wenn Sie mit dem gestaffelten Rollout zufrieden sind und den Release für 100% der Nutzer einführen möchten, können Sie den Release-Status auf "completed" festlegen:
Erstellen Sie eine Bearbeitung, wie im Workflow für Bearbeitungen beschrieben.
Ändern Sie den gestaffelten Release von
"inProgress"im Produktions-Track mit der Methode Edits.tracks: update. Legen Sie den Status auf"completed"fest.{ "releases": [{ "versionCodes": ["99"], "status": "completed" }] }Übernehmen Sie die Änderungen im aktiven Bearbeitungsvorgang mit dem Aufruf von Edits: commit. In den nächsten Stunden wird das neue APK für Nutzer eingeführt. Der von Ihnen ausgewählte Bruchteil der Nutzer erhält das neue APK.
Abgeschlossenen Roll-out anhalten
In diesem Abschnitt wird davon ausgegangen, dass Sie einen Roll-out auf einem Track abgeschlossen haben, wie im vorherigen Abschnitt beschrieben. Hier erfahren Sie, wie Sie den abgeschlossenen Roll-out anhalten, wenn Sie ein Problem feststellen:
Erstellen Sie eine Änderung, wie im Workflow für Änderungen beschrieben.
Ändern Sie den
"completed"-Release im Produktions-Track mit der Methode Edits.tracks: update. Setzen Sie den Status auf"halted".{ "releases": [{ "versionCodes": ["99"], "status": "halted" }] }Übernehmen Sie die Änderungen im aktiven Bearbeitungsvorgang mit dem Aufruf von Edits: commit. Ihr Release ist dann nicht mehr für neue Nutzer verfügbar und bestehende Nutzer können kein Upgrade mehr darauf durchführen.
Die Version, die anstelle der "completed"-Version ausgeliefert wird, ist die vorherige "completed"-Version im Track, die veröffentlicht wurde und nicht angehalten wird. Das bedeutet, dass du einen "completed"-Release auf einem Track nur anhalten kannst, wenn bereits mindestens ein "completed"-Release auf dem Track veröffentlicht wurde.
Wenn Sie GetTrack oder ListTracks aufrufen, während ein "completed"-Release angehalten wird, wird das „Fallback-Release für die Auslieferung“ als abgeschlossenes Release auf dem Track angezeigt, auf dem das vorherige "completed"-Release angehalten wurde.
Wenn Sie beispielsweise ursprünglich einen alpha-Track hatten, der so aussah:
{
"track": "alpha",
"releases": [
{
"name": "2 (2.0)",
"versionCodes": [
"2"
],
"status": "completed"
}
]
}
und Sie die Veröffentlichung von "completed" gemäß den Schritten in diesem Abschnitt angehalten haben, würde der Aufruf von GetTrack für den alpha-Track etwa Folgendes zurückgeben:
{
"track": "alpha",
"releases": [
{
"name": "2 (2.0)",
"versionCodes": [
"2"
],
"status": "halted"
},
{
"name": "1 (1.0)",
"versionCodes": [
"1"
],
"status": "completed"
}
]
}
Wenn Sie die Veröffentlichung von "completed" später fortsetzen möchten, können Sie den Status wieder auf "inProgress" oder "completed" festlegen. Sie können einen neuen Release mit dem Status "inProgress" zusätzlich zum Release mit dem Status "completed" erstellen. Sie können den Release mit dem Status "completed" dann aber nur auf 100% (d. h. auf den Status "completed") zurücksetzen.
Versionsentwürfe
Mit Release-Entwürfen können Sie APKs automatisch über die API hochladen und einen Release erstellen, der später über die Google Play Console bereitgestellt werden kann. So erstellen Sie einen Versionsentwurf für einen Track:
- Öffnen Sie eine neue Bearbeitung, wie unter Bearbeitungs-Workflow beschrieben.
- Rufen Sie die Methode Edits.apks: upload für jedes APK auf, das Sie hochladen möchten. Übergeben Sie das APK im Anfragetext der Methode. Die Methode gibt einen Versionscode für jedes hochgeladene APK zurück. Sie verwenden diesen Versionscode, um auf das APK zu verweisen, wenn Sie es einem Release zuweisen.
Rufen Sie die Methode Edits.tracks: update für jeden Track auf, den Sie veröffentlichen möchten. Übergeben Sie im Anfragetext eine Edits.tracks-Ressource mit der zu erstellenden Release-Version. Beispiel:
{ "releases": [{ "name": "My draft release", "versionCodes": ["88"], "status": "draft" }] }Rufen Sie die Methode Edits: commit auf, um die Änderungen zu übernehmen. Ihr Releaseentwurf kann jetzt über die Google Play Console oder die API geprüft und eingeführt werden.
Versionshinweise angeben
Wenn Sie eine neue Version Ihrer Anwendung veröffentlichen, können Sie Nutzern die Neuerungen mitteilen, indem Sie Versionshinweise für das Release angeben.
Verwenden Sie dazu das Feld "releaseNotes", wenn Sie der Methode Edits.tracks: update eine Edits.tracks-Ressource bereitstellen.
{
"releases": [{
"name": "Release with notes",
"versionCodes": ["88"],
"status": "completed",
"releaseNotes": [
{"language": "en-US", "text": "Describe what's new in this release."}
]
}]
}