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 und entfernt zuvor verworfene APIs. Diese Version der Bibliothek bietet außerdem einen umfangreicheren Fehlerkontext durch neue Unterantwortcodes.

Abwärtskompatibilität für PBL-Upgrade

Wenn Sie zur PBL 9 migrieren möchten, müssen Sie einige Ihrer vorhandenen API-Referenzen in 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 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 Koroutinen, 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 Upgrades von PBL 7 auf PBL 9.) Aktualisieren Sie die Implementierung der Methode queryProductDetailsAsync.

    Die Signatur der Methode ProductDetailsResponseListener.onProductDetailsResponse wurde geändert. Daher sind Änderungen in Ihrer App für die Implementierung von queryProductDetailsAsync erforderlich. Weitere Informationen findest du unter Zum Kauf verfügbare Produkte 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 in Ihrer Implementierung eine dieser entfernten APIs verwendet wird, finden Sie in der Tabelle die entsprechenden alternativen APIs.

    Zuvor verworfene API entfernt Alternative API, die verwendet werden soll
    queryPurchaseHistoryAsync APIs Weitere Informationen finden Sie unter Bisherige Käufe 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 Produkttypkonstanten INAPP und SUBS sind funktional ähnlich wie die verworfenen SKU-Typkonstanten.
    SkuDetails ProductDetails. Dies ist das neue Datenmodell, das Einmalkaufprodukte unterstützt.
    SkuDetailsParams Verwenden Sie QueryProductDetailsParams mit queryProductDetailsAsync.
    SkuDetailsResponseListener Verwenden Sie ProductDetailsResponseListener mit queryProductDetailsAsync.
    QueryPurchaseHistoryParams
    • Verwende queryPurchasesAsync für aktive oder ausstehende Käufe.
    • Verbrauchte Käufe auf Ihren Backend-Servern erfassen
    • Verwenden Sie für stornierte oder ungültige Käufe die serverseitige Voided Purchases API.
    getSkuDetailsList und setSkuDetailsList Verwende BillingFlowParams.Builder.setProductDetailsParamsList.
    querySkuDetailsAsync queryProductDetailsAsync
    enablePendingPurchases() (API ohne Parameter) enablePendingPurchases(PendingPurchasesParams params)
    Die eingestellte Methode „enablePendingPurchases()“ entspricht funktional 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, die verwendet werden soll
    BillingClient.SkuType BillingClient.ProductType. Die Produkttypkonstanten INAPP und SUBS sind funktional ähnlich wie die verworfenen SKU-Typkonstanten.
    SkuDetails ProductDetails. Dies ist das neue Datenmodell, das Einmalkaufprodukte 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.
    • Verbrauchte Käufe auf Ihren Backend-Servern erfassen
    • Verwenden Sie für stornierte oder ungültige Käufe die serverseitige Voided Purchases API.
    getSkuDetailsList und setSkuDetailsList Verwende BillingFlowParams.Builder.setProductDetailsParamsList.

  4. (Empfohlen) Automatische Wiederherstellung der Verbindung zum Dienst aktivieren.

    Die Play Billing Library kann versuchen, die Dienstverbindung automatisch wiederherzustellen, wenn ein API-Aufruf erfolgt, während die Verbindung zum Dienst getrennt ist. Weitere Informationen finden Sie unter Automatische Wiederherstellung der Dienstverbindung 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 Teilnahmevoraussetzungen 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 entsprechende Ergebnisverarbeitung, um diese spezifischen Unterantwortcodes zu erkennen und darauf zu reagieren, um die Nutzerfreundlichkeit zu verbessern. Fordere den Nutzer beispielsweise auf, die Zahlungsmethoden zu korrigieren, oder zeige eine bestimmte Fehlermeldung an.

  6. Kenntnis der 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 Logik zur Fehlerbehandlung diese Änderung berücksichtigt und in diesen spezifischen Szenarien nicht auf einen allgemeinen Fehler angewiesen ist.

  7. Behandeln Sie die Null-Zulässigkeit von DeveloperProvidedBillingDetails.getLinkUri().

    Wenn du DeveloperProvidedBillingDetails im Rahmen einer Integration externer Zahlungen verwendest, ist getLinkUri() jetzt @Nullable.

    Migrationsschritt: Damit diese Änderung sicher verarbeitet wird, muss Ihr Integrationscode sowohl null- als auch leere Stringwerte ("") aus der Methode DeveloperProvidedBillingDetails.getLinkUri() 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.