Summary
Das neue Abonnement Modell und die Übersicht über die Google Play Billing Library 5.0
Kamo
May 25, 2022
Während der jährlichen I/O-Konferenz hat Google seine neue Hauptversion der Google Play Billing Library vorgestellt. Neben der Abschaffung der klassischen Methoden gab es auch umfangreiche Informationen über die neue Abonnement-Architektur, die die Erstellung, Verwaltung und den Verkauf von In-App-Käufen vereinfachen soll. In diesem Artikel gehe ich auf die Aktualisierungen von Google Play Billing Library 5.0 ein und erläutere die interessantesten davon.
Das neue Abonnement-Modell
Erwerb neuer Abonnements
Da wir gerade von Code sprechen: In Google Play Billing Library 5.0 ist die Klasse SkuDetails veraltet, ebenso wie jede andere Einheit oder Methode, die Sku in ihrem Namen enthält. Jetzt sollten Sie für diesen Zweck ProductDetails verwenden. ProductDetails enthalten Informationen über ein Abonnement, einschließlich der Basispläne und Angebote.
Davor haben Sie Abonnementdetails wie die folgenden angefordert:
val params = SkuDetailsParams.newBuilder() .setType(BillingClient.SkuType.SUBS) .setSkusList(listOf("premium")) .build() billingClient.querySkuDetailsAsync(params) { billingResult, skuDetailsList -> // Process the result }
Jetzt sollten Sie Folgendes tun:
val productList = listOf( QueryProductDetailsParams.Product.newBuilder() .setProductType(BillingClient.SkuType.SUBS) .setProductId("premium") .build() ) val params = QueryProductDetailsParams.newBuilder() .setProductList(productList) .build() billingClient.queryProductDetailsAsync(params) { billingResult, productDetailsList -> // Process the result }Copy
Und um den Erwerbsvorgang zu starten, haben Sie die folgenden Konstruktionen verwendet:
val billingFlowParams = BillingFlowParams.newBuilder() .setSkuDetails(skuDetails) .build() val billingResult = billingClient.launchBillingFlow(activity, billingFlowParams)Copy
Wohingegen sie jetzt so aussehen sollten wie die folgenden:
// Note that `subscriptionOfferDetails` can be null if it is an in-app product, not a subscription. val offerToken = productDetails.subscriptionOfferDetails?.get(selectedOfferIndex)?.offerToken ?: return val productDetailsParamsList = listOf( BillingFlowParams.ProductDetailsParams.newBuilder() .setProductDetails(productDetails) .setOfferToken(offerToken) .build() ) val billingFlowParams = BillingFlowParams.newBuilder() .setProductDetailsParamsList(productDetailsParamsList) val billingResult = billingClient.launchBillingFlow(activity, billingFlowParams) Copy
Sie können sich auch die Migrationsbeispiele in den offiziellen Migrationsschritten von Google ansehen. In den Beispielen sind ein paar Tippfehler enthalten, die hier korrigiert wurden.
Lassen Sie uns einen Überblick über die Änderungen geben.
Wie ich bereits erwähnt habe, sollten Sie jetzt ProductDetails verwenden, um Abonnementdetails und den Kaufprozess abzufragen. Sie sollten auch einen offerToken in die Parameter des Abrechnungsvorgangs einbeziehen, da jedes ProductDetails mehrere Angebote enthalten kann. Beachten Sie, dass das Array der Angebotsdetails (productDetails.subscriptionOfferDetails) immer die Details des Basisplans enthält (falls ein Basisplan existiert). Selbst wenn Ihr Abonnement also nur einen Basisplan ohne Angebote enthält, wird es dennoch offerTokens zum Kauf enthalten.
Sie werden feststellen, dass der neue Kaufprozess mehrere ProductDetails anstelle von nur einem SkuDetails wie in der vorherigen Version akzeptiert. Wenn Sie jedoch mehr als ein ProductDetails angeben, wird der Prozess mit einem Fehler beendet. Der offizielle Integrationsleitfaden gibt das falsche Beispiel, die Methoden setProductDetails und setOfferToken direkt in der Klasse BillingFlowParams.Builder zu verwenden, aber für diese Zwecke gibt es nur die Methode setProductDetailsParamsList. Es scheint, dass Google vor kurzem beschlossen hat, von einzelnen Produktdetails auf mehrere umzusteigen, mit einer Vision für die Zukunft, wenn Billing mehrere verschiedene Abonnementkäufe auf einmal unterstützt.
Der restliche Ablauf – nämlich die Bearbeitung des Kaufs – bleibt derselbe wie in der Google Play Billing Library 4.0.
Rückwärtskompatibilität von Abonnements
Bis jetzt hört sich alles gut an, aber was ist, wenn Sie nicht sofort migrieren möchten? Google hat sich darum gekümmert.
Obwohl die Google Play Console bereits nur mit dem neuen Abonnementmodell funktioniert, werden alle alten Abonnements automatisch in das neue Format gewandelt, wobei ihre Abwärtskompatibilität erhalten bleibt. Das bedeutet, dass Sie Ihre Abonnements im neuen Format in der Google Console sehen, aber weiterhin mit ihnen arbeiten können, wie Sie es bisher in Ihrer App getan haben.
Sie werden auch feststellen, dass alle alten Abonnements nach der Migration schreibgeschützt sind. Google warnt Sie, dass durch die Bearbeitung der Support der InAppProducts API für dieses Abonnement deaktiviert wird.
Möglicherweise verwenden Sie diese API in Ihrem Backend, um einige Produktdetails abzurufen. Vorsicht: Nachdem Sie das Abonnement editierbar gemacht haben, erhalten Sie von dieser API Fehlermeldungen (wie unten gezeigt), wenn Sie versuchen, umgewandelte Abonnementinformationen abzurufen. Das Gleiche gilt für alle neuen Abonnements, die nach dem 11. Mai erstellt werden.
HTTP code - 422 Non-existent in-app product: com.qonversion.sample\/ProductId{productId=article_test_trial}Copy
Wenn Sie also die InAppProducts API verwenden, sollten Sie ein Upgrade in Betracht ziehen, bevor Sie neue Abonnements erstellen oder alte bearbeiten.
Wenn Sie die neue Abonnement-Benutzeroberfläche in der Google Play Console durchsuchen, finden Sie die Markierung “Abwärtskompatibel” in der Nähe der Abonnement-Basispläne und -angebote. Das bedeutet, dass Sie, wenn Sie diese Abonnements mit den veralteten SkuDetails erwerben (wie in Google Play Billing Library 4.0), kaufen Sie genau dieselben kompatiblen Basispläne/Angebote. Wenn es nur einen kompatiblen Basisplan ohne ein kompatibles Angebot gibt, wird dieser Basisplan gekauft. Wenn sowohl ein kompatibler Basisplan als auch ein kompatibles Angebot verfügbar sind, wird das Angebot gekauft, wenn es für den aktuellen Nutzer in Frage kommt, andernfalls – der Basisplan. Wenn Sie möchten, können Sie einen anderen Basisplan/ein anderes Angebot als abwärtskompatibel auswählen.
Hinweis: Diese Rückwärtskompatibilität bezieht sich auf die Google Play Billing Library, nicht aber auf die InAppProducts API. Wenn Sie, wie bereits erwähnt, neue Funktionen verwenden, z. B. mehrere Basispläne oder Angebote für ein Abonnement oder es einfach von schreibgeschützt in bearbeitbar umwandeln, kann dieses Abonnement für eine App immer noch abwärtskompatibel sein, aber nicht für die API.
Die anderen Updates
Es gab mehrere kleinere Aktualisierungen in der Google Play Billing Library 5.0, die kurz erwähnt werden sollten.
Die Methode
queryPurchases, die in der Google Play Billing Library 4.0 veraltet war, wurde entferntKeine synchronisierten Anfragen mehr, nur noch
queryPurchasesAsync.launchPriceChangeFlowist veraltet – der neue empfohlene Preisänderungsprozess erfordert die Bestätigung der Kunden über die Google Play-Abonnementseite. Sie sollten daher Deep Links für die Navigation dort verwenden, anstatt die Methode BillingClient aufzurufen.Die Methode
setIsOfferPersonalizedwurde hinzugefügt, um einen personalisierten Preis für EU-Kunden gemäß der Richtlinie über Verbraucherrechte anzugeben. Diese Option fügt am Boden des Google Billing-Kaufbildschirms eine Zeile hinzu, die darauf hinweist, dass ein Preis personalisiert ist.
Das neue Abonnementmodell und die Qonversion
Während wir an der Unterstützung von Google Play Billing Library 5.0 arbeiten, können Sie Qonversion SDK weiterhin für Ihre In-App-Käufe verwenden. Wir verwenden jetzt Google Play Billing Library 4.0, was bedeutet, dass wir nur Abonnements mit rückwärtskompatiblen Basisplänen und Angeboten verwalten können. Sie können nach wie vor Eigenschaften bearbeiten, die im vorherigen Abonnementmodell verfügbar waren, wie z.B. Preis, Karenzzeit, Testdauer usw., und auch neue Abonnements erstellen. Stellen Sie nur sicher, dass Sie danach immer noch mindestens einen abwärtskompatiblen Basisplan und, falls erforderlich, ein abwärtskompatibles Angebot haben. Außerdem benötigen wir für die Konfiguration von Produkten in unserem Product Center nach wie vor eine vollständige Abonnementkennung, keine Basisplan- oder Angebotskennungen.
Wenn Sie Fragen haben, lassen Sie es uns bitte wissen. Wir helfen Ihnen gerne weiter.
Das neue Abonnement Modell und die Übersicht über die Google Play Billing Library 5.0
Kamo
May 25, 2022
Während der jährlichen I/O-Konferenz hat Google seine neue Hauptversion der Google Play Billing Library vorgestellt. Neben der Abschaffung der klassischen Methoden gab es auch umfangreiche Informationen über die neue Abonnement-Architektur, die die Erstellung, Verwaltung und den Verkauf von In-App-Käufen vereinfachen soll. In diesem Artikel gehe ich auf die Aktualisierungen von Google Play Billing Library 5.0 ein und erläutere die interessantesten davon.
Das neue Abonnement-Modell
Erwerb neuer Abonnements
Da wir gerade von Code sprechen: In Google Play Billing Library 5.0 ist die Klasse SkuDetails veraltet, ebenso wie jede andere Einheit oder Methode, die Sku in ihrem Namen enthält. Jetzt sollten Sie für diesen Zweck ProductDetails verwenden. ProductDetails enthalten Informationen über ein Abonnement, einschließlich der Basispläne und Angebote.
Davor haben Sie Abonnementdetails wie die folgenden angefordert:
val params = SkuDetailsParams.newBuilder() .setType(BillingClient.SkuType.SUBS) .setSkusList(listOf("premium")) .build() billingClient.querySkuDetailsAsync(params) { billingResult, skuDetailsList -> // Process the result }
Jetzt sollten Sie Folgendes tun:
val productList = listOf( QueryProductDetailsParams.Product.newBuilder() .setProductType(BillingClient.SkuType.SUBS) .setProductId("premium") .build() ) val params = QueryProductDetailsParams.newBuilder() .setProductList(productList) .build() billingClient.queryProductDetailsAsync(params) { billingResult, productDetailsList -> // Process the result }Copy
Und um den Erwerbsvorgang zu starten, haben Sie die folgenden Konstruktionen verwendet:
val billingFlowParams = BillingFlowParams.newBuilder() .setSkuDetails(skuDetails) .build() val billingResult = billingClient.launchBillingFlow(activity, billingFlowParams)Copy
Wohingegen sie jetzt so aussehen sollten wie die folgenden:
// Note that `subscriptionOfferDetails` can be null if it is an in-app product, not a subscription. val offerToken = productDetails.subscriptionOfferDetails?.get(selectedOfferIndex)?.offerToken ?: return val productDetailsParamsList = listOf( BillingFlowParams.ProductDetailsParams.newBuilder() .setProductDetails(productDetails) .setOfferToken(offerToken) .build() ) val billingFlowParams = BillingFlowParams.newBuilder() .setProductDetailsParamsList(productDetailsParamsList) val billingResult = billingClient.launchBillingFlow(activity, billingFlowParams) Copy
Sie können sich auch die Migrationsbeispiele in den offiziellen Migrationsschritten von Google ansehen. In den Beispielen sind ein paar Tippfehler enthalten, die hier korrigiert wurden.
Lassen Sie uns einen Überblick über die Änderungen geben.
Wie ich bereits erwähnt habe, sollten Sie jetzt ProductDetails verwenden, um Abonnementdetails und den Kaufprozess abzufragen. Sie sollten auch einen offerToken in die Parameter des Abrechnungsvorgangs einbeziehen, da jedes ProductDetails mehrere Angebote enthalten kann. Beachten Sie, dass das Array der Angebotsdetails (productDetails.subscriptionOfferDetails) immer die Details des Basisplans enthält (falls ein Basisplan existiert). Selbst wenn Ihr Abonnement also nur einen Basisplan ohne Angebote enthält, wird es dennoch offerTokens zum Kauf enthalten.
Sie werden feststellen, dass der neue Kaufprozess mehrere ProductDetails anstelle von nur einem SkuDetails wie in der vorherigen Version akzeptiert. Wenn Sie jedoch mehr als ein ProductDetails angeben, wird der Prozess mit einem Fehler beendet. Der offizielle Integrationsleitfaden gibt das falsche Beispiel, die Methoden setProductDetails und setOfferToken direkt in der Klasse BillingFlowParams.Builder zu verwenden, aber für diese Zwecke gibt es nur die Methode setProductDetailsParamsList. Es scheint, dass Google vor kurzem beschlossen hat, von einzelnen Produktdetails auf mehrere umzusteigen, mit einer Vision für die Zukunft, wenn Billing mehrere verschiedene Abonnementkäufe auf einmal unterstützt.
Der restliche Ablauf – nämlich die Bearbeitung des Kaufs – bleibt derselbe wie in der Google Play Billing Library 4.0.
Rückwärtskompatibilität von Abonnements
Bis jetzt hört sich alles gut an, aber was ist, wenn Sie nicht sofort migrieren möchten? Google hat sich darum gekümmert.
Obwohl die Google Play Console bereits nur mit dem neuen Abonnementmodell funktioniert, werden alle alten Abonnements automatisch in das neue Format gewandelt, wobei ihre Abwärtskompatibilität erhalten bleibt. Das bedeutet, dass Sie Ihre Abonnements im neuen Format in der Google Console sehen, aber weiterhin mit ihnen arbeiten können, wie Sie es bisher in Ihrer App getan haben.
Sie werden auch feststellen, dass alle alten Abonnements nach der Migration schreibgeschützt sind. Google warnt Sie, dass durch die Bearbeitung der Support der InAppProducts API für dieses Abonnement deaktiviert wird.
Möglicherweise verwenden Sie diese API in Ihrem Backend, um einige Produktdetails abzurufen. Vorsicht: Nachdem Sie das Abonnement editierbar gemacht haben, erhalten Sie von dieser API Fehlermeldungen (wie unten gezeigt), wenn Sie versuchen, umgewandelte Abonnementinformationen abzurufen. Das Gleiche gilt für alle neuen Abonnements, die nach dem 11. Mai erstellt werden.
HTTP code - 422 Non-existent in-app product: com.qonversion.sample\/ProductId{productId=article_test_trial}Copy
Wenn Sie also die InAppProducts API verwenden, sollten Sie ein Upgrade in Betracht ziehen, bevor Sie neue Abonnements erstellen oder alte bearbeiten.
Wenn Sie die neue Abonnement-Benutzeroberfläche in der Google Play Console durchsuchen, finden Sie die Markierung “Abwärtskompatibel” in der Nähe der Abonnement-Basispläne und -angebote. Das bedeutet, dass Sie, wenn Sie diese Abonnements mit den veralteten SkuDetails erwerben (wie in Google Play Billing Library 4.0), kaufen Sie genau dieselben kompatiblen Basispläne/Angebote. Wenn es nur einen kompatiblen Basisplan ohne ein kompatibles Angebot gibt, wird dieser Basisplan gekauft. Wenn sowohl ein kompatibler Basisplan als auch ein kompatibles Angebot verfügbar sind, wird das Angebot gekauft, wenn es für den aktuellen Nutzer in Frage kommt, andernfalls – der Basisplan. Wenn Sie möchten, können Sie einen anderen Basisplan/ein anderes Angebot als abwärtskompatibel auswählen.
Hinweis: Diese Rückwärtskompatibilität bezieht sich auf die Google Play Billing Library, nicht aber auf die InAppProducts API. Wenn Sie, wie bereits erwähnt, neue Funktionen verwenden, z. B. mehrere Basispläne oder Angebote für ein Abonnement oder es einfach von schreibgeschützt in bearbeitbar umwandeln, kann dieses Abonnement für eine App immer noch abwärtskompatibel sein, aber nicht für die API.
Die anderen Updates
Es gab mehrere kleinere Aktualisierungen in der Google Play Billing Library 5.0, die kurz erwähnt werden sollten.
Die Methode
queryPurchases, die in der Google Play Billing Library 4.0 veraltet war, wurde entferntKeine synchronisierten Anfragen mehr, nur noch
queryPurchasesAsync.launchPriceChangeFlowist veraltet – der neue empfohlene Preisänderungsprozess erfordert die Bestätigung der Kunden über die Google Play-Abonnementseite. Sie sollten daher Deep Links für die Navigation dort verwenden, anstatt die Methode BillingClient aufzurufen.Die Methode
setIsOfferPersonalizedwurde hinzugefügt, um einen personalisierten Preis für EU-Kunden gemäß der Richtlinie über Verbraucherrechte anzugeben. Diese Option fügt am Boden des Google Billing-Kaufbildschirms eine Zeile hinzu, die darauf hinweist, dass ein Preis personalisiert ist.
Das neue Abonnementmodell und die Qonversion
Während wir an der Unterstützung von Google Play Billing Library 5.0 arbeiten, können Sie Qonversion SDK weiterhin für Ihre In-App-Käufe verwenden. Wir verwenden jetzt Google Play Billing Library 4.0, was bedeutet, dass wir nur Abonnements mit rückwärtskompatiblen Basisplänen und Angeboten verwalten können. Sie können nach wie vor Eigenschaften bearbeiten, die im vorherigen Abonnementmodell verfügbar waren, wie z.B. Preis, Karenzzeit, Testdauer usw., und auch neue Abonnements erstellen. Stellen Sie nur sicher, dass Sie danach immer noch mindestens einen abwärtskompatiblen Basisplan und, falls erforderlich, ein abwärtskompatibles Angebot haben. Außerdem benötigen wir für die Konfiguration von Produkten in unserem Product Center nach wie vor eine vollständige Abonnementkennung, keine Basisplan- oder Angebotskennungen.
Wenn Sie Fragen haben, lassen Sie es uns bitte wissen. Wir helfen Ihnen gerne weiter.
Das neue Abonnement Modell und die Übersicht über die Google Play Billing Library 5.0
Kamo
May 25, 2022
Während der jährlichen I/O-Konferenz hat Google seine neue Hauptversion der Google Play Billing Library vorgestellt. Neben der Abschaffung der klassischen Methoden gab es auch umfangreiche Informationen über die neue Abonnement-Architektur, die die Erstellung, Verwaltung und den Verkauf von In-App-Käufen vereinfachen soll. In diesem Artikel gehe ich auf die Aktualisierungen von Google Play Billing Library 5.0 ein und erläutere die interessantesten davon.
Das neue Abonnement-Modell
Erwerb neuer Abonnements
Da wir gerade von Code sprechen: In Google Play Billing Library 5.0 ist die Klasse SkuDetails veraltet, ebenso wie jede andere Einheit oder Methode, die Sku in ihrem Namen enthält. Jetzt sollten Sie für diesen Zweck ProductDetails verwenden. ProductDetails enthalten Informationen über ein Abonnement, einschließlich der Basispläne und Angebote.
Davor haben Sie Abonnementdetails wie die folgenden angefordert:
val params = SkuDetailsParams.newBuilder() .setType(BillingClient.SkuType.SUBS) .setSkusList(listOf("premium")) .build() billingClient.querySkuDetailsAsync(params) { billingResult, skuDetailsList -> // Process the result }
Jetzt sollten Sie Folgendes tun:
val productList = listOf( QueryProductDetailsParams.Product.newBuilder() .setProductType(BillingClient.SkuType.SUBS) .setProductId("premium") .build() ) val params = QueryProductDetailsParams.newBuilder() .setProductList(productList) .build() billingClient.queryProductDetailsAsync(params) { billingResult, productDetailsList -> // Process the result }Copy
Und um den Erwerbsvorgang zu starten, haben Sie die folgenden Konstruktionen verwendet:
val billingFlowParams = BillingFlowParams.newBuilder() .setSkuDetails(skuDetails) .build() val billingResult = billingClient.launchBillingFlow(activity, billingFlowParams)Copy
Wohingegen sie jetzt so aussehen sollten wie die folgenden:
// Note that `subscriptionOfferDetails` can be null if it is an in-app product, not a subscription. val offerToken = productDetails.subscriptionOfferDetails?.get(selectedOfferIndex)?.offerToken ?: return val productDetailsParamsList = listOf( BillingFlowParams.ProductDetailsParams.newBuilder() .setProductDetails(productDetails) .setOfferToken(offerToken) .build() ) val billingFlowParams = BillingFlowParams.newBuilder() .setProductDetailsParamsList(productDetailsParamsList) val billingResult = billingClient.launchBillingFlow(activity, billingFlowParams) Copy
Sie können sich auch die Migrationsbeispiele in den offiziellen Migrationsschritten von Google ansehen. In den Beispielen sind ein paar Tippfehler enthalten, die hier korrigiert wurden.
Lassen Sie uns einen Überblick über die Änderungen geben.
Wie ich bereits erwähnt habe, sollten Sie jetzt ProductDetails verwenden, um Abonnementdetails und den Kaufprozess abzufragen. Sie sollten auch einen offerToken in die Parameter des Abrechnungsvorgangs einbeziehen, da jedes ProductDetails mehrere Angebote enthalten kann. Beachten Sie, dass das Array der Angebotsdetails (productDetails.subscriptionOfferDetails) immer die Details des Basisplans enthält (falls ein Basisplan existiert). Selbst wenn Ihr Abonnement also nur einen Basisplan ohne Angebote enthält, wird es dennoch offerTokens zum Kauf enthalten.
Sie werden feststellen, dass der neue Kaufprozess mehrere ProductDetails anstelle von nur einem SkuDetails wie in der vorherigen Version akzeptiert. Wenn Sie jedoch mehr als ein ProductDetails angeben, wird der Prozess mit einem Fehler beendet. Der offizielle Integrationsleitfaden gibt das falsche Beispiel, die Methoden setProductDetails und setOfferToken direkt in der Klasse BillingFlowParams.Builder zu verwenden, aber für diese Zwecke gibt es nur die Methode setProductDetailsParamsList. Es scheint, dass Google vor kurzem beschlossen hat, von einzelnen Produktdetails auf mehrere umzusteigen, mit einer Vision für die Zukunft, wenn Billing mehrere verschiedene Abonnementkäufe auf einmal unterstützt.
Der restliche Ablauf – nämlich die Bearbeitung des Kaufs – bleibt derselbe wie in der Google Play Billing Library 4.0.
Rückwärtskompatibilität von Abonnements
Bis jetzt hört sich alles gut an, aber was ist, wenn Sie nicht sofort migrieren möchten? Google hat sich darum gekümmert.
Obwohl die Google Play Console bereits nur mit dem neuen Abonnementmodell funktioniert, werden alle alten Abonnements automatisch in das neue Format gewandelt, wobei ihre Abwärtskompatibilität erhalten bleibt. Das bedeutet, dass Sie Ihre Abonnements im neuen Format in der Google Console sehen, aber weiterhin mit ihnen arbeiten können, wie Sie es bisher in Ihrer App getan haben.
Sie werden auch feststellen, dass alle alten Abonnements nach der Migration schreibgeschützt sind. Google warnt Sie, dass durch die Bearbeitung der Support der InAppProducts API für dieses Abonnement deaktiviert wird.
Möglicherweise verwenden Sie diese API in Ihrem Backend, um einige Produktdetails abzurufen. Vorsicht: Nachdem Sie das Abonnement editierbar gemacht haben, erhalten Sie von dieser API Fehlermeldungen (wie unten gezeigt), wenn Sie versuchen, umgewandelte Abonnementinformationen abzurufen. Das Gleiche gilt für alle neuen Abonnements, die nach dem 11. Mai erstellt werden.
HTTP code - 422 Non-existent in-app product: com.qonversion.sample\/ProductId{productId=article_test_trial}Copy
Wenn Sie also die InAppProducts API verwenden, sollten Sie ein Upgrade in Betracht ziehen, bevor Sie neue Abonnements erstellen oder alte bearbeiten.
Wenn Sie die neue Abonnement-Benutzeroberfläche in der Google Play Console durchsuchen, finden Sie die Markierung “Abwärtskompatibel” in der Nähe der Abonnement-Basispläne und -angebote. Das bedeutet, dass Sie, wenn Sie diese Abonnements mit den veralteten SkuDetails erwerben (wie in Google Play Billing Library 4.0), kaufen Sie genau dieselben kompatiblen Basispläne/Angebote. Wenn es nur einen kompatiblen Basisplan ohne ein kompatibles Angebot gibt, wird dieser Basisplan gekauft. Wenn sowohl ein kompatibler Basisplan als auch ein kompatibles Angebot verfügbar sind, wird das Angebot gekauft, wenn es für den aktuellen Nutzer in Frage kommt, andernfalls – der Basisplan. Wenn Sie möchten, können Sie einen anderen Basisplan/ein anderes Angebot als abwärtskompatibel auswählen.
Hinweis: Diese Rückwärtskompatibilität bezieht sich auf die Google Play Billing Library, nicht aber auf die InAppProducts API. Wenn Sie, wie bereits erwähnt, neue Funktionen verwenden, z. B. mehrere Basispläne oder Angebote für ein Abonnement oder es einfach von schreibgeschützt in bearbeitbar umwandeln, kann dieses Abonnement für eine App immer noch abwärtskompatibel sein, aber nicht für die API.
Die anderen Updates
Es gab mehrere kleinere Aktualisierungen in der Google Play Billing Library 5.0, die kurz erwähnt werden sollten.
Die Methode
queryPurchases, die in der Google Play Billing Library 4.0 veraltet war, wurde entferntKeine synchronisierten Anfragen mehr, nur noch
queryPurchasesAsync.launchPriceChangeFlowist veraltet – der neue empfohlene Preisänderungsprozess erfordert die Bestätigung der Kunden über die Google Play-Abonnementseite. Sie sollten daher Deep Links für die Navigation dort verwenden, anstatt die Methode BillingClient aufzurufen.Die Methode
setIsOfferPersonalizedwurde hinzugefügt, um einen personalisierten Preis für EU-Kunden gemäß der Richtlinie über Verbraucherrechte anzugeben. Diese Option fügt am Boden des Google Billing-Kaufbildschirms eine Zeile hinzu, die darauf hinweist, dass ein Preis personalisiert ist.
Das neue Abonnementmodell und die Qonversion
Während wir an der Unterstützung von Google Play Billing Library 5.0 arbeiten, können Sie Qonversion SDK weiterhin für Ihre In-App-Käufe verwenden. Wir verwenden jetzt Google Play Billing Library 4.0, was bedeutet, dass wir nur Abonnements mit rückwärtskompatiblen Basisplänen und Angeboten verwalten können. Sie können nach wie vor Eigenschaften bearbeiten, die im vorherigen Abonnementmodell verfügbar waren, wie z.B. Preis, Karenzzeit, Testdauer usw., und auch neue Abonnements erstellen. Stellen Sie nur sicher, dass Sie danach immer noch mindestens einen abwärtskompatiblen Basisplan und, falls erforderlich, ein abwärtskompatibles Angebot haben. Außerdem benötigen wir für die Konfiguration von Produkten in unserem Product Center nach wie vor eine vollständige Abonnementkennung, keine Basisplan- oder Angebotskennungen.
Wenn Sie Fragen haben, lassen Sie es uns bitte wissen. Wir helfen Ihnen gerne weiter.
Das neue Abonnement Modell und die Übersicht über die Google Play Billing Library 5.0
Kamo
May 25, 2022
Während der jährlichen I/O-Konferenz hat Google seine neue Hauptversion der Google Play Billing Library vorgestellt. Neben der Abschaffung der klassischen Methoden gab es auch umfangreiche Informationen über die neue Abonnement-Architektur, die die Erstellung, Verwaltung und den Verkauf von In-App-Käufen vereinfachen soll. In diesem Artikel gehe ich auf die Aktualisierungen von Google Play Billing Library 5.0 ein und erläutere die interessantesten davon.
Das neue Abonnement-Modell
Erwerb neuer Abonnements
Da wir gerade von Code sprechen: In Google Play Billing Library 5.0 ist die Klasse SkuDetails veraltet, ebenso wie jede andere Einheit oder Methode, die Sku in ihrem Namen enthält. Jetzt sollten Sie für diesen Zweck ProductDetails verwenden. ProductDetails enthalten Informationen über ein Abonnement, einschließlich der Basispläne und Angebote.
Davor haben Sie Abonnementdetails wie die folgenden angefordert:
val params = SkuDetailsParams.newBuilder() .setType(BillingClient.SkuType.SUBS) .setSkusList(listOf("premium")) .build() billingClient.querySkuDetailsAsync(params) { billingResult, skuDetailsList -> // Process the result }
Jetzt sollten Sie Folgendes tun:
val productList = listOf( QueryProductDetailsParams.Product.newBuilder() .setProductType(BillingClient.SkuType.SUBS) .setProductId("premium") .build() ) val params = QueryProductDetailsParams.newBuilder() .setProductList(productList) .build() billingClient.queryProductDetailsAsync(params) { billingResult, productDetailsList -> // Process the result }Copy
Und um den Erwerbsvorgang zu starten, haben Sie die folgenden Konstruktionen verwendet:
val billingFlowParams = BillingFlowParams.newBuilder() .setSkuDetails(skuDetails) .build() val billingResult = billingClient.launchBillingFlow(activity, billingFlowParams)Copy
Wohingegen sie jetzt so aussehen sollten wie die folgenden:
// Note that `subscriptionOfferDetails` can be null if it is an in-app product, not a subscription. val offerToken = productDetails.subscriptionOfferDetails?.get(selectedOfferIndex)?.offerToken ?: return val productDetailsParamsList = listOf( BillingFlowParams.ProductDetailsParams.newBuilder() .setProductDetails(productDetails) .setOfferToken(offerToken) .build() ) val billingFlowParams = BillingFlowParams.newBuilder() .setProductDetailsParamsList(productDetailsParamsList) val billingResult = billingClient.launchBillingFlow(activity, billingFlowParams) Copy
Sie können sich auch die Migrationsbeispiele in den offiziellen Migrationsschritten von Google ansehen. In den Beispielen sind ein paar Tippfehler enthalten, die hier korrigiert wurden.
Lassen Sie uns einen Überblick über die Änderungen geben.
Wie ich bereits erwähnt habe, sollten Sie jetzt ProductDetails verwenden, um Abonnementdetails und den Kaufprozess abzufragen. Sie sollten auch einen offerToken in die Parameter des Abrechnungsvorgangs einbeziehen, da jedes ProductDetails mehrere Angebote enthalten kann. Beachten Sie, dass das Array der Angebotsdetails (productDetails.subscriptionOfferDetails) immer die Details des Basisplans enthält (falls ein Basisplan existiert). Selbst wenn Ihr Abonnement also nur einen Basisplan ohne Angebote enthält, wird es dennoch offerTokens zum Kauf enthalten.
Sie werden feststellen, dass der neue Kaufprozess mehrere ProductDetails anstelle von nur einem SkuDetails wie in der vorherigen Version akzeptiert. Wenn Sie jedoch mehr als ein ProductDetails angeben, wird der Prozess mit einem Fehler beendet. Der offizielle Integrationsleitfaden gibt das falsche Beispiel, die Methoden setProductDetails und setOfferToken direkt in der Klasse BillingFlowParams.Builder zu verwenden, aber für diese Zwecke gibt es nur die Methode setProductDetailsParamsList. Es scheint, dass Google vor kurzem beschlossen hat, von einzelnen Produktdetails auf mehrere umzusteigen, mit einer Vision für die Zukunft, wenn Billing mehrere verschiedene Abonnementkäufe auf einmal unterstützt.
Der restliche Ablauf – nämlich die Bearbeitung des Kaufs – bleibt derselbe wie in der Google Play Billing Library 4.0.
Rückwärtskompatibilität von Abonnements
Bis jetzt hört sich alles gut an, aber was ist, wenn Sie nicht sofort migrieren möchten? Google hat sich darum gekümmert.
Obwohl die Google Play Console bereits nur mit dem neuen Abonnementmodell funktioniert, werden alle alten Abonnements automatisch in das neue Format gewandelt, wobei ihre Abwärtskompatibilität erhalten bleibt. Das bedeutet, dass Sie Ihre Abonnements im neuen Format in der Google Console sehen, aber weiterhin mit ihnen arbeiten können, wie Sie es bisher in Ihrer App getan haben.
Sie werden auch feststellen, dass alle alten Abonnements nach der Migration schreibgeschützt sind. Google warnt Sie, dass durch die Bearbeitung der Support der InAppProducts API für dieses Abonnement deaktiviert wird.
Möglicherweise verwenden Sie diese API in Ihrem Backend, um einige Produktdetails abzurufen. Vorsicht: Nachdem Sie das Abonnement editierbar gemacht haben, erhalten Sie von dieser API Fehlermeldungen (wie unten gezeigt), wenn Sie versuchen, umgewandelte Abonnementinformationen abzurufen. Das Gleiche gilt für alle neuen Abonnements, die nach dem 11. Mai erstellt werden.
HTTP code - 422 Non-existent in-app product: com.qonversion.sample\/ProductId{productId=article_test_trial}Copy
Wenn Sie also die InAppProducts API verwenden, sollten Sie ein Upgrade in Betracht ziehen, bevor Sie neue Abonnements erstellen oder alte bearbeiten.
Wenn Sie die neue Abonnement-Benutzeroberfläche in der Google Play Console durchsuchen, finden Sie die Markierung “Abwärtskompatibel” in der Nähe der Abonnement-Basispläne und -angebote. Das bedeutet, dass Sie, wenn Sie diese Abonnements mit den veralteten SkuDetails erwerben (wie in Google Play Billing Library 4.0), kaufen Sie genau dieselben kompatiblen Basispläne/Angebote. Wenn es nur einen kompatiblen Basisplan ohne ein kompatibles Angebot gibt, wird dieser Basisplan gekauft. Wenn sowohl ein kompatibler Basisplan als auch ein kompatibles Angebot verfügbar sind, wird das Angebot gekauft, wenn es für den aktuellen Nutzer in Frage kommt, andernfalls – der Basisplan. Wenn Sie möchten, können Sie einen anderen Basisplan/ein anderes Angebot als abwärtskompatibel auswählen.
Hinweis: Diese Rückwärtskompatibilität bezieht sich auf die Google Play Billing Library, nicht aber auf die InAppProducts API. Wenn Sie, wie bereits erwähnt, neue Funktionen verwenden, z. B. mehrere Basispläne oder Angebote für ein Abonnement oder es einfach von schreibgeschützt in bearbeitbar umwandeln, kann dieses Abonnement für eine App immer noch abwärtskompatibel sein, aber nicht für die API.
Die anderen Updates
Es gab mehrere kleinere Aktualisierungen in der Google Play Billing Library 5.0, die kurz erwähnt werden sollten.
Die Methode
queryPurchases, die in der Google Play Billing Library 4.0 veraltet war, wurde entferntKeine synchronisierten Anfragen mehr, nur noch
queryPurchasesAsync.launchPriceChangeFlowist veraltet – der neue empfohlene Preisänderungsprozess erfordert die Bestätigung der Kunden über die Google Play-Abonnementseite. Sie sollten daher Deep Links für die Navigation dort verwenden, anstatt die Methode BillingClient aufzurufen.Die Methode
setIsOfferPersonalizedwurde hinzugefügt, um einen personalisierten Preis für EU-Kunden gemäß der Richtlinie über Verbraucherrechte anzugeben. Diese Option fügt am Boden des Google Billing-Kaufbildschirms eine Zeile hinzu, die darauf hinweist, dass ein Preis personalisiert ist.
Das neue Abonnementmodell und die Qonversion
Während wir an der Unterstützung von Google Play Billing Library 5.0 arbeiten, können Sie Qonversion SDK weiterhin für Ihre In-App-Käufe verwenden. Wir verwenden jetzt Google Play Billing Library 4.0, was bedeutet, dass wir nur Abonnements mit rückwärtskompatiblen Basisplänen und Angeboten verwalten können. Sie können nach wie vor Eigenschaften bearbeiten, die im vorherigen Abonnementmodell verfügbar waren, wie z.B. Preis, Karenzzeit, Testdauer usw., und auch neue Abonnements erstellen. Stellen Sie nur sicher, dass Sie danach immer noch mindestens einen abwärtskompatiblen Basisplan und, falls erforderlich, ein abwärtskompatibles Angebot haben. Außerdem benötigen wir für die Konfiguration von Produkten in unserem Product Center nach wie vor eine vollständige Abonnementkennung, keine Basisplan- oder Angebotskennungen.
Wenn Sie Fragen haben, lassen Sie es uns bitte wissen. Wir helfen Ihnen gerne weiter.
Start Now for Free
Or book a demo with our team to learn more about Qonversion
Start Now for Free
Or book a demo with our team to learn more about Qonversion
Start Now for Free
Or book a demo with our team to learn more about Qonversion
Read more
Read more
Trash Panda Maximizes App Revenue after Setting the Best Subscription Price with A/B Tests
Jul 8, 2024
Jul 8, 2024
How StyleDNA Saved 20% Development Time and Unlocked New Features
Jun 19, 2024
Jun 19, 2024
WWDC24 Updates for App Developers | What's new in Storekit 2 and App Store Server API?
Jun 17, 2024
Jun 17, 2024
How A/B Testing with Qonversion Helped Iben Sandahl’s Parenting App Double Their Sales
Jun 13, 2024
Jun 13, 2024
Trash Panda Maximizes App Revenue after Setting the Best Subscription Price with A/B Tests
Jul 8, 2024
Jul 8, 2024
How StyleDNA Saved 20% Development Time and Unlocked New Features
Jun 19, 2024
Jun 19, 2024
WWDC24 Updates for App Developers | What's new in Storekit 2 and App Store Server API?
Jun 17, 2024
Jun 17, 2024
