Перейдите на Google Play Billing Library 9 с версий 7 или 8.

В этом документе описывается, как осуществить миграцию с Google Play Billing Library (PBL) 7 или 8 на PBL 9 и как интегрировать новые функции.

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

Обзор

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

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

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

Обновление с PBL 7 или 8 до PBL 9

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

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

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

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

    dependencies {
  val billing_version = "9.0.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 Константы типов продуктов INAPP и SUBS функционально аналогичны устаревшим константам типов SKU.
    SkuDetails ProductDetails . Это новая модель данных, поддерживающая разовые продукты.
    SkuDetailsParams Используйте QueryProductDetailsParams с queryProductDetailsAsync .
    SkuDetailsResponseListener Используйте ProductDetailsResponseListener с queryProductDetailsAsync .
    QueryPurchaseHistoryParams
    • Используйте queryPurchasesAsync для активных или ожидающих оформления покупок.
    • Отслеживайте совершенные покупки на своих внутренних серверах.
    • Для аннулирования или отмены покупок используйте серверный 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 Константы типов продуктов INAPP и SUBS функционально аналогичны устаревшим константам типов SKU.
    SkuDetails ProductDetails . Это новая модель данных, поддерживающая разовые продукты.
    SkuDetailsParams Используйте QueryProductDetailsParams с queryProductDetailsAsync .
    SkuDetailsResponseListener Используйте ProductDetailsResponseListener с queryProductDetailsAsync .
    QueryPurchaseHistoryParams
    • Используйте queryProductDetailsAsync для активных или ожидающих оформления покупок.
    • Отслеживайте совершенные покупки на своих внутренних серверах.
    • Для аннулирования или отмены покупок используйте серверный API для аннулированных покупок.
    getSkuDetailsList и setSkuDetailsList Используйте BillingFlowParams.Builder.setProductDetailsParamsList

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

    Библиотека Play Billing может попытаться автоматически восстановить соединение со службой, если вызов API выполняется во время отключения службы. Для получения дополнительной информации см. раздел «Включение автоматического переподключения к службе» .

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

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

    • PAYMENT_DECLINED_DUE_TO_INSUFFICIENT_FUNDS - Возвращается, когда на счету пользователя меньше стоимости товара, который он пытается приобрести.
    • USER_INELIGIBLE — Возвращается, если пользователь не соответствует заданным требованиям для получения подписки.
    • NO_APPLICABLE_SUB_RESPONSE_CODE — значение по умолчанию, возвращаемое, если ни один другой код подответа не применим.

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

  6. Учет переклассификации кодов ошибок.

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

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

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

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

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

    Котлин 

    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. Дополнительные изменения по желанию.