Yes I understand, but the only difference between the version that gives a rate of 24.44% and the one of 0.04% is the inclusion of that parameter. That’s all. Also the same thing has happened to another developer.
At this point I am baffled and I no longer know how to attack the problem.
Yeah checking the plugins none were updated between builds. So im as stumped as you guys. the last was admob and that was updated before we put the builds which caused crashes. then i made 2 changes, one was hiding banners on app suspend/exit, and the other was showRuntimeErrors = false and crashes went WAY down. lower than they have probably ever been?!? makes no sense.
Most likely hiding the banners on suspend. Solar is awful on suspend/resume and causes so many ANRs. I just can’t get below 1.4% for ANRs. Using bugsnag was eye-opening and really highlighted the problem there. Most likely because I am using 500MB+ texture memory (as each update gets worse)
For example a device can be fine, suspend/resume and then get nothing but low memory errors. 95% of my ANRs are triggered by a suspend… Go figure?
We tried out your suggestion of forcing an exit when the app suspends, but unfortunately we got a lot of negative feedback about it so reverted back to standard suspend behaviour.
It did make a noticeable drop in ANRs when we did it though.
This is a bit off topic, but it is consistent with your feedback on ANR.
We are facing a number of Android ANR issues, when the APK package or OBB is large (1GB or more) when starting Activity’s onCreate, initializing the FileService entry to register all resources, occupying the main thread for a long time resulting in ANR. It also causes ANR when the lifecycle onPause is triggered due to lock contention (between the GLThread which running heavy Lua code and main processes handle lifecycle).
This has always been a problem (including the latest 3696 of course).
Could you take a look? @vlads
Thanks.
And if you facing the same ANR issue, please ping this post with your APK/OBB/AAB size in MB, thanks.
A few days ago I have launched an update of one of my apps with the highest volume of downloads (120k daily), with 8.8 million active users and DAU = 1.2 million users.
I launched to 5% of users, for obvious reasons. After a couple of days these are the results:
The previous version (166 - Build 3691) had a crash rate of 0.10%. Now the update with build 3696 went to have 6.45% crash rate. There are no code changes, except having added in build.settings the inputs suggested by Vlad to resolve (java.lang.NullPointerException).:
<provider
android:name="androidx.startup.InitializationProvider"
android:authorities="${applicationId}.androidx-startup"
tools:node="remove">
</provider>
And in main the following to hide the ads when the application is suspended or the user comes out of it:
local function onSystemEvent( event )
if event.type == "applicationSuspend" or event.type == "applicationExit" then
HideAds() -- This calls a function which hides admob's ads.
end
end
Runtime:addEventListener( "system", onSystemEvent )
Increasingly bewildered
FYI, SIGENV means your app is trying to access memory it doesn’t own. Is this on a new play or after a suspend/resume which seems to be the main source of all errors currently.
I am using 3965 without any crash increase but I do not use banners.
The only fix for this is to separate UI code (taps and stuff) from the main thread. It would be simple to return a state of handled in this scenario and this would avoid the ANR being registered.
Corona is stuck in the 320x480 days where game were 30 assets on screen!
This won’t get fixed even though I reported this to vlad over a year ago.
How could I do it?
A quick thought @orangegstudios do you expose the audio library al mixer in your app? we seem to be getting alot of crashes coming from what seems to be that.
*** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
pid: 0, tid: 11933 >>> com.razmobi.monstertrucks2 <<<
backtrace:
#00 pc 0x00000000000302a0 /apex/com.android.runtime/lib/bionic/libc.so (je_free+336)
#01 pc 0x0000000000008441 /data/app/com.razmobi.monstertrucks2-RND9eoLNQr2DqLP_3rasVw==/split_config.armeabi_v7a.apk!libalmixer.so
#02 pc 0x000000000009ca95 /data/app/com.razmobi.monstertrucks2-RND9eoLNQr2DqLP_3rasVw==/split_config.armeabi_v7a.apk!libcorona.so
#03 pc 0x000000000000ca6b /data/app/com.razmobi.monstertrucks2-RND9eoLNQr2DqLP_3rasVw==/split_config.armeabi_v7a.apk!liblua.so
#04 pc 0x000000000001b0e1 /data/app/com.razmobi.monstertrucks2-RND9eoLNQr2DqLP_3rasVw==/split_config.armeabi_v7a.apk!liblua.so
#05 pc 0x000000000000ccc1 /data/app/com.razmobi.monstertrucks2-RND9eoLNQr2DqLP_3rasVw==/split_config.armeabi_v7a.apk!liblua.so
#06 pc 0x000000000000c4df /data/app/com.razmobi.monstertrucks2-RND9eoLNQr2DqLP_3rasVw==/split_config.armeabi_v7a.apk!liblua.so
#07 pc 0x000000000000cead /data/app/com.razmobi.monstertrucks2-RND9eoLNQr2DqLP_3rasVw==/split_config.armeabi_v7a.apk!liblua.so
#08 pc 0x00000000000064d3 /data/app/com.razmobi.monstertrucks2-RND9eoLNQr2DqLP_3rasVw==/split_config.armeabi_v7a.apk!liblua.so (lua_pcall+202)
we do expose/use it in some of our apps and am wondering if that is a theme for the crashes in the new builds.
can see above crash that seems to reference the /split_config.armeabi_v7a.apk!libalmixer.so
Do you ever pass an onComplete function to audio.play() ? That listener has caused problems in the audio library for as long as I can remember.
No, never used onComplete in audio.play, I saw a previous post on that and double checked all my code to make sure wasn’t there.
We do use the al mixer to set the pitch of certain audio.
I am using audio.play and oncomplete in many places. Just yesterday I uploaded an update that eliminated oncomplete because I had found a thread in an old forum where they said that it caused many crash. In a few days I will have the vitals results.
I don’t use onComplete for audio.play and I also get lots of crashes from almixer.so
It’s very annoying since it’s out of our control. We use loops for background music and that’s it. Everything is is standard audio.play and nothing fancy.
There has to be some behind the scenes bug with this many people having issues (for months now).
Hi, today I obtained data of android Vitals, and unfortunately the crash rate did not fall, confirming that “oncomplete” of “audio.play” is not the problem, because I have eliminated. At this point I think the problem is underlying some change in “build/sdk” that we cannot resolve and we need the help of @vlads
Try a test build, without plugins to say 5% of users and see if this helps?
If that doesn’t crash, then add them back in one by one until you find the issue. I will give an educated guess it’s admob.
And if it’s admob try disabling/reducing frequency of the specific features (banners, interstitials etc) to catch the villain. Or use a crash reporting system with breadcrumbs to catch the specific moment the crashes occur (like before displaying an ad). With enough evidence it is admob you could also go to a Google forum.
Also I think Vlad should chip in on this as it’s an important matter and definitely tied to the target 33 update
In a previous test, eliminate the banners of one of my apps, and the crash rate remained very high, without changes. (My app shows banners and interstitial)
Now I just sent an update to 10%, completely eliminating Admob.
This probably won’t help since it’s tied to ANR’s not crashes, but who knows. Since admob v21 I think you can add this in your manifest and remove initialization and ad loading from the main thread (then if a crash occurs there it doesn’t mess with input and triggers the ANR). One ANR I was having in the console tied to ad loading did disappear after I put this
applicationChildElements =
{
[[
<meta-data
android:name="com.google.android.gms.ads.flag.OPTIMIZE_INITIALIZATION"
android:value="true"/>
]],
[[
<meta-data
android:name="com.google.android.gms.ads.flag.OPTIMIZE_AD_LOADING"
android:value="true"/>
]],
}