Closed SponsorAds closed 2 years ago
Why do you think this ANR is related to the adverts extension? The main thread there referenced in the anr is the air thread not any of our extensions. There is a query for the advertising identifier in a waiting state but that would be because the other thread is blocking. I'd suggest logging this with Harman, they will be able to understand the references in the main libCore.
Generally these issues are related to sound playback.
Also crashes are quite different to ANRs, this appears to be an ANR which means your app is taking a long time to do something. This can be caused by your code, not just the runtime, eg if you do a long load or a blocking process that stops the UI.
We do not use any kind of audio or video playback with AIR directly, but only your ANE for it. Our app code is now about 5 years old. We do not have any loading times going on, nothing is locking up the main thread. These are typical input dispatch ANEs. Every single report is about watching ads or random hangs. They just got significantly higher in the last couple months. Interestingly we see the exact same stack trace on 6 different apps now, just after we updated the SDK and ANEs (and not touching any code).
Sadly as everything is closed source we're also completely unable to debug anything. It's e.g. impossible to know when this ANE is even fetching the identifiers.
I'd suggest you post this on the AIR SDK site. I can't see any reason this is directly related to the extensions. They will be able to understand what's happening in all of those AIR library references there.
The ad identifier will either be retrieve via your code directly or internally to the ad sdks. We don't do anything without your interaction in the ANE, but the advertising SDKs will. But I've never seen these async calls cause an ANR so I highly doubt that is the issue, it's just another process that happens to be waiting for whatever is blocking.
Looks like Harman have an answer for you regarding garbage collection? Meant to mention that is often the other cause (second to the audio).
https://github.com/airsdk/Adobe-Runtime-Support/issues/1675
Cheers
Not at all. His answer boils down to "sucks, good luck finding our GC issues". We confirmed than none of our app features causes >4ms GC spikes and that our app never, in 3 hours constant usage, goes above 200MB ram (of which 120MB are textures preloaded). So the fun goes on.
Ah sorry to hear that. Only thing i can suggest is to make sure you are running those tests on a device that you have listed as experiencing the ANR in the console. There can be a large difference between android devices.
For months we are experiencing thousands of crashes and ANR (5+%) that seem to be linked to your adverts ANEs. At least that is the only reference all logs show. The exact same logs are showing up on all our apps and it is starting to cost us quite some money as our support gets flodded with requests regarding crashes.