RevenueCat

Build With RevenueCat

Build a customized mobile subscription business with RevenueCat. We do the heavy lifting of normalizing subscribers from any source and maintain a single source of truth for subscription status, so you can get back to building your app.

RevenueCat is a powerful, secure, reliable, and free to use in-app purchase server with global support. All you need to get started is an API key.

Ask A Question

Questions

3

[Android] Crash at android.support.v4.app.JobIntentService$JobServiceEngineImpl.dequeueWork

Hi, We had a sporadic crash issue with the below stack and I've resolved the issue. android.os.Parcel.readException (Parcel.java:2013) android.os.Parcel.readException (Parcel.java:1959) android.app.job.IJobCallback$Stub$Proxy.dequeueWork (IJobCallback.java:191) android.app.job.JobParameters.dequeueWork (JobParameters.java:208) android.support.v4.app.JobIntentService$JobServiceEngineImpl.dequeueWork (JobIntentService.java:314) android.support.v4.app.JobIntentService.dequeueWork (JobIntentService.java:639) android.support.v4.app.JobIntentService$CommandProcessor.doInBackground (JobIntentService.java:389) android.support.v4.app.JobIntentService$CommandProcessor.doInBackground (JobIntentService.java:382) android.os.AsyncTask$2.call (AsyncTask.java:333) java.util.concurrent.FutureTask.run (FutureTask.java:266) java.util.concurrent.ThreadPoolExecutor.runWorker (ThreadPoolExecutor.java:1162) java.util.concurrent.ThreadPoolExecutor$Worker.run (ThreadPoolExecutor.java:636) java.lang.Thread.run (Thread.java:764) The cause was Purchases.configure call at MainApplication class. in our case, an app can be executed on the background first. Purchases.configure creates an internal thread and it could lead to the above crash when an app is launched at the background. As a solution, we've changed a code to call Purchases.configure at MainActivity. It would be great if you can enhance the document or codes because this kind of crash is very difficult to find a root cause.

Posted by Yongjae Chuh 5 months ago

2
ANSWERED

Setting up new user / restoring transactions

When a user registers or logs-in we call `Purchases.setup` with the freshly obtained User ID from our backend. We then call RC restore transactions to see if there is a potential subscription to auto-load. Strange thing happened just now is I registered a brand new User ID on our end and the RC restore transactions callback happened but it contained data that was not for the new user (I could tell it was for a different user that I use for testing who had a bunch of purchased products). The restore payload is: ``` purchases:addRestoreTransactionsListener purchaserInfo { "allExpirationDates": { "annual5": "2018-08-23T16:46:05Z", "monthly3": "2018-08-23T15:18:30Z", "monthly2": "2018-08-22T16:04:41Z", "monthly5": "2018-08-23T15:49:45Z", "monthly": "2018-06-23T21:48:09Z", "monthly4": "2018-08-23T15:49:01Z" }, "activeSubscriptions": [ ], "expirationsForActiveEntitlements": { }, "activeEntitlements": [ ], "allPurchasedProductIdentifiers": [ "monthly", "monthly3", "monthly2", "monthly5", "annual5", "monthly4" ], "latestExpirationDate": "2018-08-23T16:46:05Z" } ``` When I look at the RC web dashboard and click on my "new" user (ID = 456) I get this screen: https://cl.ly/ec8ad0913502 The URL contains my 456 user-id but the transaction list shows my other user (User ID = 1) and the breadcrumb also contains the "1" for my other user. Is there something I am doing wrong whereby the user data is getting criss-crossed? Our React Native RevenueCat setup code is here: https://gist.github.com/ruckus/95a0597df2830da4e0a4af1f7d63ca02

Posted by Cody Caughlan 11 months ago