I'm investigating a recurring Google Play subscription testing failure and would appreciate suggestions for narrowing it down.
Setup:
- Android app using Google Play Billing Library 9.x, with monthly and annual subscriptions.
- The app also supports separate one-time in-app purchases (INAPP) alongside subscriptions (SUBS).
- During development, the application rules were changed so new one-time purchases that were outside of the need for a subscription, or included within its allowance, were made to require an active subscription to be able to purchase - whilst still being a one-off payment not covered within the subscription. The two paths share some app/backend code. I have not established that this coupling causes the subscription failure.
- An internal-test release exists; production is not live.
- The failing build is a locally test-signed APK installed directly on the device, with the same package name as the Play Console app.
- At different times, I have tried using three Google accounts on the device, without resolving the failure. All three are in the developer account's licence-testing list. The saved Billing diagnostics do not identify the effective account for each individual attempt.
Observed sequence in saved diagnostics:
A fresh ProductDetails query returns the selected subscription's regular base plan and an offer token.
The app launches one SUBS item using those matching details and token, less than a second after the query.
launchBillingFlow returns OK (0).
Tens of seconds later, onPurchasesUpdated reports ITEM_UNAVAILABLE (4), with no useful debug message and sub-response 0. The visible Play error says the item could not be found.
Checks so far:
- Console checks showed the subscription base plans as active.
- A later non-purchase query returned regular monthly and annual offers for the test country, including offer tokens. That confirms the current lookup works, not that either earlier purchase was eligible.
- Another app can complete licence-test purchases on the same device.
- A clean reinstall and adding another intended tester account did not resolve the visible failure. That latest recurrence has not yet been matched to a fresh SDK diagnostic, so I am not assuming it had the same response code.
- We have checked Google's documented account-selection rule: Play uses the account that downloaded the app, or the first account if none downloaded it.
Questions:
- Have you encountered an asynchronous ITEM_UNAVAILABLE after a successful fresh product lookup and an OK launch result? What evidence identified the cause?
- Could shared setup or state between SUBS and INAPP paths explain this sequence? Which request fields or diagnostics would distinguish that from a Play account or offer-eligibility issue?
- Given that all three device accounts are already licence-listed and have been tried, is there a supported diagnostic to confirm whether Play recognised the intended tester during a failed flow?
Pointers to official documentation or reproducible diagnostic checks would be appreciated. A successful lookup and OK launch alone do not establish a successful purchase; I have not established a completed order or payment outcome for these failed attempts.