-
Notifications
You must be signed in to change notification settings - Fork 43
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.
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
ANRs when calling Purchases.configure() during Application.onCreate() #1629
Comments
👀 We've just linked this issue to our internal tracker and notified the team. Thank you for reporting, we're checking this out! |
Hi, |
The app is on the latest 7.6.0 version, but the version in error reports vary over the last 28 days. Since the ANR locations are not consistent, I thought it was more important to demonstrate the ANRs happening than to only cherry pick those on the latest version. If you want me to do that, I can. This error is very rare with 60 events over 28 days out of many thousands of users. That said, it is the top crash in my app so it got my attention and if you were doing I/O, that should be fixed. But I see now the stack trace is more likely just loading the parser and not actually parsing. I don't believe I'm configuring the SDK any differently than your example. In my Application:
|
Here is a stack from the latest version showing work being done on the main thread to restore subscriber attributes from the cache. This implies I/O happening on the main thread.
|
@rglanz-rc Here are some more stack traces. Seeing 30+ ANRs within the last 90 days after calling Purchases$Companion.configure from the Android startup library.
|
I'm seeing in the field several dozen ANRs happening inside Purchases.configure. I am calling configure during Application.onCreate(), which matches your examples.
For reference, I have 16 products defined for Google Play where this is failing and 13 products defined for Amazon. These are part of 8 offerings, most with 3 packages. I don't know if the quantity here is impacting the configure time, but it doesn't seem like much compared to other apps.
Here are a sampling of my ANRs. Each ANR exception is a bit different, likely due to how far configure got in reconstituting its data before the system killed it with the ANR hammer. The second one is especially concerning to me since it shows json parsing happening on the main thread, which implies I/O and that is generally a bad idea on the main thread.
Now I could call configure in the background, but that could introduce race conditions around Purchases being configured. So I would like to know what the design intent is here and if there is a bug in doing too much I/O. Also depending upon the answer, your examples may need to be changed.
The text was updated successfully, but these errors were encountered: