Troy, I am unware of where any changes to the widget library stand on our priority list. It’s in the queue of things that causes Android Crashes and we are working to get to them as quickly as we can.
Rob
This thread is wandering, and I don’t wish to minimize the impact of various runtime errors caused by errant code that causes “attempt to index nil” -type errors, indeed those should be addressed wherever found, BUT…
I hope your engineering team knows the difference between runtime errors (typically caused by Lua, whether dev’s own or Corona’s libs like widget/etc, and/or their Java-Lua interfaces) and low-level ANR’s (typically caused by flaws in native-code libs, and/or their Java-native interfaces)
To some degree a dev can work around the first class of higher-level problems, even if buried within Corona libs (by monkey-patching them, or using something else), but there’s usually no practical way to work-around the second class of lower-level problems at a dev’s level.
It’s these low-level native-lib “true” ANR’s that are having the greatest impact. (at least, for those who’ve already done everything else they can do at higher levels to eliminate runtime errors) So that’s where I hope your engineering is focusing their efforts.
(Updated: This issue RE: runtime error caused by widget.lua has been moved to https://forums.coronalabs.com/topic/72782-runtime-error-caused-by-widgetlua/))
@Rob, Technically, if I wanted to fix the widget errors while waiting for Corona to fix them, I could move it into my project folder and make the changes myself. So, I agree with Dave’s point that priority should be on bugs we (as devs) are unable to reach ourselves. And my CRASH / ANR rate (<1%) is only impacting the traffic Google sends me, which really should be my own responsibility, too. But please, if possible, put widget.lua on the priority list just below this.
Can you point me to where I can download the latest widget folder?
The widget library can be found here: https://github.com/coronalabs/framework-widget
However, it’s a few months out of sync with our internal version. I’m trying to see what’s involved in getting it updated so everyone has access to the latest version.
Rob
A few months? @Rob most core files are at least 2 years out of date!
@troy, framework crashes are totally out-of-scope (for us) and need Corona to urgently fix.
Some progress is being made so this is at least positive, but IMHO this has been a growing issue since way before Christmas and HTML builds should really of been paused to concentrate of live apps that are suffering right now.
Today I saw my CRASH count rise again and the number of my downloads go down, again.
The crash seems to impact Android 7 and 8 the most.
Can anyone refer me to a link where I can learn more about how to read this report? Is the top item where it stopped (at com.ansca.corona.Controller.stop (Controller.java:263) - waiting to lock <0x0abd65e7> (a com.ansca.corona.Controller) held by thread 11
or is it the one at the bottom?
@SGS, would you classify this as a framework crash, also?
Here is the main report…
Broadcast of Intent { act=android.intent.action.SCREEN_OFF flg=0x50000010 launchParam=MultiScreenLaunchParams { mDisplayId=0 mBaseDisplayId=0 mFlags=0 } (has extras) }
“main” prio=5 tid=1 Blocked | group=“main” sCount=1 dsCount=0 obj=0x75d0d6a8 self=0xf1305400 | sysTid=22014 nice=0 cgrp=default sched=0/0 handle=0xf413a534 | state=S schedstat=( 0 0 0 ) utm=1969 stm=897 core=1 HZ=100 | stack=0xff66f000-0xff671000 stackSize=8MB | held mutexes=
at com.ansca.corona.Controller.stop (Controller.java:263)
- waiting to lock <0x0abd65e7> (a com.ansca.corona.Controller) held by thread 11
at com.ansca.corona.CoronaActivity.requestSuspendCoronaRuntime (CoronaActivity.java:2005)
at com.ansca.corona.CoronaActivity.onPause (CoronaActivity.java:1828)
at android.app.Activity.performPause (Activity.java:6894)
at android.app.Instrumentation.callActivityOnPause (Instrumentation.java:1323)
at android.app.ActivityThread.performPauseActivityIfNeeded (ActivityThread.java:3791)
at android.app.ActivityThread.performPauseActivity (ActivityThread.java:3768)
at android.app.ActivityThread.performPauseActivity (ActivityThread.java:3742)
at android.app.ActivityThread.handlePauseActivity (ActivityThread.java:3716)
at android.app.ActivityThread.-wrap16 (ActivityThread.java)
at android.app.ActivityThread$H.handleMessage (ActivityThread.java:1516)
at android.os.Handler.dispatchMessage (Handler.java:102)
at android.os.Looper.loop (Looper.java:154)
at android.app.ActivityThread.main (ActivityThread.java:6247)
at java.lang.reflect.Method.invoke! (Native method)
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run (ZygoteInit.java:872)
at com.android.internal.os.ZygoteInit.main (ZygoteInit.java:762)
(Updated: This issue RE: runtime error caused by widget.lua has been moved to https://forums.coronalabs.com/topic/72782-runtime-error-caused-by-widgetlua/))
@Rob, thank you for looking into an update to widget.lua
@troy yes it is. It is most likely caused by switching to an ad or other plugin that is taking control of the runtime.
I think @Rob’s response was just re the widget repository being out of date.
However, to your point, yes, many of these “framework” issues go way back (for example) - it’s just that no one seemed to cared about them until last May when mandatory reporting and vitals started punishing your ranking.
@dave yeah fixes are long time coming re ANR’s (which would hopefully help you as well).
But I meant the widgets repo is 2 years out of date (well that is what it shows for me).
Just launched a new version on Android and in the first couple of hours, I see this…
ANR
“main” prio=5 tid=1 MONITOR | group=“main” sCount=1 dsCount=0 obj=0x418abd08 self=0x417e1898 | sysTid=32385 nice=-11 sched=0/0 cgrp=[fopen-error:2] handle=1074307412 | state=S schedstat=( 0 0 0 ) utm=278 stm=84 core=1
at com.ansca.corona.CoronaActivity.requestSuspendCoronaRuntime (CoronaActivity.java:2005)
at com.ansca.corona.CoronaActivity.onPause (CoronaActivity.java:1828)
at android.app.Activity.performPause (Activity.java:5563)
at android.app.Instrumentation.callActivityOnPause (Instrumentation.java:1239)
at android.app.ActivityThread.performPauseActivity (ActivityThread.java:3351)
at android.app.ActivityThread.performPauseActivity (ActivityThread.java:3320)
at android.app.ActivityThread.handlePauseActivity (ActivityThread.java:3298)
at android.app.ActivityThread.access$1100 (ActivityThread.java:172)
at android.app.ActivityThread$H.handleMessage (ActivityThread.java:1316)
at android.os.Handler.dispatchMessage (Handler.java:102)
at android.os.Looper.loop (Looper.java:146)
at android.app.ActivityThread.main (ActivityThread.java:5598)
at java.lang.reflect.Method.invokeNative (Native Method)
at java.lang.reflect.Method.invoke (Method.java:515)
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run (ZygoteInit.java:1283)
at com.android.internal.os.ZygoteInit.main (ZygoteInit.java:1099)
at dalvik.system.NativeStart.main (Native Method)
Wow! I just looked at my crash rate and it spiked in January around 500, and is currently around 350 / month, it used to be around 30 a month, and that is with corona 3162 and no updates in more than six months!
I use Admob, Widget Candy UI, and Badger IAP libraries, that’s it!
and most of the crashes are happening on S7’s and S8’s…
Does Corona 2018.3274 fix these crashes yet? I see this build and a previous one fix 2 ‘rare’ android bugs. Would be nice if we get a bit more info on what those bugs exactly relate to?
Following up as well. Anyone from Corona who can verify please?
I am also in the same boat as OP (huge amount of ANRs and crashes which are not relevant with my code). I believe this relates to all developers’ projects, but only the ones with larger userbases detects the 1% crashes (which is significant in google terms and can dramatically lower your ranking).
@Corona Team
Please keep us informed about related findings. Fixing ranking punishment is much much more important than new features!
This problem matters more than anything else because it is lowering our reputations and hitting us in the wallet. We made a commitment to Corona and need to depend on Corona to deliver a stable experience for us and our users. Corona does a great job, but this problem needs to be fixed yesterday.
It looks like Unity is dealing with a similar issue:
[ANDROID][IL2CPP] APPLICATION.QUIT() CRASHES THE APP
Mobile-Mar 14, 2018-Priority: 2Necessary for shipping a final release-Severity: 1Crash or major loss of functionality
To reproduce:
-
Download attached project “Unity_ApplicationQuit.zip” and open in Unity
-
Build and run the project on an Android device
-
Wait till APK closes itself
Expected Result: APK closes itself without a crash
Actual Result: APK closes itself alongside with a crash
Just saying: iOS treats self-closing apps as crashes. Do not self-close your apps. Is not a good thing.
@Vlads brings up a great point. Many of these crashes seem to happen as the app is closing down. Modern mobile OS’s don’t need apps to close. Maybe try not exiting them and see if that impacts your crashes. This should be an easy fix to test that wouldn’t require a release (or at a minimum testing to you beta testers).
Anyway to answer some of the questions (though I will likely be repeating previous answers).
-
This is our number one engineering priority. There just are a lot of reports to go through.
-
This primarily seems to affect Android 7 and 8 and affects apps that have been running fine for months. So clearly Google changed something on their end. There seems to be several common themes in the crashes:
a. OpenAL Audio
b. Suspend/Exiting
c. Plugins
d. Other odd crashes
For the Audio side, we have the new Android audio in beta. This will clearly remove the “OpenAL” crashes. But we have known bugs and we are unaware of anyone who’s released with this audio version so we can’t predict that there won’t be new ANRs. If your app is suffering from these crashes, it might be worth, after heavy testing, to try the new android audio.
For Suspending/Exiting. The recent fixes may have addressed these but I think we have more to go. Is it worth doing a rebuild now? If you can do a staged roll out to see if you’re effected, then you probably should try. If you are intentionally exiting, you should try not exiting and just let the OS suspend the app.
As far as plugins go, we are releasing these as we fix them. I’ve been working with the team to find a better way to communicate changes to you. The following seem to have been updated: AdColony, InMobi, Facebook Audience Network, Unity Ads, Chartboost and AppLovin. If you use these plugins, it would be worth rebuilding and resubmitting your app.
The other odd crashes will be a matter of watching the daily build release notes.
Rob