Skip to content

Commit b39a4fb

Browse files
BC 8 issue on Android has been fixed in 9.16.0 (#1314)
* added info on both pages referencing the BC 8 client issue on Android from v9.0.0 * Added table with hybrid versioning
1 parent 86a22b0 commit b39a4fb

File tree

2 files changed

+68
-24
lines changed

2 files changed

+68
-24
lines changed

docs/getting-started/restoring-purchases.mdx

Lines changed: 36 additions & 12 deletions
Original file line numberDiff line numberDiff line change
@@ -60,38 +60,59 @@ Consumables and non-renewing subscriptions can only be restored by using an acco
6060

6161
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.
6262

63-
## Issues restoring one-time purchases with Google's Billing Client 8 when using anonymous users
63+
## [SOLVED] Issues restoring one-time purchases with Google's Billing Client 8 when using anonymous users
64+
65+
:::info[Android Fix Available (9.16.0+)]
66+
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.
67+
68+
For cross-platform SDKs (React Native, Flutter, etc.), ensure you're using a version that includes purchases-android 9.16.0+.
69+
:::
70+
71+
### Minimum Versions with Fix
72+
73+
| RevenueCat SDK | Minimum Version with Fix |
74+
| :--------------------- | :----------------------- |
75+
| purchases-android | 9.16.0 |
76+
| react-native-purchases | 9.6.12 |
77+
| purchases-flutter | 9.10.2 |
78+
| purchases-unity | 8.4.12 |
79+
| purchases-capacitor | 11.3.2 |
80+
| purchases-kmp | 2.2.15+17.25.0 |
6481

6582
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:
6683

67-
| RevenueCat SDK | Version using Billing Client 8+ |
68-
| :----------------------- | :--------------------------------------------- |
69-
| purchases-android | 9.0.0 and up |
70-
| react-native-purchases | 9.0.0 and up |
71-
| purchases-flutter | 9.0.0 and up |
72-
| cordova-plugin-purchases | 7.0.0 and up |
73-
| purchases-unity | 8.0.0 and up |
74-
| purchases-capacitor | 11.0.0 and up |
75-
| purchases-kmp | 2.0.0 and up |
84+
| RevenueCat SDK | Version using Billing Client 8+ |
85+
| :----------------------- | :------------------------------ |
86+
| purchases-android | 9.0.0 and up |
87+
| react-native-purchases | 9.0.0 and up |
88+
| purchases-flutter | 9.0.0 and up |
89+
| cordova-plugin-purchases | 7.0.0 and up |
90+
| purchases-unity | 8.0.0 and up |
91+
| purchases-capacitor | 11.0.0 and up |
92+
| purchases-kmp | 2.0.0 and up |
7693

7794
This can be problematic if both:
95+
7896
- 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
7997
- 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.
8098

8199
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.
82100

83-
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.
101+
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.
84102

85103
There are 2 recommended approaches Google offers to perform backups:
104+
86105
- [Auto Backup](https://developer.android.com/identity/data/autobackup)
87-
- [Key-value backups](https://developer.android.com/identity/data/keyvaluebackup).
106+
- [Key-value backups](https://developer.android.com/identity/data/keyvaluebackup).
88107

89108
#### Auto Backup
109+
90110
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).
91111

92112
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.
93113

94114
#### Key-Value backups
115+
95116
Please note that enabling this will disable Auto backup and will just back up RevenueCat files!
96117

97118
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:
@@ -101,7 +122,9 @@ android:backupAgent="com.revenuecat.purchases.backup.RevenueCatBackupAgent"
101122
```
102123

103124
### What should you do?
125+
104126
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:
127+
105128
- 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))
106129
- If you have modified the files you would like to backup using Auto Backup and have not included RevenueCat's SharedPreferences file.
107130
- If you have disabled backups
@@ -111,6 +134,7 @@ If you are in one of those positions, we recommend you make sure your backup con
111134
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.
112135

113136
### How to test backups
137+
114138
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).
115139

116140
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.
Lines changed: 32 additions & 12 deletions
Original file line numberDiff line numberDiff line change
@@ -1,21 +1,40 @@
11
---
2-
title: Restoring consumable purchases won't work in Google's Billing Client 8
3-
sidebar_label: Restoring consumables Billing Client 8
2+
title: "[SOLVED] Restoring consumable purchases won't work in Google's Billing Client 8"
3+
sidebar_label: "[SOLVED] Restoring consumables BC8"
44
---
55

6+
## Resolved
7+
8+
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.
9+
10+
:::info Upgrade Recommendation
11+
**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.
12+
:::
13+
14+
### Minimum Versions with Fix
15+
16+
| RevenueCat SDK | Minimum Version with Fix |
17+
| :--------------------- | :----------------------- |
18+
| purchases-android | 9.16.0 |
19+
| react-native-purchases | 9.6.12 |
20+
| purchases-flutter | 9.10.2 |
21+
| purchases-unity | 8.4.12 |
22+
| purchases-capacitor | 11.3.2 |
23+
| purchases-kmp | 2.2.15+17.25.0 |
24+
625
## Issue Description
726

827
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:
928

10-
| RevenueCat SDK | Version using Billing Client 8+ |
11-
| :----------------------- | :--------------------------------------------- |
12-
| purchases-android | 9.0.0 and up |
13-
| react-native-purchases | 9.0.0 and up |
14-
| purchases-flutter | 9.0.0 and up |
15-
| cordova-plugin-purchases | 7.0.0 and up |
16-
| purchases-unity | 8.0.0 and up |
17-
| purchases-capacitor | 11.0.0 and up |
18-
| purchases-kmp | 2.0.0 and up |
29+
| RevenueCat SDK | Version using Billing Client 8+ |
30+
| :----------------------- | :------------------------------ |
31+
| purchases-android | 9.0.0 and up |
32+
| react-native-purchases | 9.0.0 and up |
33+
| purchases-flutter | 9.0.0 and up |
34+
| cordova-plugin-purchases | 7.0.0 and up |
35+
| purchases-unity | 8.0.0 and up |
36+
| purchases-capacitor | 11.0.0 and up |
37+
| purchases-kmp | 2.0.0 and up |
1938

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

@@ -32,9 +51,10 @@ In this scenario, these users will have anonymous user ids that won't be easily
3251
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).
3352

3453
So right now, for everyone affected by this issue we would recommend to:
54+
3555
- 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.
3656
- 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)
3757

3858
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.
3959

40-
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.
60+
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.

0 commit comments

Comments
 (0)