Crash due to onLoadNativeLibraries for some users

Crash due to onLoadNativeLibraries for some users
0

We recently released a game using c++ Cocos2d-X on Android. I am getting a crash from a very small number of users while loading the native libraries.

It crashes in “Cocos2dxActivity.java” at

System.loadLibrary(libName);

This is the error that it gives:

Fatal Exception: java.lang.UnsatisfiedLinkError

dalvik.system.PathClassLoader[DexPathList[[zip file “/data/app/(REDACTED MY BUNDLE ID)-1/base.apk”],nativeLibraryDirectories=[/data/app/(REDACTED MY BUNDLE ID)-1/lib/arm, /data/app/(REDACTED MY BUNDLE ID)-1/base.apk!/lib/armeabi, /vendor/lib, /system/lib]]] couldn’t find “libMyGame.so”

I can’t understand why this would only happen on some users devices. It also seems to happen on a variety of different devices and versions of Android. Any help would be greatly appreciated!

Thanks,
David

1 Like

That error simply means that it can’t find the required library files to load.

Are those users running on very old phones or old versions of Android that don’t support armeabi-v7a? The reason I ask is because the device is trying to load a library based on armeabi, which is deprecated, and shouldn’t be used.

The most recent crash with this was on a Nexus 5X (running Android 6.0.1) which was released about 4 years ago, but Wikipedia has listed as 64-bit ARMv8-A. Can you think of any reason it would be looking for older versions?

That is really odd, since it shouldn’t be looking for the armeabi architecture libraries. How are you building the Android version of your application?

If you are using CMake, then check what architectures you’ve specified in your gradle.properties. It should be something like this:

PROP_APP_ABI=armeabi-v7a:arm64-v8a

If you’re still using the ndk-build method, then what is the setting for the APP_ABI in your /proj.android/app/jni/Application.mk file?

It should be like this if I recall correctly:
APP_ABI := armeabi-v7a arm64-v8a

EDIT: Open up the APK file in WinZIP/WinRAR or similar app, and check the contents of the library folders.

Also, are you sure those users aren’t running your application in 32bit mode emulators, those that just happen to have the hardware ID set to whatever device they want to be reported (like Nexus 5X)? You could easily test this by creating an emulator with the same spec using the armeabi Android 6.0.1 image, to see what data it sends in your crash reports.

My Gradle.properties file is set to:

PROP_APP_ABI=armeabi-v7a;arm64-v8a;x86

Extracting the .aab file I uploaded to Android I actually have all the platforms including x86_64 and armeabi folders. It appears they were made because the crashylitics .so file was added to them for those platforms. Perhaps the availability of those folders is causing issues? That being said, one of the reasons I added crashylitics recently was to find these bugs, so I think that was present even before I added crashylitics.

The only thing I can think of is that the crash reports are coming from 32bit mode Android emulators, but perhaps someone else here may have a better idea. Have you compared the number of Nexus 5X devices that run your app vs the number crashes you’re getting? (or any other device that happens to be reporting crashes). If the majority of those devices with the same Android version are not crashing, then something is definitely a little suspect about the ones that are crashing.

So I’ve been collecting more data on this crash over the last few days from crashylitcs and through the Play Store. They both tell a slightly different story. Crashylitics is saying its all coming from jailbroken devices and all different users, but shows them all as the same Nexus type device. Play shows two different crashes, but they are coming from desktops, with one being a 64 bit x86. There is also another crash which is exclusively rooted devices. I’m not sure what’s going on here, but after seeing this in both consoles, I think its very isolated and someone doing something with my binary that it is not intended to be used for. Wish it were not contributing to my crash rate in Google Play, but I think I am going to leave this to rest unless I get more clues. Thanks for the help!

It is extremely disappointing if Google is actually using crash reports from rooted devices to judge the reliability of your app. Take this scenario, if a bad actor decides to destroy the Google store rating of an app, then they can do so through rooted devices… that’s a major loophole if it is in fact the case.

After using ReLinker to load native lib I have much less such crash reports.

1 Like