Ошибка инициализации биллинга на телефоне андроид что делать

Иногда люди сталкиваются с ошибкой инициализации биллинга, не до конца понимая, что это за ошибка и как её решить. Чтобы в этом разобраться для начала необходимо понять, что же такое биллинг.

Что такое биллинг?

Биллинг – (от английского «bill» — счёт) это специальная система, выставляющая различные счета клиентам. Данные счета выставляются за использование каких-либо услуг компании или же за покупку товаров. В наше время биллинг в компаниях является крайне сложным комплексом технологий и программ, которые помогают вести учёт всех предоставленных услуг, устанавливать определённые тарифы и, в конечном итоге, отправлять клиентам счета, учитывая все акции и скидки.

В сотовой связи биллинг работает в реальном времени. То есть со счёта клиента денежные средства списываются моментально. За это клиент сразу же получает необходимые ему услуги (например, Интернет-трафик, SMS и др.). Чтобы работать в таком режиме, система должна быть очень надёжной, а стабильность работы не должна прерываться ни на секунду.

Ошибки инициализации биллинга

При покупке различного рода услуг у операторов связи (телекоммуникации) и даже при покупке различного контента в Интернете может возникнуть ошибка биллинга. Такие ошибки при выставлении счёта не дают возможность приобрести необходимые человеку услуги или товары, однако есть несколько способов для исправления этой ошибки.

Совершить покупку в другое время

Ошибка биллинга может появиться по разным причинам. Если человек сделал много запросов на приобретение товара или услуг, которые были отклонены, то скорее всего возникнет данная ошибка. К тому же, банковская карта, с которой должна производиться оплата может быть помечена как «Подозрительный способ оплаты». Также необходимо внимательно посмотреть, какой регион указан при покупке. Если регион указан неверно, то скорее всего появится ошибка биллинга.

В таких случаях клиенту необходимо подождать 1-2 суток и попытаться совершить покупку снова. Чаще всего достаточно подождать 24 часа, после чего совершение покупки не составит проблем.

Проверить правильность платёжной информации

Возможно ошибка возникает из-за неправильной платёжной информации клиента. Ему необходимо тщательно проверить все данные, которые он указывал. Это может быть регион, способ оплаты, банковская карта и другие данные. Из-за неправильно указанных данных система не может выставить счёт, выдавая такие ошибки биллинга.

Очистка кэша и изменение личных данных

Накопленный кэш зачастую является проблемой некорректной работы. Чтобы исправить это, достаточно просто удалить весь кэш с устройства. Если неполадки не устранились, то можно попробовать удалить личные данные и ввести их заново. Для обновления информации в системе может потребоваться от 3 до 48 часов. После этого можно заново проводить платёжные операции.

10 ответов

I am experiencing the same thing on 10.0.44.

What happens

We have a StoreActivity that creates a new BillingProcessor via constructor e.g.

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_store);
        // ...
        bp = new BillingProcessor(this, LICENSE_KEY, MERCHANT_ID, new BillingProcessor.IBillingHandler() {//...}

I stepped through the code and onBillingInitialized is triggered shorty after this constructor executes and the following code starts to run:

    public void handleBpResult() {
        if (bp.isInitialized()) {
            showView(mContent);

            // set up price text
            SkuDetails adFree = bp.getPurchaseListingDetails(Constants.SKU_PREMIUM);

As soon as bp.getPurchaseListingDetails(Constants.SKU_PREMIUM); is called the onBillingError callback is triggered and the infinite loop begins.

I checked and int errorCode for the callback is 6 and Throwable error is null. Case 6 in the switch for us is just a break which then starts the same handleBpResult function as above eventually running into bp.getPurchaseListingDetails(Constants.SKU_PREMIUM); and thus the cycle continues eventually crashing the app.

If I remove all billing processor related code from onBillingError then at least the infinite cycle is fixed but the errorCode 6 error will just appear later e.g. when the use attempts to purchase a store item.

Safety improvement

From a quick scan of the source getPurchaseListingDetails ends up calling getSkuDetails which interacts directly with the google inappbillingservice service. Thus calling anything that interacts with android billing like getPurchaseListingDetails inside the onBillingError could risk an infinite loop.

For our case the workaround is to use isPurchased which is a cache hit instead of interacting with the service and risking the loop. This is likely more efficient as well.

How to reproduce error code 6

Not sure. I have a device stuck in this state for any InAppBillingService related apps.

Blu Advance 5
Android 5.1

From settings>accounts I have a google account listed with sync off and when I click into the account for more details it says «Sync is currently experiencing problems. It will be back shortly»

Suggestions for improvement?

If possible getPurchaseListingDetails and getSubscriptionListingDetails could maybe be cache hits as well? From their function names it is not immediately obvious that they access billing service and they don’t appear to be used internally to build the cache.

From a quick glance, there doesn’t appear to be any public way to access purchase details from the cache even though the cache stores a map of ProductId->PurchaseInfo

I am experiencing the same thing on 10.0.44.

What happens

We have a StoreActivity that creates a new BillingProcessor via constructor e.g.

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_store);
        // ...
        bp = new BillingProcessor(this, LICENSE_KEY, MERCHANT_ID, new BillingProcessor.IBillingHandler() {//...}

I stepped through the code and onBillingInitialized is triggered shorty after this constructor executes and the following code starts to run:

    public void handleBpResult() {
        if (bp.isInitialized()) {
            showView(mContent);

            // set up price text
            SkuDetails adFree = bp.getPurchaseListingDetails(Constants.SKU_PREMIUM);

As soon as bp.getPurchaseListingDetails(Constants.SKU_PREMIUM); is called the onBillingError callback is triggered and the infinite loop begins.

I checked and int errorCode for the callback is 6 and Throwable error is null. Case 6 in the switch for us is just a break which then starts the same handleBpResult function as above eventually running into bp.getPurchaseListingDetails(Constants.SKU_PREMIUM); and thus the cycle continues eventually crashing the app.

If I remove all billing processor related code from onBillingError then at least the infinite cycle is fixed but the errorCode 6 error will just appear later e.g. when the use attempts to purchase a store item.

Safety improvement

From a quick scan of the source getPurchaseListingDetails ends up calling getSkuDetails which interacts directly with the google inappbillingservice service. Thus calling anything that interacts with android billing like getPurchaseListingDetails inside the onBillingError could risk an infinite loop.

For our case the workaround is to use isPurchased which is a cache hit instead of interacting with the service and risking the loop. This is likely more efficient as well.

How to reproduce error code 6

Not sure. I have a device stuck in this state for any InAppBillingService related apps.

Blu Advance 5
Android 5.1

From settings>accounts I have a google account listed with sync off and when I click into the account for more details it says «Sync is currently experiencing problems. It will be back shortly»

Suggestions for improvement?

If possible getPurchaseListingDetails and getSubscriptionListingDetails could maybe be cache hits as well? From their function names it is not immediately obvious that they access billing service and they don’t appear to be used internally to build the cache.

From a quick glance, there doesn’t appear to be any public way to access purchase details from the cache even though the cache stores a map of ProductId->PurchaseInfo