बिलिंग नतीजे के रिस्पॉन्स कोड मैनेज करना

जब Play Billing Library का कोई कॉल किसी कार्रवाई को ट्रिगर करता है, तो लाइब्रेरी BillingResult जवाब के बारे में डेवलपर को बताएं. उदाहरण के लिए, अगर आपको queryProductDetailsAsync उपयोगकर्ता के लिए उपलब्ध ऑफ़र पाने के लिए, जवाब कोड में या तो ठीक है कोड और सही ProductDetails देता है ऑब्जेक्ट है या इसमें कोई अलग प्रतिक्रिया है, जो ProductDetails ऑब्जेक्ट सबमिट नहीं किया जा सका.

सभी रिस्पॉन्स कोड गड़बड़ियां नहीं होते. BillingResponseCode रेफ़रंस पेज पर, हर जवाब की पूरी जानकारी मिलती है इस गाइड में चर्चा की गई है. रिस्पॉन्स कोड के कुछ ऐसे उदाहरण जिनमें गड़बड़ियां नहीं बताई गई हैं:

  • BillingClient.BillingResponseCode.OK : कॉल से ट्रिगर की गई कार्रवाई सफलतापूर्वक पूरी हुई.
  • BillingClient.BillingResponseCode.USER_CANCELED : उपयोगकर्ता को Play Store के यूज़र इंटरफ़ेस (यूआई) फ़्लो दिखाने वाली कार्रवाइयों के लिए, यह रिस्पॉन्स यह बताता है कि उपयोगकर्ता ने यूज़र इंटरफ़ेस (यूआई) फ़्लो से बाहर चला गया है, लेकिन प्रोसेस.

जब रिस्पॉन्स कोड से कोई गड़बड़ी दिखती है, तो इसकी वजह कभी-कभी अस्थायी है और इसलिए उससे उबरना संभव है. Play पर कॉल किए जाने पर 'Play Billing लाइब्रेरी' का तरीका इस्तेमाल करने पर, BillingResponseCode दिखता है वह मान है जो वापस पाने लायक स्थिति दिखाता है, तो आपको कॉल फिर से करके देखना चाहिए. तय सीमा में कुछ मामलों में, स्थिति को कुछ समय के लिए नहीं माना जाता है. इसलिए, फिर से कोशिश करनी होती है इसका सुझाव नहीं दिया जाता.

अस्थायी गड़बड़ियां, इन फ़ैक्टर के आधार पर फिर से कोशिश करने की अलग-अलग रणनीतियों के लिए कॉल करती हैं क्या गड़बड़ी तब होती है, जब उपयोगकर्ता सेशन में होते हैं—उदाहरण के लिए, जब कोई उपयोगकर्ता परचेज़ फ़्लो से गुज़रना होता है—या बैकग्राउंड में गड़बड़ी होती है—इसके लिए उदाहरण के लिए, जब onResume के दौरान उपयोगकर्ता की मौजूदा खरीदारी के बारे में क्वेरी की जा रही हो. यहां फिर से रणनीति आज़माएं सेक्शन में, नीचे दिए गए उदाहरण दिए गए हैं और फिर से आज़माने लायक BillingResult जवाब सेक्शन यह सुझाव देता है कि हर रिस्पॉन्स कोड के लिए कौनसी रणनीति सबसे अच्छा काम करेगी.

रिस्पॉन्स कोड के अलावा, गड़बड़ी के कुछ रिस्पॉन्स में डीबग करने और लॉग करने के मकसद से.

फिर से कोशिश करें रणनीतियां

सरल पुनर्प्रयास

ऐसी स्थितियों में, जब उपयोगकर्ता किसी सेशन में हो, तो बेहतर है कि एक आसान फिर से कोशिश करें, ताकि गड़बड़ी की वजह से उपयोगकर्ता अनुभव कम हो सके किया जा सकता है. ऐसी स्थिति में, हमारा सुझाव है कि आप फिर से कोशिश करें. बाहर निकलने की शर्त के तौर पर कुल कोशिशों की संख्या.

नीचे दिए गए उदाहरण में, किसी गड़बड़ी को ठीक करने के लिए फिर से कोशिश करने की आसान रणनीति के बारे में बताया गया है BillingClient तय करते समय कनेक्शन:

class BillingClientWrapper(context: Context) : PurchasesUpdatedListener {
  // Initialize the BillingClient.
  private val billingClient = BillingClient.newBuilder(context)
    .setListener(this)
    .enablePendingPurchases()
    .build()

  // Establish a connection to Google Play.
  fun startBillingConnection() {
    billingClient.startConnection(object : BillingClientStateListener {
      override fun onBillingSetupFinished(billingResult: BillingResult) {
        if (billingResult.responseCode == BillingClient.BillingResponseCode.OK) {
          Log.d(TAG, "Billing response OK")
          // The BillingClient is ready. You can now query Products Purchases.
        } else {
          Log.e(TAG, billingResult.debugMessage)
          retryBillingServiceConnection()
        }
      }

      override fun onBillingServiceDisconnected() {
        Log.e(TAG, "GBPL Service disconnected")
        retryBillingServiceConnection()
      }
    })
  }

  // Billing connection retry logic. This is a simple max retry pattern
  private fun retryBillingServiceConnection() {
    val maxTries = 3
    var tries = 1
    var isConnectionEstablished = false
    do {
      try {
        billingClient.startConnection(object : BillingClientStateListener {
          override fun onBillingSetupFinished(billingResult: BillingResult) {
            if (billingResult.responseCode == BillingClient.BillingResponseCode.OK) {
              isConnectionEstablished = true
              Log.d(TAG, "Billing connection retry succeeded.")
            } else {
              Log.e(
                TAG,
                "Billing connection retry failed: ${billingResult.debugMessage}"
              )
            }
          }
        })
      } catch (e: Exception) {
        e.message?.let { Log.e(TAG, it) }
        tries++
      }
    } while (tries <= maxTries && !isConnectionEstablished)
  }
  ...
}

एक्सपोनेन्शियल बैकऑफ़ फिर से कोशिश करें

हमारा सुझाव है कि Play Billing Library से जुड़ी कार्रवाइयों के लिए, एक्स्पोनेंशियल बैकऑफ़ का इस्तेमाल करें बैकग्राउंड में होते हैं और उपयोगकर्ता अनुभव पर तब तक कोई असर नहीं डालते, जब तक उपयोगकर्ता सत्र में.

उदाहरण के लिए, नए अनुरोधों को स्वीकार करते समय खरीदारी करता है, क्योंकि यह कार्रवाई बैकग्राउंड में हो सकती है और कोई गड़बड़ी होने पर, रीयल टाइम में अनुमति देना ज़रूरी नहीं है.

private fun acknowledge(purchaseToken: String): BillingResult {
  val params = AcknowledgePurchaseParams.newBuilder()
    .setPurchaseToken(purchaseToken)
    .build()
  var ackResult = BillingResult()
  billingClient.acknowledgePurchase(params) { billingResult ->
    ackResult = billingResult
  }
  return ackResult
}

suspend fun acknowledgePurchase(purchaseToken: String) {

  val retryDelayMs = 2000L
  val retryFactor = 2
  val maxTries = 3

  withContext(Dispatchers.IO) {
    acknowledge(purchaseToken)
  }

  AcknowledgePurchaseResponseListener { acknowledgePurchaseResult ->
    val playBillingResponseCode =
    PlayBillingResponseCode(acknowledgePurchaseResult.responseCode)
    when (playBillingResponseCode) {
      BillingClient.BillingResponseCode.OK -> {
        Log.i(TAG, "Acknowledgement was successful")
      }
      BillingClient.BillingResponseCode.ITEM_NOT_OWNED -> {
        // This is possibly related to a stale Play cache.
        // Querying purchases again.
        Log.d(TAG, "Acknowledgement failed with ITEM_NOT_OWNED")
        billingClient.queryPurchasesAsync(
          QueryPurchasesParams.newBuilder()
            .setProductType(BillingClient.ProductType.SUBS)
            .build()
        )
        { billingResult, purchaseList ->
          when (billingResult.responseCode) {
            BillingClient.BillingResponseCode.OK -> {
              purchaseList.forEach { purchase ->
                acknowledge(purchase.purchaseToken)
              }
            }
          }
        }
      }
      in setOf(
         BillingClient.BillingResponseCode.ERROR,
         BillingClient.BillingResponseCode.SERVICE_DISCONNECTED,
         BillingClient.BillingResponseCode.SERVICE_UNAVAILABLE,
       ) -> {
        Log.d(
          TAG,
          "Acknowledgement failed, but can be retried --
          Response Code: ${acknowledgePurchaseResult.responseCode} --
          Debug Message: ${acknowledgePurchaseResult.debugMessage}"
        )
        runBlocking {
          exponentialRetry(
            maxTries = maxTries,
            initialDelay = retryDelayMs,
            retryFactor = retryFactor
          ) { acknowledge(purchaseToken) }
        }
      }
      in setOf(
         BillingClient.BillingResponseCode.BILLING_UNAVAILABLE,
         BillingClient.BillingResponseCode.DEVELOPER_ERROR,
         BillingClient.BillingResponseCode.FEATURE_NOT_SUPPORTED,
       ) -> {
        Log.e(
          TAG,
          "Acknowledgement failed and cannot be retried --
          Response Code: ${acknowledgePurchaseResult.responseCode} --
          Debug Message: ${acknowledgePurchaseResult.debugMessage}"
        )
        throw Exception("Failed to acknowledge the purchase!")
      }
    }
  }
}

private suspend fun <T> exponentialRetry(
  maxTries: Int = Int.MAX_VALUE,
  initialDelay: Long = Long.MAX_VALUE,
  retryFactor: Int = Int.MAX_VALUE,
  block: suspend () -> T
): T? {
  var currentDelay = initialDelay
  var retryAttempt = 1
  do {
    runCatching {
      delay(currentDelay)
      block()
    }
      .onSuccess {
        Log.d(TAG, "Retry succeeded")
        return@onSuccess;
      }
      .onFailure { throwable ->
        Log.e(
          TAG,
          "Retry Failed -- Cause: ${throwable.cause} -- Message: ${throwable.message}"
        )
      }
    currentDelay *= retryFactor
    retryAttempt++
  } while (retryAttempt < maxTries)

  return block() // last attempt
}

ऐसे बिलिंग नतीजे जिन्हें फिर से इस्तेमाल किया जा सकता है

NETWORK_ERROR (गड़बड़ी कोड 12)

समस्या

यह गड़बड़ी बताती है कि नेटवर्क कनेक्शन में कोई समस्या थी को मैनेज करने की अनुमति दें.

संभावित रिज़ॉल्यूशन

रिकवर करने के लिए, आसान बार-बार कोशिश करने या एक्सपोनेन्शियल बैकऑफ़ का इस्तेमाल करें. यह इस बात पर निर्भर करता है कि किस कार्रवाई से गड़बड़ी हुई.

SERVICE_SECONDS (गड़बड़ी कोड -3)

समस्या

यह गड़बड़ी बताती है कि अनुरोध से पहले तय की गई टाइम आउट की सीमा पूरी हो गई है Google Play जवाब दे सकता है. उदाहरण के लिए, किसी देरी की वजह से ऐसा हो सकता है Play Billing Library से जुड़े कॉल के अनुरोध की कार्रवाई को पूरा किया जा सकता है.

संभावित रिज़ॉल्यूशन

यह समस्या आम तौर पर कुछ समय के लिए होती है. फिर से अनुरोध करने के लिए, इनमें से किसी एक का इस्तेमाल करें आसान या एक्स्पोनेंशियल बैकऑफ़ रणनीति, जो इस बात पर निर्भर करती है कि किस कार्रवाई से गड़बड़ी.

SERVICE_DISCONNECTED को नापसंद करें नीचे बताया गया है, तो Google Play Billing सेवा के साथ कनेक्शन टूटता नहीं है और आपको सिर्फ़ 'Play Billing लाइब्रेरी' के किसी भी ऑपरेशन को फिर से करने की कोशिश करनी होगी.

SERVICE_DISCONNECTED (गड़बड़ी कोड -1)

समस्या

इस गंभीर गड़बड़ी का मतलब है कि Google Play से क्लाइंट ऐप्लिकेशन का कनेक्शन BillingClient के ज़रिए स्टोर सेवा गंभीर हो गया है.

संभावित रिज़ॉल्यूशन

जहां तक हो सके इस गड़बड़ी से बचने के लिए, हमेशा Google खाते के इंटरनेट कनेक्शन की जांच करें Play Billing लाइब्रेरी का इस्तेमाल करके कॉल करने से पहले, इस नंबर पर कॉल करें BillingClient.isReady().

SERVICE_DISCONNECTED से खाता वापस पाने की कोशिश करने के लिए तो आपके क्लाइंट ऐप्लिकेशन को इसका इस्तेमाल करके कनेक्शन फिर से स्थापित करने की कोशिश करनी चाहिए BillingClient.startConnection.

SERVICE_TIMEOUT की तरह का इस्तेमाल किया है, तो किस कार्रवाई को ट्रिगर किया गया, इसके आधार पर आसान बार-बार कोशिश करने या एक्स्पोनेंशियल बैकऑफ़ का इस्तेमाल करें गड़बड़ी को ठीक करें.

SERVICE_UNAVAILABLE (गड़बड़ी कोड 2)

अहम जानकारी:

Google Play Billing Library 6.0.0 से, SERVICE_UNAVAILABLE में नेटवर्क समस्याओं के लिए लंबे समय तक वापस लौटाया जाता है. इसे तब वापस भेजा जाता है, जब बिलिंग सेवा उपलब्ध नहीं है और अब काम नहीं करता SERVICE_TIMEOUT केस.

समस्या

यह अस्थायी गड़बड़ी बताती है कि Google Play Billing सेवा फ़िलहाल उपलब्ध नहीं हैं. ज़्यादातर मामलों में, इसका मतलब है कि इंटरनेट की समस्या है क्लाइंट डिवाइस और Google Play Billing सेवाओं के बीच कहीं भी.

संभावित रिज़ॉल्यूशन

यह समस्या आम तौर पर कुछ समय के लिए होती है. फिर से अनुरोध करने के लिए, इनमें से किसी एक का इस्तेमाल करें आसान या एक्स्पोनेंशियल बैकऑफ़ रणनीति, जो इस बात पर निर्भर करती है कि किस कार्रवाई से गड़बड़ी.

SERVICE_DISCONNECTED को नापसंद करें का विकल्प न हो, तो Google Play Billing सेवा के साथ कनेक्शन टूटता नहीं है. ऐसा करने के लिए, आपको कोशिश करें कि किसी भी कार्रवाई की कोशिश की जा रही हो.

BILLING_UNAVAILABLE (गड़बड़ी कोड 3)

समस्या

यह गड़बड़ी बताती है कि उपयोगकर्ता बिलिंग से जुड़ी गड़बड़ी इस अवधि के दौरान हुई है खरीदने की प्रोसेस. ऐसा कब हो सकता है, इसके कुछ उदाहरण यहां दिए गए हैं:

  • उपयोगकर्ता के डिवाइस में मौजूद Play Store ऐप्लिकेशन का वर्शन पुराना है.
  • उपयोगकर्ता किसी ऐसे देश में है जहां यह सुविधा उपलब्ध नहीं है.
  • उपयोगकर्ता एक एंटरप्राइज़ उपयोगकर्ता है और उसके एंटरप्राइज़ एडमिन ने उपयोगकर्ताओं को बंद कर दिया है खरीदारी करने से रोकने में मदद मिलती है.
  • Google Play, उपयोगकर्ता के पेमेंट के तरीके से शुल्क नहीं ले पा रहा है. उदाहरण के लिए, उपयोगकर्ता के क्रेडिट कार्ड की अवधि खत्म हो चुकी है.

संभावित रिज़ॉल्यूशन

इस मामले में, अपने-आप फिर से कोशिश करने की सुविधा से मदद मिलने की संभावना कम है. हालांकि, मैन्युअल तरीके से दोबारा कोशिश करने पर अगर उपयोगकर्ता उस स्थिति को ठीक कर लेता है जिसकी वजह से समस्या हुई थी. उदाहरण के लिए, अगर उपयोगकर्ता अपने Play Store के वर्शन को Play Store पर काम करने वाले वर्शन पर अपडेट करता है. इसके बाद, इसे मैन्युअल तौर पर अपडेट करता है तो फिर से कोशिश करें.

अगर यह गड़बड़ी तब होती है, जब उपयोगकर्ता किसी सेशन में नहीं होता है, तो हो सकता है कि फिर से कोशिश करने पर समझ. आपको BILLING_UNAVAILABLE मिलने पर परचेज़ फ़्लो के बाद कोई गड़बड़ी होती है, तो हो सकता है कि उपयोगकर्ता को खरीदारी के दौरान Google Play से सुझाव लेते हैं. साथ ही, आपको यह पता होना चाहिए कि कोई गड़बड़ी हुई. इस स्थिति में, किसी चीज़ के बारे में बताते हुए गड़बड़ी का मैसेज दिखाया जा सकता है गलती हुई. उसने उपयोगकर्ता को “फिर से कोशिश करें” बटन दिया, ताकि वह समस्या को ठीक करने के बाद, मैन्युअल तरीके से दोबारा कोशिश करें.

गड़बड़ी (गड़बड़ी कोड 6)

समस्या

यह एक गंभीर गड़बड़ी है, जो Google Play की आंतरिक समस्या की ओर इशारा करती है वह भी ऐसा कर सकता है.

संभावित रिज़ॉल्यूशन

कभी-कभी Google Play की आंतरिक समस्याओं की वजह से ERROR अस्थायी हैं और एक्सपोनेन्शियल बैकऑफ़ के साथ फिर से कोशिश करने की सुविधा खतरों को कम करने की कोशिश कर रहे हैं. जब उपयोगकर्ता सेशन में होते हैं, तो सामान्य तरीके से फिर से कोशिश करने को प्राथमिकता दी जाती है.

ITEM_ALREADY_OWNED

समस्या

इस जवाब से पता चलता है कि Google Play उपयोगकर्ता के पास पहले से ही या एक बार खरीदे जाने वाले प्रॉडक्ट को खरीदने की कोशिश कर रहे हैं. ज़्यादातर मामलों में, यह कोई अस्थायी गड़बड़ी नहीं होती. हालांकि, ऐसा सिर्फ़ तब होता है, जब ऐसा Google Play की कैश मेमोरी में सेव किया गया पुराना डेटा.

संभावित रिज़ॉल्यूशन

इस गड़बड़ी से बचने के लिए, जब इसकी वजह कैश मेमोरी से जुड़ी समस्या न हो, तो अगर उपयोगकर्ता के पास पहले से प्रॉडक्ट का मालिकाना हक है, तो उसे खरीदे जाने वाले प्रॉडक्ट के तौर पर मिलेगा. पक्का करें कि आपने खरीदारी के लिए उपलब्ध प्रॉडक्ट दिखाए जाने पर, उपयोगकर्ता के एनटाइटलमेंट और फ़िल्टर करें कि उपयोगकर्ता अपनी ज़रूरत के हिसाब से क्या खरीद सकता है. जब क्लाइंट ऐप्लिकेशन को कैश मेमोरी में सेव की गई समस्या की वजह से यह गड़बड़ी मिलती है, तो गड़बड़ी ट्रिगर होती है Google Play की कैश मेमोरी को, Play के बैकएंड से मिले नए डेटा के साथ अपडेट किया जाता है. गड़बड़ी के बाद फिर से कोशिश करें. इससे इस स्थिति में, यह समस्या ठीक हो जाएगी केस. BillingClient.queryPurchasesAsync() पर कॉल करें ITEM_ALREADY_OWNED मिलने के बाद यह देखने के लिए कि उपयोगकर्ता ने प्रॉडक्ट को हासिल किया है या नहीं. अगर ऐसा नहीं है खरीदारी की फिर से कोशिश करने के लिए, आसान तरीके से फिर से कोशिश करें.

ITEM_NOT_OWNED

समस्या

खरीदारी के इस रिस्पॉन्स से पता चलता है कि Google Play उपयोगकर्ता के पास उस सदस्यता या एक बार खरीदे जाने वाले प्रॉडक्ट को बदलना है जिसे उपयोगकर्ता बदलना चाहता है, स्वीकार करें या उसका इस्तेमाल करें. ज़्यादातर मामलों में, यह कोई अस्थायी गड़बड़ी नहीं होती. हालांकि, Google की वजह से ऐसा होता है Play की कैश मेमोरी पुरानी हो रही है.

संभावित रिज़ॉल्यूशन

जब कैश मेमोरी में सेव की गई समस्या की वजह से गड़बड़ी मिलती है, तो गड़बड़ी Google को ट्रिगर करती है Play की कैश मेमोरी को, Play के बैकएंड से मिले नए डेटा के साथ अपडेट किया जाता है. फिर से प्रयास कर रहा है कृपया गड़बड़ियों को ठीक करने के बाद, फिर से कोशिश करें अस्थायी इंस्टेंस. ITEM_NOT_OWNED मिलने के बाद, BillingClient.queryPurchasesAsync() पर कॉल करके देखें कि उपयोगकर्ता ने प्रॉडक्ट खरीदा. अगर ऐसा नहीं है, तो आसान प्रोसेस लॉजिक का इस्तेमाल करके खरीदारी.

बिलिंग नतीजे के ऐसे जवाब जिन्हें फिर से बहाल नहीं किया जा सकता

फिर से कोशिश करने के लॉजिक का इस्तेमाल करके, इन गड़बड़ियों को ठीक नहीं किया जा सकता.

FEATURE_NOT_SUPPORTED

समस्या

इस गड़बड़ी का पता चलता है कि Google Play Billing की सुविधा ठीक से काम नहीं करती उपयोगकर्ता के डिवाइस पर काम करता है. ऐसा शायद Play Store के पुराने वर्शन की वजह से हुआ है.

उदाहरण के लिए, शायद आपके कुछ उपयोगकर्ताओं का डिवाइसों में, इन-ऐप्लिकेशन मैसेज की सुविधा काम नहीं करती.

संभावित जोखिम को कम करने की प्रोसेस

Play Billing को कॉल करने से पहले, BillingClient.isFeatureSupported() का इस्तेमाल करें और जानें कि सुविधा से जुड़ी सहायता उपलब्ध है या नहीं लाइब्रेरी.

when {
  billingClient.isReady -> {
    if (billingClient.isFeatureSupported(BillingClient.FeatureType.IN_APP_MESSAGING)) {
       // use feature
    }
  }
}

USER_CANCELED

समस्या

उपयोगकर्ता ने बिलिंग फ़्लो के यूज़र इंटरफ़ेस (यूआई) से क्लिक किया.

संभावित रिज़ॉल्यूशन

यह सिर्फ़ जानकारी के लिए है. ऐसा हो सकता है कि इसमें पूरी जानकारी न दी जाए.

ITEM_UNAVAILABLE

समस्या

Google Play Billing की सदस्यता या एक बार खरीदने के लिए उपलब्ध प्रॉडक्ट इस उपयोगकर्ता के लिए खरीदारी के लिए उपलब्ध है.

संभावित जोखिम को कम करने की प्रोसेस

पक्का करें कि आपका ऐप्लिकेशन, सुझाए गए queryProductDetailsAsync के ज़रिए प्रॉडक्ट की जानकारी को रीफ़्रेश करता हो. ध्यान रखें कि कितनी बार लागू करने के लिए, Play Console के कॉन्फ़िगरेशन पर प्रॉडक्ट कैटलॉग में बदलाव किया जाएगा अगर ज़रूरी हो, तो पेज को कुछ और रीफ़्रेश किया जा सकता है. Google Play Billing का इस्तेमाल करके सिर्फ़ ऐसे प्रॉडक्ट बेचने की कोशिश करें जो सही नतीजे देते हों जानकारी queryProductDetailsAsync से मिली है. प्रॉडक्ट के लिए ज़रूरी शर्तों के कॉन्फ़िगरेशन की जांच करें और देखें कि क्या इनमें अंतर मौजूद है. उदाहरण के लिए, हो सकता है कि आप किसी ऐसे प्रॉडक्ट के लिए क्वेरी कर रहे हों जो सिर्फ़ क्षेत्र के अलावा कोई अन्य क्षेत्र. कोई भी प्रॉडक्ट इस्तेमाल के लिए उपलब्ध होना चाहिए, ताकि वह खरीदारी के लिए उपलब्ध हो सके. इसके लिए, यह ज़रूरी है कि आपका ऐप्लिकेशन पब्लिश किया गया है और इसका ऐप्लिकेशन उपयोगकर्ता के देश में उपलब्ध होना चाहिए.

कभी-कभी, खास तौर पर टेस्टिंग के दौरान, प्रॉडक्ट में सब कुछ सही होता है कॉन्फ़िगरेशन के बावजूद यह गड़बड़ी उपयोगकर्ताओं को दिखती है. ऐसा इन वजहों से हो सकता है: Google के सर्वर पर प्रॉडक्ट की जानकारी दिखने में देरी. फिर से कोशिश करें बाद में.

Developer_ERROR

समस्या

यह एक गंभीर गड़बड़ी है, जिससे पता चलता है कि आप गलत तरीके से एपीआई का इस्तेमाल कर रहे हैं. उदाहरण के लिए, BillingClient.launchBillingFlow को गलत पैरामीटर देने पर यह गड़बड़ी होती है.

संभावित रिज़ॉल्यूशन

पक्का करें कि आपने अलग-अलग Play Billing Library का इस्तेमाल सही तरीके से किया हो कॉल. साथ ही, गड़बड़ी के बारे में ज़्यादा जानकारी के लिए डीबग मैसेज देखें.