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 wie Sie 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 eingestellte APIs. Diese Version der Bibliothek bietet außerdem einen umfangreicheren Fehlerkontext durch neue Unterantwortcodes.

Abwärtskompatibilität für PBL-Upgrade

Wenn ihr zur PBL 9 migrieren möchtet, müsst ihr einige eurer vorhandenen API-Referenzen in eurer 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 ein 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 Implementierung von queryProductDetailsAsync erforderlich. Weitere Informationen findest du unter Produktverfügbarkeit 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 findest du 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 Verwende QueryProductDetailsParams mit queryProductDetailsAsync.
    SkuDetailsResponseListener Verwende 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 Verwende QueryProductDetailsParams mit queryProductDetailsAsync.
    SkuDetailsResponseListener Verwende 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) Aktivieren Sie die automatische Wiederherstellung der Verbindung zum 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 Dienstwiederverbindung 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 zutrifft.

    Migrationsschritt: Aktualisieren Sie Ihre PurchasesUpdatedListener- oder entsprechende Ergebnisverarbeitung, damit diese spezifischen Unterantwortcodes erkannt und darauf reagiert werden kann, um die Nutzerfreundlichkeit zu verbessern. Beispiele: Aufforderung, Zahlungsmethoden zu korrigieren, oder Anzeige einer bestimmten Fehlermeldung.

  6. Kenntnis der 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 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 Sie DeveloperProvidedBillingDetails im Rahmen einer Integration externer Zahlungen verwenden, 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.