Crittercism shows how poor Corona for Android is. Coronalabs, do you care?

haakon · January 21, 2013, 1:10am

Right, quite a dramatic title, but we’re actually shocked at how poor Corona works on Android. At least it looks like that after we started logging device crashes.

Being Enterprise users, we’ve been able to implement a crash log plugin, Crittercism.com, that overtakes the Corona Error Handler and the Android error handler, and posts all crashes and lua errors to the crittercism system. It gives us a great knowledge of what our users struggle with.

Hundreds of exceptions happens every day, related to all kinds of (CoronaActivity) crashes.

Can someone @ Coronalabs tell us what in the world is going on?

Do you know how fragile your implementation is?
Is the list of exceptions below known to you already?
What steps have you taken and are you taking to make the Android part more robust?
Why are we even having crashes caused by exceptions in the mix between the Android runtime and the Corona runtime? We, your users, would expect this to be totally robust.

Besides, we wonder how serious these exceptions actually are. It might be that they can be ignored, because they don’t actually take the app down or come forward as a crash to the users. I doubt it though, they look serious. Can someone shed some light?

Here’s a short list of the most common exceptions:

java.lang.RuntimeException: Unable to pause activity {xx.xx.xxx/com.ansca.corona.CoronaActivity}: java.lang.NullPointerException

java.lang.NullPointerException  
at com.ansca.corona.NativeToJavaBridge.callGetBytesFromFile(NativeToJavaBridge.java:755)

java.lang.IllegalArgumentException: View not attached to window manager

android.app.RemoteServiceException: Bad notification posted from package xx.xx.xxx: Couldn't create icon: StatusBarIcon(pkg=xx.xx.xxx id=0x7f020001 level=0 visible=true num=0 )

java.lang.RuntimeException: eglMakeCurrent failed.  
at android.opengl.derived.SwapGLSurfaceView$EglHelper.createSurface(SwapGLSurfaceView.java:709)

java.lang.UnsupportedOperationException  
at android.view.GLES20Canvas.clipPath(GLES20Canvas.java:302)

java.lang.RuntimeException: createWindowSurface failed  
at android.opengl.derived.SwapGLSurfaceView$EglHelper.createSurface(SwapGLSurfaceView.java:701)

java.lang.NullPointerException  
at com.ansca.corona.CoronaActivity.onKeyUp(CoronaActivity.java:1945)

java.lang.NullPointerException  
at com.ansca.corona.CoronaActivity.onKeyDown(CoronaActivity.java:1893)

java.lang.NullPointerException  
at com.ansca.corona.CoronaActivity.onTouchEvent(CoronaActivity.java:1541)

android.view.WindowManager$BadTokenException: Unable to add window -- token android.os.BinderProxy@41327d50 is not valid; is your activity running?

java.lang.RuntimeException: Unable to pause activity {xx.xx.xxx/com.ansca.corona.CoronaActivity}: java.lang.NullPointerException

java.lang.RuntimeException: createWindowSurface failed EGL\_BAD\_ALLOC

java.lang.NoSuchMethodError: <init><br>at android.database.sqlite.SQLiteProgram.release(SQLiteProgram.java:183)<br> [import]uid: 21746 topic_id: 35144 reply_id: 335144[/import]

haakon · January 21, 2013, 1:55am

Hey, another one:

java.lang.IllegalStateException: Can not perform this action after onSaveInstanceState at android.app.FragmentManagerImpl.checkStateLoss(FragmentManager.java:1265) at android.app.FragmentManagerImpl.popBackStackImmediate(FragmentManager.java:451) at android.app.Activity.onBackPressed(Activity.java:2121) at com.ansca.corona.CoronaActivity.onKeyUp(CoronaActivity.java:1951) [import]uid: 21746 topic_id: 35144 reply_id: 139709[/import]

ingemar · January 21, 2013, 2:56am

This does look rather worrying, however what happens when you run your apps on your Android test devices? Can you isolate the reporting of these exceptions to these devices only and see what impact on performance/functionality they may have? [import]uid: 70847 topic_id: 35144 reply_id: 139716[/import]

haakon · January 21, 2013, 11:03am

Uhh, another form. But this enquiry does not fit in the new system, so I’ll just have to wait here for some Coronalabs representative to fire back at me
[import]uid: 21746 topic_id: 35144 reply_id: 139773[/import]

J_A_Whye · January 21, 2013, 11:57am

That’s an irresponsible headline just to try and get an answer faster from Corona Labs.

Jay [import]uid: 9440 topic_id: 35144 reply_id: 139779[/import]

haakon · January 21, 2013, 12:21pm

Yes, definately, I’m guilty as charged, no doubt. I really wonder if all those exceptions are to be expected or not, if it is impossible to fix for the Corona dudes or what. [import]uid: 21746 topic_id: 35144 reply_id: 139780[/import]

Joshua_Quick · January 21, 2013, 1:46pm

Haakon,

Regarding OpenGL exceptions…

java.lang.RuntimeException: eglMakeCurrent failed.
java.lang.RuntimeException: createWindowSurface failed

The “createWindowSurface” crash was known to happen on some devices using GPU “PowerVR SGX 540” such as LG (but not on Kindle Fires and Nooks). We fixed this issue in daily build #986.

We have not been able to reproduce the “eglMakeCurrent” crash, but we did notice that Google has made several OpenGL fixes as can be seen in the link below.
https://github.com/android/platform_frameworks_base/commits/master/opengl/java/android/opengl/GLSurfaceView.java

Since Google’s fixes are only available in the newest Android OS versions, we decided to port their code into Corona (their license allows this), making their fixes available on all Android OS versions that Corona supports (Android 2.2 and above). This was done last week, as of daily build #1007.

Regarding OpenGL exception…

android.view.GLES20Canvas

Corona does not use that Java class. Nor have we ever received a bug report with that error before. I don’t believe that error comes from Corona. Do you have the full stack trace? That should indicate the root cause of that error.

Regarding…

java.lang.NoSuchMethodError: at android.database.sqlite.SQLiteProgram.release(SQLiteProgram.java:183)

I don’t believe this error comes from Corona either. Corona uses the official native SQLite library, which is really just a giant *.c file. Corona does not use Google’s Java implementation of SQLite. If you have access to the stack trace, then that should tell you where the error is coming from.

Regarding all of the other exceptions such onKeyDown, onKeyUp, onTouch, and other UI related exceptions, I’ve never received reports about those issues either. I’m thinking that your AndroidManifest.xml file’s CoronaActivity is misconfigured. Is the activity set up to be “singleTask”? It should look something like this…
[lua] android:configChanges=“keyboardHidden|screenSize|orientation”
android:label=“My Application”
android:launchMode=“singleTask”
android:theme="@android:style/Theme.NoTitleBar.Fullscreen">[/lua]

Note that launchMode is set to “singleTask”. That setting is very important because the CoronaActivity was designed to only support one instance at a time. If you are missing that XML attribute, then I can potentially see some UI crashes occurring if you have multiple CoronaActivity instances and you exit out of one of them. That would screw over the other CoronaActivity instance.

Also, are you able to reproduce any of the above crashes on your own devices? If so, then that would make isolating this a lot faster for both of us.
[import]uid: 32256 topic_id: 35144 reply_id: 139792[/import]

sam3dus · January 21, 2013, 1:56pm

Corona seems slanted to iOS.
Android is their red-headed step-child.

ex. your issues, android manifest control, etc.

Perhaps it’s just a reality of their # of staff vs tasks that need attention.
But the generic android build template issue has been around for x years.

As much as we’ve enjoyed the Test Driver account and the Corona simulator and physics support, we cannot justify the expense of a subscription until Android is given somewhere close to the support that iOS enjoys. [import]uid: 186251 topic_id: 35144 reply_id: 139787[/import]

haakon · January 21, 2013, 2:09pm

Joshua, thanks. We’re diving into this right away, starting with updating to the latest daily. We’re using singleTask in our Manifest, so the UI errors must have some other origin. We’ll post more relevant stack traces as soon as we’ve seen how the latest daily performs. [import]uid: 21746 topic_id: 35144 reply_id: 139794[/import]

kimruben · January 21, 2013, 2:13pm

Haakons (Our) AndroidManifest.xml should be very correct, as the original version we had was one we got by apktooling out one from an apk built by a non-enterprise version of coronasdk. [import]uid: 63706 topic_id: 35144 reply_id: 139795[/import]

Joshua_Quick · January 21, 2013, 8:22pm

Regarding the NullPointerExceptions within the CoronaActivity (ie: key/touch events), we added additional error handling and null checks to prevent those exceptions from handling. This change will make it into daily build #1009, tomorrow.

That said, I’m surprised these exceptions are happening at all. The only way they can happen is if the CoronaActivity received key/touch events *after* the window was destroyed via a call to its onDestroy() method by the operating system. But in any case, it doesn’t hurt to have additional error handling on our end. If you can reproduce these NullPointerExceptions on your end, then please let us know if this fixed the issue. Thanks! [import]uid: 32256 topic_id: 35144 reply_id: 139837[/import]

haakon · January 21, 2013, 1:55am