Skip to content

BC 8 issue on Android has been fixed in 9.16.0 #1314

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
GuilhermeMota93 merged 2 commits into from
Jan 12, 2026
Merged

BC 8 issue on Android has been fixed in 9.16.0 #1314

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
01a530d
added info on both pages referencing the BC 8 client issue on Android…
GuilhermeMota93 Jan 9, 2026
98432a9
Added table with hybrid versioning
GuilhermeMota93 Jan 12, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
48 changes: 36 additions & 12 deletions docs/getting-started/restoring-purchases.mdx
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -60,38 +60,59 @@ Consumables and non-renewing subscriptions can only be restored by using an acco

By logging in your users with a custom App User ID, RevenueCat can continue to provide transaction details in a user's [CustomerInfo](/customers/customer-info) for their previous consumable and non-renewing subscription purchases.

## Issues restoring one-time purchases with Google's Billing Client 8 when using anonymous users
## [SOLVED] Issues restoring one-time purchases with Google's Billing Client 8 when using anonymous users

:::info[Android Fix Available (9.16.0+)]
As of [purchases-android 9.16.0](https://github.com/RevenueCat/purchases-android/releases/tag/9.16.0), the Android SDK includes a fix for the Billing Client 8 limitation described below. If you're using purchases-android 9.0.0-9.15.x, upgrading to 9.16.0 or later is strongly recommended.

For cross-platform SDKs (React Native, Flutter, etc.), ensure you're using a version that includes purchases-android 9.16.0+.
Copy link
Contributor

@tonidero tonidero Jan 11, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could be worth adding a table for what specific versions the fix is included on in the hybrids.

Copy link
Contributor Author

@GuilhermeMota93 GuilhermeMota93 Jan 12, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done now!

:::

### Minimum Versions with Fix

| RevenueCat SDK | Minimum Version with Fix |
| :--------------------- | :----------------------- |
| purchases-android | 9.16.0 |
| react-native-purchases | 9.6.12 |
| purchases-flutter | 9.10.2 |
| purchases-unity | 8.4.12 |
| purchases-capacitor | 11.3.2 |
| purchases-kmp | 2.2.15+17.25.0 |

Starting on Billing Client 8, Google removed the ability to query consumed one-time purchases through Google's Billing Client library. This means that our SDKs using that version of Billing Client won't be able to restore these purchases. This affects the following versions:

| RevenueCat SDK | Version using Billing Client 8+ |
| :----------------------- | :--------------------------------------------- |
| purchases-android | 9.0.0 and up |
| react-native-purchases | 9.0.0 and up |
| purchases-flutter | 9.0.0 and up |
| cordova-plugin-purchases | 7.0.0 and up |
| purchases-unity | 8.0.0 and up |
| purchases-capacitor | 11.0.0 and up |
| purchases-kmp | 2.0.0 and up |
| RevenueCat SDK | Version using Billing Client 8+ |
| :----------------------- | :------------------------------ |
| purchases-android | 9.0.0 and up |
| react-native-purchases | 9.0.0 and up |
| purchases-flutter | 9.0.0 and up |
| cordova-plugin-purchases | 7.0.0 and up |
| purchases-unity | 8.0.0 and up |
| purchases-capacitor | 11.0.0 and up |
| purchases-kmp | 2.0.0 and up |

This can be problematic if both:

- Your app DOESN'T offer an account system (so users can't log in to recover their purchases) and you rely on RevenueCat's anonymous users AND
- Your app has or had at any point in time used one-time products that were consumed. RevenueCat automatically consumes purchases for products that are configured as consumables in the RevenueCat dashboard.

In this scenario, these users will have anonymous user ids that won't be easily recoverable and won't be able to recover their purchases through the Billing Client, so those purchases can not be recovered.

One way to reduce the impact of this issue is by making sure RevenueCat's data is safely backed up in the user's Google account, so it is automatically restored when the user reinstalls the app and/or changes devices. RevenueCat stores data in its own SharedPreferences file. The exact name of that file is available as the constant `RevenueCatBackupAgent.REVENUECAT_PREFS_FILE_NAME`, which you can reference when setting up backups. We recommend you also include your app's default SharedPreferences file.
One way to reduce the impact of this issue is by making sure RevenueCat's data is safely backed up in the user's Google account, so it is automatically restored when the user reinstalls the app and/or changes devices. RevenueCat stores data in its own SharedPreferences file. The exact name of that file is available as the constant `RevenueCatBackupAgent.REVENUECAT_PREFS_FILE_NAME`, which you can reference when setting up backups. We recommend you also include your app's default SharedPreferences file.

There are 2 recommended approaches Google offers to perform backups:

- [Auto Backup](https://developer.android.com/identity/data/autobackup)
- [Key-value backups](https://developer.android.com/identity/data/keyvaluebackup).
- [Key-value backups](https://developer.android.com/identity/data/keyvaluebackup).

#### Auto Backup

Auto Backup is enabled by default in your app. This backs up most of your app content, including the RevenueCat SharedPreferences file, up to a 25MB limit, at which point, it stops doing backups. You can configure what you want to backup following [the official documentation](https://developer.android.com/identity/data/autobackup#IncludingFiles).

We recommend adjusting the files you want to back up to make sure you don't go over the limit and making sure the RevenueCat SharedPreferences file is included.

#### Key-Value backups

Please note that enabling this will disable Auto backup and will just back up RevenueCat files!

If you prefer to disable auto-backup and just back up the RevenueCat SharedPreferences file, you may optionally use our provided `RevenueCatBackupAgent` to perform a backup of the relevant files. To do this, you need to add to your app's `AndroidManifest.xml` `<application>` node a property like this:
Expand All @@ -101,7 +122,9 @@ android:backupAgent="com.revenuecat.purchases.backup.RevenueCatBackupAgent"
```

### What should you do?

For the majority of apps, Auto Backup is enabled by default and should handle backups for you without doing anything. However, there are some situations where it won't:

- If your app has the potential of having more than 25MB of data over the files that Auto Backup automatically backs up (See [docs](https://developer.android.com/identity/data/autobackup#Files))
- If you have modified the files you would like to backup using Auto Backup and have not included RevenueCat's SharedPreferences file.
- If you have disabled backups
Expand All @@ -111,6 +134,7 @@ If you are in one of those positions, we recommend you make sure your backup con
Both options are powered by similar Google backup mechanisms and either should work pretty similarly, so we recommend using Auto Backup unless there is a reason you prefer to use a Backup Agent.

### How to test backups

Whether you're using Auto Backup or Key-Value backups, Google provides some documentation on how to test backups and restores [in their documentation](https://developer.android.com/identity/data/testingbackup).

One thing to note, however, is that these backups are not guaranteed to work across all devices and might require factory resets in the target device to use the backup.
Expand Down
44 changes: 32 additions & 12 deletions docs/known-store-issues/play-billing-library/restore-consumable-purchases-bc8.mdx
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,21 +1,40 @@
---
title: Restoring consumable purchases won't work in Google's Billing Client 8
sidebar_label: Restoring consumables Billing Client 8
title: "[SOLVED] Restoring consumable purchases won't work in Google's Billing Client 8"
sidebar_label: "[SOLVED] Restoring consumables BC8"
---

## Resolved

As of [purchases-android 9.16.0](https://github.com/RevenueCat/purchases-android/releases/tag/9.16.0), this issue has been resolved for the Android SDK. We've added support for querying consumed one-time purchases using Google Play's AIDL service interface, which works around the Billing Client 8 limitation.

:::info Upgrade Recommendation
**If you're using purchases-android 9.0.0-9.15.x**, we strongly recommend upgrading to 9.16.0 or later to benefit from this fix.
:::

### Minimum Versions with Fix

| RevenueCat SDK | Minimum Version with Fix |
| :--------------------- | :----------------------- |
| purchases-android | 9.16.0 |
| react-native-purchases | 9.6.12 |
| purchases-flutter | 9.10.2 |
| purchases-unity | 8.4.12 |
| purchases-capacitor | 11.3.2 |
| purchases-kmp | 2.2.15+17.25.0 |

## Issue Description

Starting on Billing Client 8, Google removed the ability to query consumed one-time purchases through Google's Billing Client library. This means that our SDKs using that version of Billing Client won't be able to restore these purchases. This affects the following versions:

| RevenueCat SDK | Version using Billing Client 8+ |
| :----------------------- | :--------------------------------------------- |
| purchases-android | 9.0.0 and up |
| react-native-purchases | 9.0.0 and up |
| purchases-flutter | 9.0.0 and up |
| cordova-plugin-purchases | 7.0.0 and up |
| purchases-unity | 8.0.0 and up |
| purchases-capacitor | 11.0.0 and up |
| purchases-kmp | 2.0.0 and up |
| RevenueCat SDK | Version using Billing Client 8+ |
| :----------------------- | :------------------------------ |
| purchases-android | 9.0.0 and up |
| react-native-purchases | 9.0.0 and up |
| purchases-flutter | 9.0.0 and up |
| cordova-plugin-purchases | 7.0.0 and up |
| purchases-unity | 8.0.0 and up |
| purchases-capacitor | 11.0.0 and up |
| purchases-kmp | 2.0.0 and up |

This situation can cause problems if **both** of the following are true:

Expand All @@ -32,9 +51,10 @@ In this scenario, these users will have anonymous user ids that won't be easily
We found there is no good way to recover these purchases with Billing client 8. Currently the only way to lower the number of times users will run into issues restoring purchases is by being able to recover the RevenueCat anonymous user id used in previous installations. In order to do that, we recommend that you make sure you have configured backups correctly for your apps. We have written some documentation on the topic [here](https://www.revenuecat.com/docs/getting-started/restoring-purchases#issues-restoring-one-time-purchases-with-googles-billing-client-8-when-using-anonymous-users).

So right now, for everyone affected by this issue we would recommend to:

- Stay in major 8 of our SDK which uses Billing client 7. We will continue to bring important fixes to the major 8 until Billing client 8 is mandatory next year.
- Make sure backups for your app work and include the RevenueCat Shared Preferences file as mentioned in the [docs](https://www.revenuecat.com/docs/getting-started/restoring-purchases#issues-restoring-one-time-purchases-with-googles-billing-client-8-when-using-anonymous-users)

For users that have a backup performed in this situation and have a device compatible with backups, they would recover the RevenueCat anonymous user id, effectively recovering all their purchases as well.

Note that this solution won't fix all cases, since there are situations and devices where backups won't work. For those, the only solution right now is a manual approach by asking them for proof of purchase to obtain the Order ID of their purchase (Starting in `GPA.....`), then search the user for that orderId in the RevenueCat dashboard, which will allow you to find the user that did that purchase, then, from the RevenueCat dashboard itself, transfer those purchases to the new anonymous user the user is using. So for this manual approach you would need both the Order ID of the purchase and the anonymous user ID that the customer is using.
Note that this solution won't fix all cases, since there are situations and devices where backups won't work. For those, the only solution right now is a manual approach by asking them for proof of purchase to obtain the Order ID of their purchase (Starting in `GPA.....`), then search the user for that orderId in the RevenueCat dashboard, which will allow you to find the user that did that purchase, then, from the RevenueCat dashboard itself, transfer those purchases to the new anonymous user the user is using. So for this manual approach you would need both the Order ID of the purchase and the anonymous user ID that the customer is using.