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 zu PBL 9 migrieren und wie Sie die neuen Funktionen einbinden.

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

Übersicht

PBL 9 enthält Verbesserungen an bestehenden APIs sowie die Entfernung zuvor verworfener APIs. Diese Version der Bibliothek bietet außerdem einen umfassenderen Fehlerkontext durch neue Unterantwortcodes.

Abwärtskompatibilität für das PBL-Upgrade

Wenn Sie zu PBL 9 migrieren möchten, müssen Sie einige Ihrer vorhandenen API Verweise in Ihrer App aktualisieren oder entfernen. Das wird in den Versionshinweisen und später in diesem Migrationsleitfaden beschrieben.

Upgrade von PBL 7 oder 8 auf PBL 9

So führen Sie ein Upgrade von PBL 7 oder 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.1.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 Coroutinen-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.1.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 queryProductDetailsAsync Methode.

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

  3. Entfernte APIs verarbeiten

    In der folgenden Tabelle sind die entfernten APIs und die entsprechenden alternativen APIs aufgeführt, 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 Ihre Implementierung eine dieser entfernten APIs verwendet, finden Sie in der Tabelle die entsprechenden alternativen APIs.

    Zuvor verworfene API entfernt Alternative API
    queryPurchaseHistoryAsync-APIs Siehe Kaufverlauf abfragen. Wenn Sie queryPurchaseHistoryAsync verwendet haben, um die Berechtigung für kostenlose Testversionen 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 den Produkttyp INAPP und SUBS sind funktional ähnlich den verworfenen Konstanten für den SKU-Typ.
    SkuDetails ProductDetails. Dies ist das neue Datenmodell, das einmalige Produkte 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.
    • Erfassen 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 verworfene Methode enablePendingPurchases() funktional identisch ist mit enablePendingPurchases(PendingPurchasesParams.newBuilder().enableOneTimeProducts().build()).
    queryPurchasesAsync(String skuType, PurchasesResponseListener listener) queryPurchasesAsync

    Upgrade von

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

    Zuvor verworfene API entfernt Alternative API
    BillingClient.SkuType BillingClient.ProductType. Die Konstanten für den Produkttyp INAPP und SUBS sind funktional ähnlich den verworfenen Konstanten für den SKU-Typ.
    SkuDetails ProductDetails. Dies ist das neue Datenmodell, das einmalige Produkte 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.
    • Erfassen 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) Automatische Wiederverbindung mit dem Dienst aktivieren

    Die Play Billing Library kann versuchen, die Dienstverbindung automatisch wiederherzustellen, wenn ein API-Aufruf erfolgt, während die Verbindung 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 Feld für den Unterantwortcode. Dieses Feld wird nur in einigen Fällen ausgefüllt, um einen genaueren Grund für den Fehler anzugeben. Das Feld für die Unterantwort 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 Berechtigungsvoraussetzungen für ein Aboangebot nicht erfüllt.
    • NO_APPLICABLE_SUB_RESPONSE_CODE - Der Standardwert, der zurückgegeben wird, wenn kein anderer Unterantwortcode anwendbar ist.

    Migrationsschritt: Aktualisieren Sie Ihre PurchasesUpdatedListener oder die entsprechende Ergebnisverarbeitung, um diese spezifischen Unterantwort codes zu erkennen und darauf zu reagieren, damit die Nutzererfahrung verbessert wird. Sie können Nutzer beispielsweise auffordern, Zahlungsmethoden zu korrigieren, oder eine bestimmte Fehlermeldung anzeigen.

  6. Neuklassifizierung von Fehlercodes

    In Fällen, in denen 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 in diesen spezifischen Szenarien nicht auf den Empfang eines generischen Fehlers angewiesen ist.

  7. Null-Zulässigkeit für DeveloperProvidedBillingDetails.getLinkUri() verarbeiten

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

    Migrationsschritt: Um diese Änderung sicher zu verarbeiten, muss Ihr Integrationscode sowohl null als auch Leerstringwerte ("") aus der DeveloperProvidedBillingDetails.getLinkUri()-Methode verarbeiten, bevor Browser-Intents geparst oder gestartet werden. Beispiel:

    Kotlin

    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