Forums

OverviewV-Play 1 Support › Reports of several app-crashes – can't figure out why

Viewing 9 posts - 1 through 9 (of 9 total)
  • Author
    Posts
  • #4711

    Saims

    Hi,

    Crazy Elephant is doing quite well in the Google Play Store but with more downloads reports of crashes (and 1 or 2 star ratings -.-) become more and more frequent, but we don’t really know, what causes the crashes.

    The weird thing is, one 1-star rating said it crashed immediately at app-start with the Galaxy Ace. But my dad also has a Galaxy Ace and there has never been a problem with our app. We got three more confirmed crashes, one again with the Galaxy Ace, another one with a Galaxy Y and the third one with a Huawei M865.

     

    Two people sent us Error-Logs. The first one was by the Huawei M865:

    “java.lang.UnsatisfiedLinkError

    in java.lang.Runtime.loadLibrary”

    – “java.lang.ExceptionInInitializerError
    at java.lang.Class.newInstanceImpl(Native Method)
    at java.lang.Class.newInstance(Class.java:1409)
    at android.app.Instrumentation.newActivity(Instrumentation.java:1021)
    at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:1572)
    at android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:1674)
    at android.app.ActivityThread.access$1500(ActivityThread.java:117)
    at android.app.ActivityThread$H.handleMessage(ActivityThread.java:942)
    at android.os.Handler.dispatchMessage(Handler.java:99)
    at android.os.Looper.loop(Looper.java:130)
    at android.app.ActivityThread.main(ActivityThread.java:3733)
    at java.lang.reflect.Method.invokeNative(Native Method)
    at java.lang.reflect.Method.invoke(Method.java:507)
    at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:931)
    at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:689)
    at dalvik.system.NativeStart.main(Native Method)
    Caused by: java.lang.UnsatisfiedLinkError: Couldn’t load QtScript: findLibrary returned null
    at java.lang.Runtime.loadLibrary(Runtime.java:429)
    at java.lang.System.loadLibrary(System.java:554)
    at xom.xxmassdeveloper.CrazyElephant.MainActivity.<clinit>(MainActivity.java:69)
    … 15 more”

     

    And the second one was sent from a Galaxy Ace:

    “java.lang.RuntimeException

    in android.opengl.GLSurfaceView$EglHelper.throwEglException”

    – “java.lang.RuntimeException: eglSwapBuffers failed: EGL_SUCCESS
    at android.opengl.GLSurfaceView$EglHelper.throwEglException(GLSurfaceView.java:1085)
    at android.opengl.GLSurfaceView$EglHelper.swap(GLSurfaceView.java:1043)
    at android.opengl.GLSurfaceView$GLThread.guardedRun(GLSurfaceView.java:1369)
    at android.opengl.GLSurfaceView$GLThread.run(GLSurfaceView.java:1123)”

     

    I hope you can help us figure out where the crashes come from, cause we don’t really want to collect more and more 1-star ratings 😉

     

    Greetings, Simon

    #4712

    Alex
    V-Play Team

    Hi Simon,

    thanks for reporting this issue. We already got some messages about that, but weren’t unfortunately able to reproduce the error with one of our testing devices (including a Galaxy Ace btw). To further narrow down the problem: Did the crashes happen with updated versions of your games or with the initial apk too?

    Thanks,

    Alex

    #4713

    Christian
    V-Play Team

    I got two reports about the same (the first problem), one from our game Blockoban and one from Blitzkopf:

    java.lang.UnsatisfiedLinkError
    
    in java.lang.Runtime.loadLibrary
    
    java.lang.ExceptionInInitializerError
     at java.lang.Class.newInstanceImpl(Native Method)
     at java.lang.Class.newInstance(Class.java:1409)
     at android.app.Instrumentation.newActivity(Instrumentation.java:1040)
     at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:1735)
     at android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:1851)
     at android.app.ActivityThread.access$1500(ActivityThread.java:132)
     at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1038)
     at android.os.Handler.dispatchMessage(Handler.java:99)
     at android.os.Looper.loop(Looper.java:150)
     at android.app.ActivityThread.main(ActivityThread.java:4277)
     at java.lang.reflect.Method.invokeNative(Native Method)
     at java.lang.reflect.Method.invoke(Method.java:507)
     at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:839)
     at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:597)
     at dalvik.system.NativeStart.main(Native Method)
    Caused by: java.lang.UnsatisfiedLinkError: Couldn't load QtScript: findLibrary returned null
     at java.lang.Runtime.loadLibrary(Runtime.java:429)
     at java.lang.System.loadLibrary(System.java:554)
     at at.fhooe.mc.blitzkopf.MainActivity.<clinit>(MainActivity.java:69)
     ... 15 more

    I’m not sure but I think the programs were not built with the newest V-Play Version, I think it was 1.1.

    #4714

    Christian
    V-Play Team

    I just found two other error messages in flurry from Blockoban:

    class java.lang.RuntimeException
    Msg: (eglSwapBuffers failed: EGL_BAD_ALLOC)
     android.opengl.GLSurfaceView$EglHelper.throwEglException:1229
     android.opengl.GLSurfaceView$EglHelper.swap:1187
     android.opengl.GLSurfaceView$GLThread.guardedRun:1514
     android.opengl.GLSurfaceView$GLThread.run:1267

    And:

    class java.lang.NullPointerException
    Msg: android.app.SearchManager.getSearchableInfo:695
     android.app.SearchDialog.show:331
     android.app.SearchDialog.doShow:302
     android.app.SearchDialog.show:284
     android.app.SearchManager.startSearch:483
     android.app.Activity.startSearch:2687
     android.app.Activity.on

     

    Unfortunately, there’s no more saved of the message or stack trace than this. Maybe it helps :)

    #4715

    Saims

    When the error appeared for the first time it was an updated version compared to the one we handed in for our assignment. But we didn’t really change anything substantial until the first crash. So I think the initial apk would crash too (but with the initial apk we had just 20-30 active users and I guess that’s why it never crashed, or at least nobody reported it)

    But as I said, we also couldn’t reproduce the error with the Galaxy Ace. It’s so weird, but it seems like sometimes it’s working on the first start with the Galaxy Ace and sometimes it crashes.

    BTW, for building we used V-Play 1.3.

    #4717

    andiii

    Maybe it’s time to switch from cocos2d-x 0.99 to cocos2d-x 2.0/2.1.
    Cocos2d-x 2.0 and higher is based on OpenGL ES 2.0 which runs on Android 2.2 and higher.
    Many new devices don’t support OpenGL ES 1.0/1.1 or have a poor performance (emulated by ES 2.0).
    OR: when scene states change, “onPause” and “onResume” is called in the background (I imagine).
    The mglView’s corresponding methods “onPause” and “onResume” must be called also.
    OR: cheaper devices (like the Galaxy Ace) have less maximum heap -> textures must be decoded into
    heap memory before it is sent to an OpenGL texture -> bottleneck. Try also using pvr textured, ccz compressed,
    I imagine you are now using png images.

     

    The unsatisfied link error may be a problem of the update.
    Maybe some armeabi .so libraries are not copied into the apk? -> check Android NDK
    Maybe you build the library for ARM v7 (i.e. with APP_ABI=armeabi-v7a) but not for ARM v6 (APP_ABI=armeabi) -> cheaper/older devices?
    -> build for both architectures?
    Maybe error in Android.mk (LOCAL_LDLIBS)
    The last resort is that users must uninstall and reinstall the app -> clears cache.
    (Android works like that -> uninstall and reinstall to fix problems :) )

     

    #4718

    Alex
    V-Play Team

    Thanks for all your input guys!

    Andiii, you made some good points:

    andiii said:

    The unsatisfied link error may be a problem of the update.

    This was our first guess too, we are currently still looking into that.

    andiii said:

    Maybe some armeabi .so libraries are not copied into the apk? -> check Android NDK

    We already checked the concerned apks, they are all available (and copied to the app’s directory which we could verify on one of the affected devices. Furthermore the crashes do not happen on a deterministic way so the libraries may be loadable once in a while.

    andiii said:

    Maybe you build the library for ARM v7 (i.e. with APP_ABI=armeabi-v7a) but not for ARM v6 (APP_ABI=armeabi) -> cheaper/older devices?
    -> build for both architectures?

    All V-Play libraries are built with armeabi.

    andiii said:

    The last resort is that users must uninstall and reinstall the app -> clears cache.
    (Android works like that -> uninstall and reinstall to fix problems :) )

    “Android works like that” 😉 Nice, but unfortunately this solution is not really satisfying, so we’re investigating this issues further and keep you updated!

    Thanks,
    Alex

    #4719

    Alex
    V-Play Team

    Saims said:

    The weird thing is, one 1-star rating said it crashed immediately at app-start with the Galaxy Ace. But my dad also has a Galaxy Ace and there has never been a problem with our app. We got three more confirmed crashes, one again with the Galaxy Ace, another one with a Galaxy Y and the third one with a Huawei M865.

    Simon, can you reproduce which versions of Android OS your customers are running on (especially the one with the Ace)?

    Thanks,

    Alex

    #4728

    Saims

    as far as i know in the developer console it’s just possible to find out which device it was and which app-version was used, but not the Android-version. Pls correct me if I’m wrong.

    I BTW just saw on flurry, that the “java.lang.RuntimeException” appeared more then 60 times within the last weak, but unfortunately it seems like flurry doesn’t provide anymore details.

Viewing 9 posts - 1 through 9 (of 9 total)

RSS feed for this thread

You must be logged in to reply to this topic.

Voted #1 for:

  • Easiest to learn
  • Most time saving
  • Best support

Develop Cross-Platform Apps and Games 50% Faster!

  • Voted the best supported, most time-saving and easiest to learn cross-platform development tool
  • Based on the Qt framework, with native performance and appearance on all platforms including iOS and Android
  • Offers a variety of plugins to monetize, analyze and engage users
FREE!
create apps
create games
cross platform
native performance
3rd party services
game network
multiplayer
level editor
easiest to learn
biggest time saving
best support