Eseguire la migrazione alla Libreria Fatturazione Google Play 9 dalle versioni 7 o 8

Questo documento descrive come eseguire la migrazione da Libreria Fatturazione Google Play (PBL) 7 o 8 a PBL 9 e come eseguire l'integrazione con le nuove funzionalità.

Per un elenco completo delle modifiche nella versione 9.0.0, consulta le note di rilascio.

Panoramica

PBL 9 contiene miglioramenti alle API esistenti e la rimozione delle API precedentemente deprecate. Questa versione della libreria introduce anche un contesto di errore più ricco tramite nuovi codici di sotto-risposta.

Compatibilità con le versioni precedenti per l'upgrade di PBL

Per eseguire la migrazione a PBL 9, devi aggiornare o rimuovere alcuni dei riferimenti API esistenti dalla tua app, come descritto nelle note di rilascio e più avanti in questa guida alla migrazione.

Eseguire l'upgrade da PBL 7 o 8 a PBL 9

Per eseguire l'upgrade da PBL 7 o 8 a PBL 9:

  1. Aggiorna la versione della dipendenza Libreria Fatturazione Play nel file build.gradle della tua app.

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

    Se utilizzi Kotlin, il modulo KTX di Libreria Fatturazione Google Play contiene estensioni Kotlin e supporto per le coroutine che ti consentono di scrivere codice Kotlin idiomatico quando utilizzi Libreria Fatturazione Google Play. Per includere queste estensioni nel tuo progetto, aggiungi la seguente dipendenza al file build.gradle della tua app come mostrato di seguito:

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

  2. (Applicabile solo per l'upgrade da PBL 7 a PBL 9). Aggiorna l' implementazione del queryProductDetailsAsync metodo.

    La firma del metodo ProductDetailsResponseListener.onProductDetailsResponse è stata modificata, il che richiede modifiche nella tua app per l'implementazione queryProductDetailsAsync. Per maggiori informazioni, consulta la sezione Mostrare i prodotti disponibili per l'acquisto.

  3. Gestisci le API rimosse.

    La tabella seguente elenca le API rimosse e le API alternative corrispondenti che devi utilizzare nella tua app.

    Upgrade da

    PBL 9 non supporta più le API elencate nella tabella seguente. Se la tua implementazione utilizza una di queste API rimosse, consulta la tabella per trovare le API alternative corrispondenti.

    API precedentemente deprecata rimossa API alternativa da utilizzare
    API queryPurchaseHistoryAsync Consulta la sezione Eseguire query sulla cronologia acquisti. Se utilizzavi queryPurchaseHistoryAsync per determinare l'idoneità alle prove senza costi, ora devi utilizzare ProductDetails.getSubscriptionOfferDetails() per determinare le offerte per cui un utente è idoneo.
    BillingClient.SkuType BillingClient.ProductType. Le costanti del tipo di prodotto INAPP e SUBS rimangono funzionalmente simili alle costanti del tipo di SKU deprecate.
    SkuDetails ProductDetails. Questo è il nuovo modello di dati che supporta i prodotti una tantum.
    SkuDetailsParams Utilizza QueryProductDetailsParams con queryProductDetailsAsync.
    SkuDetailsResponseListener Utilizza ProductDetailsResponseListener con queryProductDetailsAsync.
    QueryPurchaseHistoryParams
    • Utilizza queryPurchasesAsync per gli acquisti attivi o in attesa.
    • Monitora gli acquisti consumati sui server di backend.
    • Utilizza l'API Voided Purchases lato server per gli acquisti annullati o annullati.
    getSkuDetailsList e setSkuDetailsList Utilizza BillingFlowParams.Builder.setProductDetailsParamsList
    querySkuDetailsAsync queryProductDetailsAsync
    enablePendingPurchases() (API senza parametri) enablePendingPurchases(PendingPurchasesParams params)
    Tieni presente che la funzione enablePendingPurchases() deprecata è funzionalmente equivalente a enablePendingPurchases(PendingPurchasesParams.newBuilder().enableOneTimeProducts().build()).
    queryPurchasesAsync(String skuType, PurchasesResponseListener listener) queryPurchasesAsync

    Upgrade da

    La tabella seguente elenca le API rimosse in PBL 9 e le API alternative corrispondenti che devi utilizzare nella tua app.

    API precedentemente deprecata rimossa API alternativa da utilizzare
    BillingClient.SkuType BillingClient.ProductType. Le costanti del tipo di prodotto INAPP e SUBS rimangono funzionalmente simili alle costanti del tipo di SKU deprecate.
    SkuDetails ProductDetails. Questo è il nuovo modello di dati che supporta i prodotti una tantum.
    SkuDetailsParams Utilizza QueryProductDetailsParams con queryProductDetailsAsync.
    SkuDetailsResponseListener Utilizza ProductDetailsResponseListener con queryProductDetailsAsync.
    QueryPurchaseHistoryParams
    getSkuDetailsList e setSkuDetailsList Utilizza BillingFlowParams.Builder.setProductDetailsParamsList

  4. (Consigliato) Abilita la riconnessione automatica del servizio.

    Libreria Fatturazione Play può tentare di ristabilire automaticamente la connessione al servizio se viene effettuata una chiamata API mentre il servizio è disconnesso. Per maggiori informazioni, consulta la sezione Abilitare la riconnessione automatica del servizio.

  5. Gestisci i nuovi codici di sotto-risposta.

    Il BillingResult restituito da launchBillingFlow() ora includerà un campo del codice di sotto-risposta. Questo campo verrà compilato solo in alcuni casi per fornire un motivo più specifico per l'errore. Il campo di sotto-risposta può avere i seguenti valori:

    • PAYMENT_DECLINED_DUE_TO_INSUFFICIENT_FUNDS - Restituito quando i fondi dell'utente sono inferiori al prezzo dell'articolo che sta tentando di acquistare.
    • USER_INELIGIBLE - Restituito quando l'utente non soddisfa i requisiti di idoneità configurati per un'offerta di abbonamento.
    • NO_APPLICABLE_SUB_RESPONSE_CODE - Il valore predefinito, restituito quando non è applicabile nessun altro codice di sotto-risposta.

    Passaggio di migrazione: aggiorna il tuo PurchasesUpdatedListener o la gestione dei risultati equivalente per riconoscere e rispondere a questi codici di sotto-risposta specifici per offrire una migliore esperienza utente. Ad esempio, richiedendo di correggere i metodi di pagamento o mostrando un messaggio di errore specifico.

  6. Informazioni sulla riclassificazione dei codici di errore.

    Per le istanze in cui l'app Play Store è bloccata dal sistema (ad esempio, in modalità Bambini personalizzata dall'OEM), il codice di risposta di PBL è cambiato da ERROR a BILLING_UNAVAILABLE.

    Passaggio di migrazione: assicurati che la logica di gestione degli errori tenga conto di questa modifica e non si basi sulla ricezione di un errore generico in questi scenari specifici.

  7. Gestisci la DeveloperProvidedBillingDetails.getLinkUri() nullabilità.

    Se utilizzi DeveloperProvidedBillingDetails nell'ambito di un'integrazione di pagamenti esterni, getLinkUri() è ora @Nullable.

    Passaggio di migrazione: per gestire questa modifica in modo sicuro, assicurati che il tuo codice di integrazione gestisca i valori null e stringa vuota ("") dal DeveloperProvidedBillingDetails.getLinkUri() metodo prima di analizzare o avviare gli intent del browser. Ad esempio:

    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. Modifiche facoltative.