google play in app billing api version is less than 3 что это такое
Android In-app Billing: от мобильного приложения до серверной валидации и тестирования
Всем привет! Недавно передо мной встала задача интегрировать биллинг в наш сервис, и, хотя изначально задача казалась довольно простой, в результате это вылилось в исследование длиной в месяц времени, кучу нервов и открытий. Результатом стало понимание того, что, несмотря на огромное количество документации, не все можно найти простым запросом в Google (а в некоторых местах документация предлагает откровенный бред, о чем я еще расскажу далее).
В результате биллинг от Google Play был успешно интегрирован в наш сервис, валидация покупок и подписок на серверной стороне работает. Кому стало интересно — добро пожаловать под кат: здесь будет полное описание всего, начиная от регистрации покупок в консоли управления Google Play, и заканчивая работой с подписками на своем бекенде.
Для начала коротко о пациенте. Я буду разбирать по кусочкам Google Play In-App Billing V3 а также облачный Android Publisher API, который и поможет нам как с валидацией покупок, так и при работе с подписками. Также не обойдем стороной Консоль управления Google Play — она тоже нам понадобится.
Зачем вообще это нужно?
Если у вас клиент-серверное приложение — то без валидации на сервере вам не обеспечить защиту от пиратства. И хотя можно просто валидировать цифровую подпись покупки на сервере, у запроса на Android Publisher API метода есть некоторые дополнительные возможности. Во-первых, вы можете получить информацию о покупке или подписке в любое время без привязки к устройству пользователя, а, во-вторых, вы можете получить более детальную информацию о подписках и управлять ими (отменять, откладывать и т. п.). К примеру, если вы хотите отобразить дату следующего платежа как в Google Play Music:
То вы можете получить ее только запросом на Android Publisher API.
Полный flow при интеграции биллинга таков:
1. Регистрация приложения в консоли Google Play и создание списка покупок.
2. Интеграция Android in-app billing в мобильном приложении.
3. Валидация покупок и подписок на сервере.
Часть 1: Регистрация приложения в консоли Google Play и создание списка покупок
1. Есть ваше приложение не было ранее загружено — подпишите ваше приложение вашим release-сертификатом и загрузите его в закрытое альфа-или бета тестирование.
All Applications / Ваше Приложение / APK / Alpha(Beta) Testing
2. Создайте список тестирования и активируйте его для выбранного вами (Alpha или Beta) типа тестирования.
3. Добавьте в этот список email-ы Google-аккаунтов, которые будет тестировать биллинг. Например, ваш личный email, с помощью которого вы вошли в Google Play на своем устройстве.
Внизу будет ссылка Opt-in URL: по этой ссылке нужно перейти всем пользователям, которые будут тестировать биллинг (и самому тоже), и согласиться на тестирование. Без этого вы не сможете совершать покупки в альфа/бета версии.
4. Перейдите во вкладку Settings / Account Details, найдите раздел LICENSE TESTING и в поле Gmail accounts with testing access добавьте те же email-ы, что и в прошлом шаге. Теперь с этих аккаунтов вы можете тестировать покупки — за них не будет взыматься плата.
Добавить метод оплаты все же придется — сам диалог покупки потребует этого, однако когда вы непострудственно увидите кнопку купить в приложении — будет указано, что это тестовая покупка.
5. Добавьте тестовые покупки в ваше приложение. Для этого пройдите в All Applications / Ваше Приложение / In-app Products и нажмите Add new product. Можете добавить одну покупку (Managed product) и одну подписку (Subscription). В качестве product id можно использовать что-то в стиле com.example.myapp_testing_inapp1 и com.example.myapp_testing_subs1 для покупки и подписки соответственно Нужно как минимум добавить название и описание, установить цену для продукта, выбрать страны, где он доступен (можете выбрать все), для подписки также выбрать период, и активировать продукт. После этого он станет доступен через некоторое время.
ВАЖНО: вы должны опубликовать приложение (как минимум в alpha/beta), иначе покупки работать не будут.
Коротко о типах покупок
1. Managed product (inapp) — одноразовая покупка. После покупки пользователем становится владельцем покупки навсегда, но также такая покупка может быть «использована» (consume) — например, для начисления каких то бонусов. После использования покупка исчезает и ее можно совершить еще раз.
2. Subscription (subs) — подписка. После активации у пользователя снимается определенная сумма раз в определенный период. Пока пользователь платит — подписка активна.
Когда наши покупки будут активированы — мы сможем получить информацию о них непосредственно в мобильном приложении (название, описание, цена в локальной валюте) а также совершить покупку.
Часть 2: Интеграция Android in-app billing в мобильном приложении
Для начала выполним некоторые манипуляции, чтобы работать с биллинг-сервисом в нашем приложении.
Скопируем файлик IInAppBillingService.aidl в наш проект:
IInAppBillingService.aidl это файл Android Interface Definition Language (AIDL), который определяет интерфейс взаимодействия с сервисом In-app Billing Version 3. Вы будете использовать этот интерфейс для выполнения биллинг-запросов с помощью IPC-вызовов.
Чтобы получить файл AIDL:
Откройте Android SDK Manager.
В SDK Manager найдите и раскройте секцию Extras.
Выберите Google Play Billing Library.
Нажмите Install packages чтобы выполнить установку.
Перейдите в папку src/main вашего проекта и создайте папку с именем aidl.
Внутри этот папки создайте пакет com.android.vending.billing.
Скопируйте файл IInAppBillingService.aidl из папки %anroid-sdk%/extras/google/play_billing/ в только что созданный пакет src/main/aidl/com.android.vending.billing
Добавим разрешение в манифест:
И в месте, где мы собираемся совершать покупки, подключимся к сервису:
Теперь можно приступать к работе с покупками. Получим список наших покупок из сервиса с описанием и ценами:
С помощью этого метода мы можем загрузить данные о доступных покупках.
Теперь мы можем прямо из приложения получить список покупок и информацию про них. Цена будет указана в той валюте, в которой пользователь будет платить. Эти методы надо вызывать в фоновом потоке, так как сервис в процессе может загружать данные с серверов Google. Как использовать эти данные — на ваше усмотрение. Вы можете отобразить цены и названия продуктов из полученного списка, а можете названия и цены указать в ресурсах приложения.
Самое время теперь что-то купить!
Отдельно хочется сказать про dataSignature. Пример ее проверки есть тут, но если ваша покупка валидируется на сервере — то это лишний шаг.
Также может быть полезной возможность получить информацию о уже совершенных покупках:
Это тоже нужно выполнять из фонового потока. Здесь вернется список покупок, которые мы совершили ранее. Также можно получить и список активных подписок.
Следующий шаг — использование покупки. Имеется в виду, что вы начисляете пользователю что-то за покупку, а сама покупка пропадает, давая таким возможность совершить покупку еще раз.
После этого вы уже не сможете прочитать данные о покупке — она будет недоступна через getPurchases().
Здесь наши возможности по использованию биллинга непосредственно на устройстве заканчиваются.
Часть 3: Валидация покупок и подписок на сервере
Это самая интересная часть, над которой я бился дольше всего. Все примеры будут на java, для которой Google предоставляет готовую библиотеку для работы со своими сервисами.
Библиотеки и для других языков можно поискать здесь. Документация по Google Publisher API находится тут, в контексте текущей задачи нас интересуют Purchases.products и Purchases.subscriptions.
По сути, главная проблема, с которой я столкнулся, это описание способа авторизации. Даже по самому описанию он выглядит как пятая нога у коня, но проблема не в том, что он не работает, а в том, что он в корне не верный для нашей задачи. Просьба к знатокам не кидаться в меня камнями: OAuth предназначен для работы с ресурсами клиента, в нашем же случае backend-сервис обращается за данными биллинга нашего собственного приложения.
И вот тут нам на помощь приходит IAM (Identy Access Management). Нам нужно создать проект в Google Cloud Console и зайти во вкладку Credentials, выбрать Create credentials → Service account key.
Заполните данные так, как показано на картинке:
Service account: New service account
Service account name: имя на выбор
Role: не выбирайте, она сейчас не нужна
Key type: JSON
Нажимаете Create. Вылезет окошко с предупреждением Service account has no role. Соглашается, выбираем CREATE WITHOUT ROLE. Вам автоматически загрузится JSON-файл с данными для авторизации аккаунта. Сохраните этот файл — в будущем он понадобится для того, чтобы авторизоваться на Google-сервисах.
Теперь возвращаемся на вкладку Credentials нашего проекта и видим внизу список Service account keys. Справа кнопка Manage service accounts — нажимаем на нее и видим:
myaccount@project-name.iam.gserviceaccount.com — это и есть id нашего аккаунта. Копируем его и идем в Google Play Developer Console → Settings → User Accounts & Rights и выбираем Invite new user.
Вставляем id аккаунта в поле Email, добавляем наше прилождение и ставим галочку напротив View financial reports.
Нажимаем Send Invitation. Теперь мы можем использовать наш JSON-файл для авторизации и Google API и доступа к данным покупок и подписок нашего приложения.
Следующий шаг — нужно активировать Google Play Developer API для нашего проекта. Идем в Google Developer Console → Library и ищем Google Play Developer API. Открываем его и нажимаем Enable.
Последний шаг настройки — идем в Google Play Developer Console → Settings → API Access.
В списке находим наш проект (на картинке выше это Google Play Android Developer, но там должно быть имя вашего проекта) и нажимаем Link.
Теперь перейдем к разработке серверной части
Как вы будете хранить JSON-файл с приватными данными IAM-аккаунта оставим на ваше усмотрение. Импортируйте Google Play Developer API в ваш проект (mavencentral) и реализуем проверку.
Данные о покупке нужно отправить с нашего приложения на сервер. Сама реализация проверки на сервере выглядит вот так:
Таким образом мы получаем возможность получить данные о нашей покупке непосредственно от Google, потому пропадает необходимость в проверке подписи. Более того, для подписок вы можете получить намного больше информации, чем непосредственно через IInAppBilligService в мобильном приложении.
В качестве параметров запроса нам нужны:
Детали по ProductPurchase и SubscriptionPurchase описаны в документации, не будем на них останавливаться.
Вместо заключения
Сначала казавшаяся простой задача по интеграции биллинга в наш сервис превратилась в путешествие через документацию, гуглинг и бессилие (OAuth, ты прекрасен), так как про использование IAM для целей доступа в документации ни слова. Серьезно, они предлагают вбить руками какой-то руками состряпанный URL в вашем браузере, добавить origin для редиректа в консоли управления проектом, и все это для того, чтобы получить одноразовый токен, который надо руками передать на сервер, после чего использовать весь флоу OAuth для получения доступа к данным биллинга. Это не говоря о том, что если вы не успеете использовать refresh-token, то вам придется получать новый токен — руками. Согласитесь — это звучит как полный бред для backend-сервиса, который должен работать без вмешательства человека.
Я надеюсь, что этой статьей помогу кому-то сэкономить немного времени и нервов.
Comments
TiagoGouvea commented Oct 17, 2019
Version of react-native-iap
Version of react-native
Platforms you faced the error (IOS or Android or both?)
Expected behavior
Connection init should start the connection, to get products, and after that be able to purchase.
Actual behavior
On initConnection catch I got:
It’s happend on production app with this device:
I was wondering how could it be related to «Google Play In-app Billing API version is less than 3», since the native link was done by the RNIAP.
Tested environment (Emulator? Real Device?)
Steps to reproduce the behavior
The user want to purchase, but on initConnection it fails.
The text was updated successfully, but these errors were encountered:
hyochan commented Oct 17, 2019
Looks like this is expected as described. I am not sure tough. Would we have to alert the user to upgrade their play store?
TiagoGouvea commented Oct 17, 2019
It should be the right thing to do, alert the user to upgrade their play store.
Because, on the user journey, that exception will avoid him to make a purchase. And just say «connection failed» as feedback, will not be the real case, will not be resolved later.
I’m checking with the user directly his Google Play version and will tell you more details when I have.
TiagoGouvea commented Oct 17, 2019 •
Another relevant question is that.
The user has two accounts on his phone, both identified as Brazilian accounts (country available to buy the products).
hannojg commented Oct 18, 2019 •
Hey! Google announced that they will quit support for the AIDL/Billing Library Version 1 and 2 and that one needs to upgrade to Version 3 until the beginning of December. Not sure if this is related, as I also don’t know which version of the AIDL/Billing Library this library uses internally.
Edit: It uses 2.0.3, so I guess this should be upgraded? @hyochan
Sorry, was related to Google Play Developer API, not BIlling Library version! Misread the announcement.
hyochan commented Oct 26, 2019
The user has two accounts on his phone, both identified as Brazilian accounts (country available to buy the products).
A user could be using an old android phone. Could you check the user’s Android version?
Покупки в Android приложении — Play Billing Library
И как это до сих пор на Хабре нет статьи об этом? Не дело, надо исправлять.
Есть 2 способа добавить In-App покупки в Android-приложение — старый и новый. До 2017 года все пользовались библиотекой от anjlab, но с июня 2017 года ситуация изменилась, Google выпустила собственную библиотеку для внутренних покупок и подписок — Play Billing Library. Сейчас последний считается стандартом.
Play Billing Library это очень просто.
Добавьте разрешение в манифесте.
Создайте инстанс BillingClient и начните соединение.
В метод onPurchasesUpdated() мы попадаем когда покупка осуществлена, в методе onBillingSetupFinished() можно запросить информацию о товарах и покупках.
Запросить информацию о товарах. Поместите querySkuDetails() в onBillingSetupFinished().
В коде вы могли заметить понятие SKU, что это? SKU — от английского Stock Keeping Unit (идентификатор товарной позиции).
Теперь в mSkuDetailsMap у нас лежит вся информация о товарах (имя, описание, цена), зарегистрированных в Play Console данного приложения (об этом позже). Обратите внимание на эту строку skuList.add(mSkuId);, здесь мы добавили id товара из Play Console, перечислите здесь все товары, с которыми вы хотите взаимодействовать. У нас товар один —sku_id_1.
Все готово к тому, чтобы выполнить запрос на покупку. Передаем id товара. Запустите этот метод, например, по клику на кнопку.
Теперь, запустив этот метод, вы увидите вот такое диалоговое окно (прим. картинки из Интернета).
Теперь если пользователь купит товар — его ему надо предоставить. Добавьте метод payComplete() и осуществите в нем действия, предоставляющие доступ к купленному товару. Например, если пользователь покупал отключение рекламы, сделайте в этом методе так, чтобы реклама больше не показывалась.
Все хорошо, но если пользователь перезапустит приложение, наша программа ничего не знает о покупках. Надо запросить информацию о них. Сделайте это в onBillingSetupFinished().
В purchasesList попадает список всех покупок, сделанных пользователем.
Делаем проверку: если товар куплен — выполнить payComplete().
Готово. Осталось это приложение опубликовать в Play Console и добавить товары. Как добавить товар: Описание страницы приложения > Контент для продажи > Создать ограниченный контент.
Примечание 1: Вы не сможете добавить товар пока не загрузите билд приложения в Play Console.
Примечание 2: Чтобы увидеть диалоговое окно о покупке, вам надо загрузить билд в Play Console, добавить товар и подождать какое-то время (
30 минут — 1 час — 3 часа), пока товар обновится, только после этого появится диалоговое окно и можно будет осуществить покупку.
Примечание 3: Ошибка Please fix the input params. SKU can’t be null — товар в Play Console еще не успел обновиться, подождите.
Примечание 4: Вы можете столкнуться с ошибкой Error «Your transaction cannot be completed», в логах как response code 6 пока будете тестировать. По каким причинам это происходит мне точно неизвестно, но по моим наблюдениям это происходит после частых манипуляций с покупкой и возвратом товара. Чтобы это починить перейдите в меню банковских карт и передобавьте вашу карту. Как этого избежать? Добавьте ваш аккаунт в Play Console в качестве тестировщика и покупайте только с тестовой карточки.
(Кстати, на Хабре работает система донейтов по кнопке под статьёй — прим. модератора).
Обзор Google Play Billing 4.0.0
Всем привет. Я SDK Engineer в Qonversion Мария Бордунова.
Сегодня речь пойдет о библиотеке Google Play Billing Library 4.0.0, которая к концу этого года должна открыть новые возможности для приложений со встроенными покупками.
Согласно анонсу Google, четвертая версия Billing Library позволит оптимизировать покупки внутри приложений:
Появится возможность приобретать несколько расходуемых (consumable) in-app продуктов единовременно. На данный момент можно покупать только 1 единицу продукта за раз.
Пользователь сможет сам определять состав подписки, то есть приобрести несколько продуктов как часть одной подписки.
Подробнее о типах продуктов для продажи внутри приложения можно почитать здесь.
Так как еще не все перешли на Billing Library v4, я бы хотела рассказать, на что стоит обратить внимание при миграции на новую версию.
Основные изменения в 4-й версии Google Play Billing Library
1. Background & Main: фоновый и главный потоки
Теперь callback-и методов вызываются в фоновом потоке (в предыдущей версии они вызывались из главного). Чтобы убедиться в этом, можно вывести в лог название текущего потока, например, в методе onBillingSetupFinished интерфейса BillingClientStateListener :
В логах можно будет увидеть следующий результат для разных версий библиотеки:
Billing Library v4: D/TestThread: PlayBillingLibrary-1 thread is running.
Billing Library v3: D/TestThread: Main thread is running.
Если требуется изменить пользовательский интерфейс прямо из callback-а, важно помнить, что взаимодействие с UI невозможно без переключения обратно в главный поток.
2. queryPurchasesAsync() для извлечения активных покупок пользователя
Метод queryPurchases() больше не актуален. Теперь, чтобы получить информацию об активных подписках и нерасходуемых покупках (они же non-consumable) в приложении, нужно использовать метод queryPurchasesAsync():
Чтобы получить ответ, необходимо реализовать интерфейс PurchasesResponseListener и переопределить его метод onQueryPurchasesResponse:
3. Новый способ для downgrade/upgrade подписок
Раньше для обновления подписки необходимо было предоставить значение SkuDetails, sku (он же идентификатор) и токен старой подписки, а также опционально ProrationMode:
Теперь для выполнения downgrade или upgrade подписки нужно вызвать BillingFlowParams.Builder.setSubscriptionUpdateParams() и передать объект SubscriptionUpdateParams в качестве параметра. Метод setOldSku() был удален.
4. Multi-quantity purchases (пока недоступны, ждем релиза)
Google анонсировал планы по оптимизации покупок внутри приложения: пользователям будет доступен выбор нужного количества продуктов прямо из корзины. Из Google Play Console можно будет настроить, какой именно продукт доступен для такой опции.
Это сильно упрощает процессы покупки и продажи. Теперь пользователи смогут купить несколько единиц расходуемого продукта (они же consumable in-app продукты, например, монетки, мана) в один клик, а не покупать их многократно разными транзакциями.
Чтобы получить количество купленного продукта, можно использовать новые методы Purchase.getQuantity() и PurchaseHistoryRecord.getQuantity().
5. Multi-line subscriptions (пока недоступны, ждем релиза)
В дополнение к предыдущей фиче, Google позволит продавать несколько продуктов в рамках одной подписки. Пользователи смогут управлять составом такой подписки в любое время (добавлять, отменять и заменять продукты при оформлении подписки или в процессе ее использования).
Например, пользователь сможет купить курс по изучению Java, Kotlin, а потом дополнить этот набор Swift.
Чтобы получить идентификаторы продуктов покупки, используйте методы Purchase.getSkus() и PurchaseHistoryRecord.getSkus() (метод getSku() более недоступен).
Что в итоге?
Конечно, Google Play Billing Library 4.0.0 здорово оптимизирует процессы покупок внутри приложения. Если говорить о технических деталях, то новшества на мобильной стороне могут показаться не фундаментальными. Но нужно учитывать и изменения на сервере. Например, если вы собираете аналитику по покупкам, в запросе purchase появится новое поле “quantity”; в поле для идентификатора продукта теперь может передаваться массив ids. Также выглядит, что количество запросов на ваш сервер хоть и на малую долю, но уменьшится за счет единовременных покупок. Почитать о прочих изменениях в библиотеке можно в release notes.
Кто уже перешел на Google billing 4.0.0? Какие сложности вы заметили при переходе или использовании? Будет интересно обсудить.
Каковы возможности получить этот код ошибки 3 в покупке InApp?
Я использую код InApp V3 для покупок в приложении в моем приложении, я получаю эту ошибку BILLING_RESPONSE_RESULT_BILLING_UNAVAILABLE и error value :3 когда учетная запись Google недоступна на устройстве. Я хочу знать, есть ли другие возможности для получения этой ошибки, потому что, когда я получаю эту ошибку, мне нужно показать всплывающее окно пользователю с некоторыми данными. Если это вызвано из-за недоступности учетной записи Google на устройстве, я покажу диалог с соответствующим текстом. Это код, который я использую
Это ошибка Error checking for billing v3 support. (response: 3:Billing Unavailable) Error checking for billing v3 support. (response: 3:Billing Unavailable)
Как мы можем видеть непосредственно в коде установки IabHElper образца, предоставленного google, ошибка означает:
«Служба биллинга недоступна на устройстве».
Как вы можете здесь прочитать, что ошибка означает
Это Справочник биллинга In-app (IAB Version 3), поэтому ошибка означает, что IAB v3 не установлен на устройстве.
Фактически это означает, что у пользователя есть учетная запись google и, возможно, также служба выставления счетов в приложении, но у нее нет последней версии. Это происходит в старых устройствах, и когда пользователь никогда ничего не обновляет, он используется для устройств, где вы можете увидеть старое приложение Market вместо приложения Play.
Таким образом, ошибка, которую вы должны показать пользователю, и тест, который вы должны выполнить, заключается не в том, что у устройства есть учетная запись google, но если у него установлены и правильно обновлены сервисы игры google.
Если вы ищете код во всем SDK библиотеки и вспомогательные классы, предоставляемые google, это единственное место, где мы можем найти именно то, что именно вы вызываете: IabHelper класса IabHelper
Таким образом, ваша ошибка может означать только одно из этого, что для вас означает, что вы должны показать пользователю mesagge, например: «У вас нет установленных служб google play, или вам нужно их обновить». И нет других возможностей или получить эту ошибку.
Эта ошибка также принимается после того, как пользователь удалит свою учетную запись google с устройства.
В основном возможность вашей проблемы BILLING_RESPONSE_RESULT_BILLING_UNAVAILABLE заключается в том, что в некоторых странах все еще в App Purchase не разрешено, как в Сербии и во многих странах.
Это будет меньше шансов, что у пользователя не будет обновлена Служба Google Play, установленная на телефоне, поэтому не беспокойтесь об этом случае.
Попробуйте эти хаки
Удалите кеш, данные и обновления для приложения для воспроизведения, снова запустите приложение для воспроизведения, оно должно работать! Или попробуйте с последними обновлениями (если он исправлен)
Просто имейте в виду:
IABv3 встроен в сервисы Google Play, поэтому для обновления App Play требуется обновление.
V2 был встроен в клиент Play Store. Проблема кеша / EULA не связана конкретно с IAB, это связано с настройкой Play Services (и, надеюсь, для большинства пользователей это необязательно, часть кэша в любом случае).
В этот переходный период, когда Play Services нужно обновить, нужно обновить систему, чтобы приложение могло ее использовать, но я думаю, что большинство людей согласятся с тем, что это лучше, чем ждать обновления ОС ».
См. Этот отчет : сообщение об ошибке, сообщение G +
Если вы не аутентифицировали свое устройство с помощью учетной записи Google, может возникнуть эта ошибка.
Для тех, кто все еще сталкивается с этой проблемой, в большинстве случаев iab не поддерживается в вашей стране, как сказал Уильямс. Вы можете использовать VPN, чтобы он работал.