Migration zur Google Play Billing Library 9 von Version 7 oder 8

In diesem Dokument wird beschrieben, wie Sie von der Google Play Billing Library (PBL) 7 oder 8 zur PBL 9 migrieren und die neuen Funktionen einbinden.

Eine vollständige Liste der Änderungen in Version 9.0.0 finden Sie in den Versionshinweisen.

Übersicht

PBL 9 enthält Verbesserungen an vorhandenen APIs sowie die Entfernung von zuvor verworfenen APIs. In dieser Version der Bibliothek wird auch ein umfassenderer Fehlerkontext durch neue Unterantwortcodes eingeführt.

Abwärtskompatibilität für PBL-Upgrade

Für die Migration zu PBL 9 müssen Sie einige Ihrer vorhandenen API-Referenzen aus Ihrer App aktualisieren oder entfernen, wie in den Versionshinweisen und später in dieser Migrationsanleitung beschrieben.

Upgrade von PBL 7 oder 8 auf PBL 9

So führen Sie ein Upgrade von PBL 7 oder PBL 8 auf PBL 9 durch:

  1. Aktualisieren Sie die Version der Play Billing Library-Abhängigkeit in der Datei build.gradle Ihrer App.

    dependencies {
  def billing_version = "9.0.0"
  implementation "com.android.billingclient:billing:$billing_version"
}

    Wenn Sie Kotlin verwenden, enthält das KTX-Modul der Google Play Billing Library Kotlin-Erweiterungen und Coroutine-Unterstützung, mit denen Sie idiomatischen Kotlin-Code schreiben können, wenn Sie die Google Play Billing Library verwenden. Wenn Sie diese Erweiterungen in Ihr Projekt einbinden möchten, fügen Sie der Datei build.gradle Ihrer App die folgende Abhängigkeit hinzu:

    dependencies {
  val billing_version = "9.0.0"
  implementation("com.android.billingclient:billing-ktx:$billing_version")
}

  2. (Gilt nur für das Upgrade von PBL 7 auf PBL 9.) Aktualisieren Sie die Implementierung der Methode queryProductDetailsAsync.

    Die Signatur der Methode ProductDetailsResponseListener.onProductDetailsResponse hat sich geändert. Daher sind Änderungen in Ihrer App für die queryProductDetailsAsync-Implementierung erforderlich. Weitere Informationen finden Sie unter Zum Kauf verfügbare Produkte anzeigen.

  3. Umgang mit den entfernten APIs

    In der folgenden Tabelle sind die APIs aufgeführt, die entfernt werden, sowie die entsprechenden alternativen APIs, die Sie in Ihrer App verwenden müssen.

    Upgrade von

    PBL 9 unterstützt die in der folgenden Tabelle aufgeführten APIs nicht mehr. Wenn in Ihrer Implementierung eine dieser entfernten APIs verwendet wird, finden Sie in der Tabelle die entsprechenden alternativen APIs.

    Zuvor verworfene API entfernt Alternative API
    queryPurchaseHistoryAsync-APIs Weitere Informationen finden Sie unter Kaufverlauf abfragen. Wenn Sie queryPurchaseHistoryAsync verwendet haben, um die Berechtigung für kostenlose Testzeiträume zu ermitteln, sollten Sie jetzt ProductDetails.getSubscriptionOfferDetails() verwenden, um zu ermitteln, für welche Angebote ein Nutzer berechtigt ist.
    BillingClient.SkuType BillingClient.ProductType. Die Konstanten für die Produkttypen INAPP und SUBS sind funktional ähnlich wie die Konstanten für den verworfenen SKU-Typ.
    SkuDetails ProductDetails Dies ist das neue Datenmodell, das Einmalkäufe unterstützt.
    SkuDetailsParams Verwenden Sie QueryProductDetailsParams mit queryProductDetailsAsync.
    SkuDetailsResponseListener Verwenden Sie ProductDetailsResponseListener mit queryProductDetailsAsync.
    QueryPurchaseHistoryParams
    • Verwenden Sie queryPurchasesAsync für aktive oder ausstehende Käufe.
    • Verfolgen Sie verbrauchte Käufe auf Ihren Backend-Servern.
    • Verwenden Sie die serverseitige Voided Purchases API für stornierte oder ungültige Käufe.
    getSkuDetailsList und setSkuDetailsList Verwenden Sie BillingFlowParams.Builder.setProductDetailsParamsList.
    querySkuDetailsAsync queryProductDetailsAsync
    enablePendingPurchases() (API ohne Parameter) enablePendingPurchases(PendingPurchasesParams params)
    Beachten Sie, dass die eingestellte Funktion „enablePendingPurchases()“ funktional äquivalent zu enablePendingPurchases(PendingPurchasesParams.newBuilder().enableOneTimeProducts().build()).
    queryPurchasesAsync(String skuType, PurchasesResponseListener listener) queryPurchasesAsync

    Upgrade von

    In der folgenden Tabelle sind die APIs aufgeführt, die in PBL 9 entfernt wurden, sowie die entsprechenden alternativen APIs, die Sie in Ihrer App verwenden müssen.

    Zuvor verworfene API entfernt Alternative API
    BillingClient.SkuType BillingClient.ProductType. Die Konstanten für die Produkttypen INAPP und SUBS sind funktional ähnlich wie die Konstanten für den verworfenen SKU-Typ.
    SkuDetails ProductDetails Dies ist das neue Datenmodell, das Einmalkäufe unterstützt.
    SkuDetailsParams Verwenden Sie QueryProductDetailsParams mit queryProductDetailsAsync.
    SkuDetailsResponseListener Verwenden Sie ProductDetailsResponseListener mit queryProductDetailsAsync.
    QueryPurchaseHistoryParams
    • Verwenden Sie queryProductDetailsAsync für aktive oder ausstehende Käufe.
    • Verfolgen Sie verbrauchte Käufe auf Ihren Backend-Servern.
    • Verwenden Sie die serverseitige Voided Purchases API für stornierte oder ungültige Käufe.
    getSkuDetailsList und setSkuDetailsList Verwenden Sie BillingFlowParams.Builder.setProductDetailsParamsList.

  4. (Empfohlen) Aktivieren Sie die automatische Wiederverbindung mit dem Dienst.

    Die Play Billing Library kann versuchen, die Dienstverbindung automatisch wiederherzustellen, wenn ein API-Aufruf erfolgt, während der Dienst getrennt ist. Weitere Informationen finden Sie unter Automatische Wiederverbindung mit dem Dienst aktivieren.

  5. Neue Unterantwortcodes verarbeiten

    Das von launchBillingFlow() zurückgegebene BillingResult enthält jetzt ein Unterantwortcodefeld. Dieses Feld wird nur in einigen Fällen ausgefüllt, um einen genaueren Grund für den Fehler anzugeben. Das Feld „sub-response“ kann die folgenden Werte haben:

    • PAYMENT_DECLINED_DUE_TO_INSUFFICIENT_FUNDS – Wird zurückgegeben, wenn das Guthaben des Nutzers geringer ist als der Preis des Artikels, den er kaufen möchte.
    • USER_INELIGIBLE: Wird zurückgegeben, wenn der Nutzer die konfigurierten Voraussetzungen für ein Aboangebot nicht erfüllt.
    • NO_APPLICABLE_SUB_RESPONSE_CODE: Der Standardwert, der zurückgegeben wird, wenn kein anderer Unterantwortcode zutrifft.

    Migrationsschritt: Aktualisieren Sie Ihre PurchasesUpdatedListener- oder gleichwertige Ergebnisverarbeitung, um diese spezifischen Unterantwortcodes zu erkennen und darauf zu reagieren, damit die Nutzerfreundlichkeit verbessert wird. Beispiele: Aufforderung, Zahlungsmethoden zu korrigieren, oder Anzeige einer bestimmten Fehlermeldung.

  6. Hinweis zur Neuklassifizierung von Fehlercodes.

    Wenn die Google Play Store App vom System blockiert wird (z. B. im OEM-angepassten Kindermodus), hat sich der Antwortcode von PBL von ERROR zu BILLING_UNAVAILABLE geändert.

    Migrationsschritt: Achten Sie darauf, dass Ihre Fehlerbehandlungslogik diese Änderung berücksichtigt und nicht darauf angewiesen ist, in diesen spezifischen Szenarien einen generischen Fehler zu erhalten.

  7. Umgang mit der Null-Zulässigkeit von DeveloperProvidedBillingDetails.getLinkUri().

    Wenn Sie DeveloperProvidedBillingDetails im Rahmen einer externen Zahlungsintegration verwenden, ist getLinkUri() jetzt @Nullable.

    Migrationsschritt: Damit diese Änderung sicher durchgeführt werden kann, muss Ihr Integrationscode sowohl null- als auch Leerstring-Werte ("") aus der Methode DeveloperProvidedBillingDetails.getLinkUri() verarbeiten, bevor Browser-Intents geparst oder gestartet werden. Beispiel:

    Kotlin

    val linkUri = details.getLinkUri()
if (!linkUri.isNullOrEmpty()) {
  val intent = Intent(Intent.ACTION_VIEW, Uri.parse(linkUri))
  context.startActivity(intent)
}

    Java

    String linkUri = details.getLinkUri();
if (!android.text.TextUtils.isEmpty(linkUri)) {
  Intent intent = new Intent(Intent.ACTION_VIEW, Uri.parse(linkUri));
  context.startActivity(intent);
}

  8. Optionale Änderungen