1

Our game stalls as it loads our main library under Android with API level 15 (or 14, haven't test previous versions). This does not occur on device with API level 16 and above.

We are using the NDK so our Main.java includes the following lines at its end:

static {
    boolean bFMODReady = false;
    try {
      System.loadLibrary("fmod");
      System.loadLibrary("fmodstudio");
      bFMODReady = true;
    } catch (UnsatisfiedLinkError e) {
        Log.e(TAG, "Unable to load FMOD (" + e.getLocalizedMessage() + ")");
    }

    if (BuildConfig.AMAZON) {
        System.loadLibrary("AmazonGamesJni");
    }

    System.loadLibrary("Main");

    if (!bFMODReady) {
        Log.e(TAG, "FMOD is not ready -> disable audio");
        disableAudio();
    }
}

The game stalls at launch with the following log:

05-05 00:30:39.017 598-598/com.snip.snap D/dalvikvm: Trying to load lib /mnt/asec/com.snip.snap-1/lib/libMain.so 0x4175c7e8

Nothing more. According to previous logs, fmod, fmodstudio and AmazonGamesJni libraries load just fine.

Obviously the loading of libMain.so get stuck for whatever reason. We are compiling our libraries against c++_static (with the APP_STL value from the Application.mk file). We also are using Proguard and multidex.

Here are what we tried to fix the issue but failed:

  • compile against either c++_shared, gnustl_static or gnustl_shared;
  • deactivate some of the static libraries we are linking our libMain against. Since it's a very lengthy operation we did deactivate just a very few;
  • deactivate proguard

What can we do to track down the issue?

Thanks for your help

SO reference:

Community
  • 1
  • 1
Kyone
  • 513
  • 5
  • 17
  • Have you tried attaching a native debugger, or killing the process with SIGABRT (`kill -6 pid; sleep 1; kill -6 pid`) to get a native stack dump in logcat? It'd be very useful to know where it was stuck. – fadden May 05 '16 at 17:20
  • Hey fadden, thanks for your answer. We did run the game with the native debugger and we realized the it got stuck because of a OpenGL|ES initialization function. Thanks for your help! – Kyone May 10 '16 at 12:38

1 Answers1

0

We figured out that the problem came from a native OpenGL call which was deadlocking.

The takeaway here is to connect your native gdb debugger and break somewhere in your native code to know what's going on.

Kyone
  • 513
  • 5
  • 17