Как перейти на библиотеку Google Play Платежей версии 9 с версии 7 или 8

В этом документе описано, как перейти с библиотеки Google Play Платежей (PBL) версии 7 или 8 на PBL версии 9 и как интегрировать новые функции.

Полный список изменений в версии 9.0.0 приведен в примечаниях к выпуску.

Обзор

В PBL 9 улучшены существующие API и удалены устаревшие. В этой версии библиотеки также представлен более подробный контекст ошибок за счет новых кодов дополнительных ответов.

Обратная совместимость для обновления PBL

Чтобы перейти на PBL 9, вам нужно обновить или удалить некоторые ссылки на API из приложения, как описано в примечаниях к выпуску и далее в этом руководстве по переносу.

Как перейти с PBL 7 или 8 на PBL 9

Чтобы перейти с PBL 7 или 8 на PBL 9, выполните следующие действия:

  1. Обновите версию зависимости библиотеки Play Платежей в файле build.gradle приложения.

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

    Если вы используете Kotlin, то модуль KTX библиотеки Google Play Платежей содержит расширения Kotlin и поддержку сопрограмм, которые позволяют писать идиоматический код Kotlin при использовании библиотеки Google Play Платежей. Чтобы включить эти расширения в проект, добавьте в файл build.gradle своего приложения следующую зависимость:

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

  2. (Применимо только при обновлении с PBL 7 до PBL 9). Обновите реализацию метода queryProductDetailsAsync.

    Изменилась сигнатура метода ProductDetailsResponseListener.onProductDetailsResponse, поэтому вам нужно внести изменения в реализацию queryProductDetailsAsync в приложении. Подробнее о том, как показывать наличие товаров, доступных для покупки…

  3. Обработайте удаленные API.

    В таблице ниже перечислены удаленные API и альтернативные API, которые нужно использовать в приложении.

    Переход с версии

    В PBL 9 больше не поддерживаются API, перечисленные в таблице ниже. Если в вашей реализации используются какие-либо из этих удаленных API, ознакомьтесь с таблицей, чтобы узнать, какие API можно использовать вместо них.

    Удален API, ранее признанный устаревшим Альтернативный API
    API queryPurchaseHistoryAsync Подробнее о запросе истории покупок… Если вы использовали queryPurchaseHistoryAsync, чтобы определить, доступен ли пользователю бесплатный пробный период, теперь вам нужно использовать ProductDetails.getSubscriptionOfferDetails().
    BillingClient.SkuType BillingClient.ProductType. Константы типов товаров INAPP и SUBS функционально аналогичны устаревшим константам типов SKU.
    SkuDetails ProductDetails. Это новая модель данных, которая поддерживает контент для однократных покупок.
    SkuDetailsParams Используйте QueryProductDetailsParams с queryProductDetailsAsync.
    SkuDetailsResponseListener Используйте ProductDetailsResponseListener с queryProductDetailsAsync.
    QueryPurchaseHistoryParams
    • Используйте queryPurchasesAsync для активных или незавершенных покупок.
    • Отслеживайте использованные покупки на своих серверах.
    • Используйте серверный Voided Purchases API для отмененных или аннулированных покупок.
    getSkuDetailsList и setSkuDetailsList Используйте BillingFlowParams.Builder.setProductDetailsParamsList.
    querySkuDetailsAsync queryProductDetailsAsync
    enablePendingPurchases() (API без параметров) enablePendingPurchases(PendingPurchasesParams params)
    Обратите внимание, что устаревший метод enablePendingPurchases() функционально эквивалентен enablePendingPurchases(PendingPurchasesParams.newBuilder().enableOneTimeProducts().build()).
    queryPurchasesAsync(String skuType, PurchasesResponseListener listener) queryPurchasesAsync

    Переход с версии

    В таблице ниже перечислены API, удаленные из PBL 9, и соответствующие альтернативные API, которые необходимо использовать в приложении.

    Удален API, ранее признанный устаревшим Альтернативный API
    BillingClient.SkuType BillingClient.ProductType. Константы типов товаров INAPP и SUBS функционально аналогичны устаревшим константам типов SKU.
    SkuDetails ProductDetails. Это новая модель данных, которая поддерживает контент для однократных покупок.
    SkuDetailsParams Используйте QueryProductDetailsParams с queryProductDetailsAsync.
    SkuDetailsResponseListener Используйте ProductDetailsResponseListener с queryProductDetailsAsync.
    QueryPurchaseHistoryParams
    • Используйте queryProductDetailsAsync для активных или незавершенных покупок.
    • Отслеживайте использованные покупки на своих серверах.
    • Используйте серверный Voided Purchases API для отмененных или аннулированных покупок.
    getSkuDetailsList и setSkuDetailsList Используйте BillingFlowParams.Builder.setProductDetailsParamsList.

  4. Включите автоматическое повторное подключение к сервису (рекомендуется).

    Библиотека Play Платежей может попытаться автоматически восстановить подключение к сервису, если вызов API выполняется, когда сервис отключен. Подробнее о том, как включить автоматическое повторное подключение сервиса…

  5. Обрабатывайте новые коды дополнительных ответов.

    BillingResult, возвращаемый из launchBillingFlow(), теперь будет включать поле с кодом дополнительного ответа. Это поле заполняется только в некоторых случаях, чтобы указать более конкретную причину сбоя. Поле sub-response может принимать следующие значения:

    • PAYMENT_DECLINED_DUE_TO_INSUFFICIENT_FUNDS – возвращается, если у пользователя недостаточно средств для покупки товара.
    • USER_INELIGIBLE – возвращается, если пользователь не соответствует требованиям для специального предложения.
    • NO_APPLICABLE_SUB_RESPONSE_CODE – значение по умолчанию, которое возвращается, если не подходит ни один другой код дополнительного ответа.

    Шаг переноса. Обновите обработку результатов PurchasesUpdatedListener или эквивалентных им, чтобы распознавать эти дополнительные коды ответов и реагировать на них. Это позволит улучшить взаимодействие с пользователями. Например, можно предложить пользователю исправить способ оплаты или показать определенное сообщение об ошибке.

  6. Осведомленность о реклассификации кодов ошибок.

    В случаях, когда приложение Google Play заблокировано системой (например, в детском режиме, настроенном производителем), код ответа от PBL изменен с ERROR на BILLING_UNAVAILABLE.

    Шаг переноса. Убедитесь, что логика обработки ошибок учитывает это изменение и не зависит от получения общей ошибки в этих конкретных сценариях.

  7. Обработка допустимости значения NULL для DeveloperProvidedBillingDetails.getLinkUri().

    Если вы используете DeveloperProvidedBillingDetails в рамках интеграции внешних платежей, то getLinkUri() теперь называется @Nullable.

    Шаг переноса. Чтобы безопасно обработать это изменение, убедитесь, что код интеграции обрабатывает значения null и пустую строку ("") из метода DeveloperProvidedBillingDetails.getLinkUri() перед синтаксическим анализом или запуском намерений браузера. Пример:

    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. Необязательные изменения.