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

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

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

Обзор

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

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

Чтобы перейти на библиотеку Play Платежей версии 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
    queryPurchaseHistoryAsync API Подробнее о запросах истории покупок… Если вы использовали 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. Рекомендуем включить автоматическое повторное подключение к сервису.

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

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