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. |
vegaro
added a commit
that referenced
this issue
Jul 8, 2024
…nd (#1772) ## Description This PR addresses a significant number of ANRs (Application Not Responding errors) reported, such as in issue #1629. ## Problem The method `IdentityManager.configure` is currently running on the main thread and accessing `SharedPreferences`. Accessing `SharedPreferences` can be costly, especially if the XML file storing the preferences is large. This cost is particularly high during the initial accesses, as the XML file needs to be read and parsed, which can block the main thread and lead to ANRs. ## Solution **Custom Dispatcher**: This PR introduces a custom dispatcher to the `IdentityManager`, allowing configure to run on a background thread. By moving this operation off the main thread, we avoid blocking it with the potentially expensive SharedPreferences access. **Main Thread Optimization**: The remaining setup in `PurchasesOrchestrator` has been deferred to execute after configure completes, ensuring the main thread remains unblocked and improving overall app responsiveness. ## Notes While this fix should mitigate the reported ANRs, it's possible there are other underlying causes contributing to these issues. This PR serves as a good initial step towards improving performance.
|
This issue has been automatically locked due to no recent activity after it was closed. Please open a new issue for related reports. |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
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: