Please supply a basic code sample that can be used to reproduce.
Also, if it happens on specific devices please specify which.

In your stacktrace xposed is used.
So maybe caused by xposed?

I might be wrong, but these lines look like they contradict:

Caused by com.badlogic.gdx.utils.GdxRuntimeException
Couldn't load shared library 'gdx' for target: Linux, 32-bit

Caused by java.lang.UnsatisfiedLinkError
dlopen failed: library "/system/lib64/libgdx.so" needed or dlopened by "/system/lib64/libnativeloader.so" is not accessible for the namespace "classloader-namespace"

The first mentioning 32 bit, when the second is looking for 64 bit.

I might be wrong, but these lines look like they contradict:

This is just a nuance of how Android is handled in SharedLibraryLoader

https://github.com/libgdx/libgdx/blob/master/gdx/src/com/badlogic/gdx/utils/SharedLibraryLoader.java#L52-L57

So on an unrelated note, I think that should be fixed.
I'll try to look into it when I'm by a PC.

Ah it seems like these crashes are from more likely from rooted devices according to Firebase report . Some example devices: Mi 9X, Pixel, TaintArt for x86

This is a longer stack trace

Fatal Exception: java.lang.ExceptionInInitializerError
java.lang.Class.newInstance
Caused by com.badlogic.gdx.utils.GdxRuntimeException
Couldn't load shared library 'gdx' for target: Linux, 32-bit
com.badlogic.gdx.utils.SharedLibraryLoader.load (SharedLibraryLoader.java:125)
com.badlogic.gdx.utils.GdxNativesLoader.load (GdxNativesLoader.java:33)
com.badlogic.gdx.backends.android.AndroidApplication. (AndroidApplication.java:60)
java.lang.Class.newInstance (Class.java)
com.android.internal.os.ZygoteInit.main (ZygoteInit.java:779)
de.robv.android.xposed.XposedBridge.main (XposedBridge.java:107)
Caused by java.lang.UnsatisfiedLinkError
dlopen failed: library "/system/lib64/libgdx.so" needed or dlopened by "/system/lib64/libnativeloader.so" is not accessible for the namespace "classloader-namespace"
java.lang.Runtime.loadLibrary0 (Runtime.java:989)
java.lang.System.loadLibrary (System.java:1562)
com.badlogic.gdx.utils.SharedLibraryLoader.load (SharedLibraryLoader.java:119)
com.badlogic.gdx.utils.GdxNativesLoader.load (GdxNativesLoader.java:33)
com.badlogic.gdx.backends.android.AndroidApplication. (AndroidApplication.java:60)
java.lang.Class.newInstance (Class.java)
com.android.internal.os.ZygoteInit.main (ZygoteInit.java:779)
de.robv.android.xposed.XposedBridge.main (XposedBridge.java:107)

So on an unrelated note, I think that should be fixed.
I'll try to look into it when I'm by a PC.

Did you find a fix for this by any chance?

I probably didn't word it well.
I'm gonna look into a fix when I'm by my PC tomorrow.

Although I haven't managed to root my new phone, so IDK how much I'll be able to test it.

Ah it seems like these crashes are from more likely from rooted devices according to Firebase report . Some example devices: Mi 9X, Pixel, TaintArt for x86

This is a longer stack trace

Fatal Exception: java.lang.ExceptionInInitializerError
java.lang.Class.newInstance
Caused by com.badlogic.gdx.utils.GdxRuntimeException
Couldn't load shared library 'gdx' for target: Linux, 32-bit
com.badlogic.gdx.utils.SharedLibraryLoader.load (SharedLibraryLoader.java:125)
com.badlogic.gdx.utils.GdxNativesLoader.load (GdxNativesLoader.java:33)
com.badlogic.gdx.backends.android.AndroidApplication. (AndroidApplication.java:60)
java.lang.Class.newInstance (Class.java)
com.android.internal.os.ZygoteInit.main (ZygoteInit.java:779)
de.robv.android.xposed.XposedBridge.main (XposedBridge.java:107)
Caused by java.lang.UnsatisfiedLinkError
dlopen failed: library "/system/lib64/libgdx.so" needed or dlopened by "/system/lib64/libnativeloader.so" is not accessible for the namespace "classloader-namespace"
java.lang.Runtime.loadLibrary0 (Runtime.java:989)
java.lang.System.loadLibrary (System.java:1562)
com.badlogic.gdx.utils.SharedLibraryLoader.load (SharedLibraryLoader.java:119)
com.badlogic.gdx.utils.GdxNativesLoader.load (GdxNativesLoader.java:33)
com.badlogic.gdx.backends.android.AndroidApplication. (AndroidApplication.java:60)
java.lang.Class.newInstance (Class.java)
com.android.internal.os.ZygoteInit.main (ZygoteInit.java:779)
de.robv.android.xposed.XposedBridge.main (XposedBridge.java:107)

Hello, I have nearly the same problem of that on Mi Note Pro Xposed, I think it may differ in different ROM. In great need of new ROM. But I couldn't even make TaintART compiled. Could you share the TaintART img with me like a googledrive link or sth?

This seems to be a Problem with the mapping in line:

Properties p = System.getProperties();
Enumeration keys = p.keys();
while(keys.hasMoreElements()) {
   String key = (String) keys.nextElement();
   String value = (String) p.get(key);
   System.out.println(key + " >>>> " + value);
}

I'm also seeing numerous reports of this crash, all of them of Google Pixel devices (distributed across various models: Pixel, Pixel 2, Pixel 2 XL, Pixel 3, Pixel 3 XL) all running Android 10. None of these devices are rooted.

@EtK2000 could this be related to #5795?
@vminc are you using Android App Bundle?

No reaction, so probably this is no issue any more.

I used ubuntu and run on android emulator. It crashed with the same logs of the first post. Any insights here?

libgdx is 1.9.13

I'm also seeing this issue with libgdx 1.10.0

Without knowing the root cause, this is impossible to fix. @jonatino have you tried the debugging steps provided above and checked whether this is related to the issue described in #5795? Are you using Android App Bundles?

Re the recent comments (not OP because it sounds like they have an app in production with only certain devices affected):
Dunno if related, but in some circumstances you may have to first run the android:copyAndroidNatives Gradle task or else the app will be missing libgdx.so and any other native libraries. I had that before with a gdx-liftoff project but now it works without, so ¯\_(ツ)_/¯

@Frosty-J @crykn that was very close to what my problem was. The android:copyAndroidNatives was copying the libgdx.so fine, but it was not copying the accompanying natives-x86.jar.

Any way to make this error a little less misleading? Initial impression I assumed it was the .so file due to the nature of the error.

Well natives-x86.jar and the equivalent versions for other CPU architectures (most modern Android devices use arm64-v8a) contain libgdx.so. I don't believe there's any reason to copy the JAR itself.

Hi, sorry for writing in this "old" issue, but I think this issue is still not solved.
We are using the libGDX version 1.11.0, and in ALL of our games we have some significant number of crashes in the Google Play Console (and crashlytics) with the error:

Caused by java.lang.UnsatisfiedLinkError
dlopen failed: library "libgdx.so" not found
com.badlogic.gdx.utils.SharedLibraryLoader.load

Yesterday we released a new update of a game (only 10% staged rolled update) and araised quite a lot errors, that on previous version didn't appear (it was using the previous libGDX v1.10.0)

Investigating this issue we found that it afected mostly the device : OnePlus 8 Pro

Very strange... maybe this device in particular has not the "Android Runtime" string in the property "java.runtime.name"
Anyways I think the way to detect that we are on an Android device OS is not working in all cases: PR:(#5897)

Maybe there should be some alternate way to "force" the Android loading of the .so file.
Or just check if contains the "Android" string.

PD: I am using the Bundle format.

Hi everybody, I am facing the same problem. I saw the issue was closed, did we receive fixes for it? Thank you.

No, looks like it was closed for inactivity rather than being fixed. Sadly, I don't have access to any of the aforementioned devices for testing, nor the power to reopen the issue.

Hi @Frosty-J, thanks so much for your rapid reply. It's sad but hopefully, the issue can be addressed in the next release.

This can only be fixed if someone is able to reliably reproduce this issue. Have you tried any of the fixes and debugging steps mentioned above?

Hi @crykn, thanks for your suggestion. Now I can see your mentioned solution, I will try to find a way to test it since I don't have the device which caused the issue.

I has the same issue in my fresh game using libgdx 1.12.1, so this issue is still not solved.

I can add the code from this suggestion #5863 (comment) in my next release, and try to give you more info. Is this suggestion is still actual?

I'll reopen this because even if I'm skeptical it can be fixed, it's still present (and has been for many years).

First thing to note is that, even if this is by far my most common crash (and has been like that for years) with 150+ unique users with this error and over 600 crahes in Firebase on the last 90 days in one of my games I've never seen a review complaining about it or direct email to complain about which suggests this is only happening to some kind of user that's doing something non standard.

In my experience the model/brand of devices, OS version and rooted device percentage distribution of the crashes suggests a majority are most likely occurring to users that did not download the game from Google Play. The most likely cause for this issue is that they downloaded the wrong architecture from an alternative store and when it crashes they just assume the APK is corrupted or something like that and move on.

What we could do to try to confirm this theory to add more information to the Exception message of SharedLibraryLoadRuntimeException but I wouldn't be too worried about it.

Hi, A few comments about this issue:

1- Yes, I can confirm that as today in libGDX version 1.12.1 this issue is still present in all my games

(I commented on this issue some months ago)

2- As @obigu said I never had a complaint or negative comment about this error. And affects a very small percentaje of users (maybe rooted devices).

3- This issue is reported both from GooglePlay console and Firebase Crashlytics

Caused by com.badlogic.gdx.utils.SharedLibraryLoadRuntimeException: Couldn't load shared library 'gdx' for target: Android
  at com.badlogic.gdx.utils.SharedLibraryLoader.load (SharedLibraryLoader.java:128)
  at com.badlogic.gdx.utils.GdxNativesLoader.load (GdxNativesLoader.java:30)

4- I have no clues or tips on how to avoid or minimize this error. I have dedicated some hours to investigate it without success :(

My theory is that the "Android apk/aab loader" doesn't match the correct library (architecture) folder:

I got stuck in the Runtime.loadlibrary0 () function

#5863 (comment)

Could somebody of you run the following snippet inside the Launcher's create method before creating the new AndroidApplication(...) statement and provide the output here?:

I did it and received crash with result, but don't know how it can help.
Here the output:

key=http.agent,	value=Dalvik/2.1.0 (Linux; U; Android 8.1.0; Nexus 5X Build/OSM1.180201.031)
key=java.io.tmpdir 	value=/data/user/0/com.mygame/cache
key=user.home 	value=

I checked this in other crashes, and it's looks similar. key=user.home is empty.

#5863 (comment)

Could somebody of you run the following snippet inside the Launcher's create method before creating the new AndroidApplication(...) statement and provide the output here?:

I did it and received crash with result, but don't know how it can help. Here the output:

key=http.agent,	value=Dalvik/2.1.0 (Linux; U; Android 8.1.0; Nexus 5X Build/OSM1.180201.031)
key=java.io.tmpdir 	value=/data/user/0/com.mygame/cache
key=user.home 	value=

I checked this in other crashes, and it's looks similar. key=user.home is empty.

It appears Android doesn't return all system properties when calling System,getProperties(), you can easily test it locally.

Having a look at the System class it looks like it separates between unchangeable and changeable system properties and the only ones retrievable as a list are the changeable ones (just those 3 instead of 44 in my case). The solution is to request the system properties you want manually. In this case the most important is java.runtime.name but the more info you have on the system the higher the chances to understand what kind of devices are failing.

Checking the documentation on the list of system properties on Dalvik it looks like java.runtime.name is not listed to always guarantee to be returned which is strange https://developer.android.com/reference/java/lang/System#getProperties().

I think i don't userstand the exact problem.
The crash (crashytics) is in SharedLibraryLoader line 122:

But the error message "detects" the Android flag (watch selected Exception lines:

Caused by com.badlogic.gdx.utils.SharedLibraryLoadRuntimeException: Couldn't load shared library 'gdx' for target: Android
at com.badlogic.gdx.utils.SharedLibraryLoader.load (SharedLibraryLoader.java:128)
at com.badlogic.gdx.utils.GdxNativesLoader.load (GdxNativesLoader.java:30)

So the problem don't seems to be in the checking of the "Android Runtime" in the System properties...
What I am missing?

I also started experiencing this issue recently. It began to occur a few months ago, and only now I got a few free hours to double down on it and get it fixed.

Turns out, the native .so libs were indeed not present in my APK. I verified like this:

1. ./gradlew :android:assembleDebug

2. cd ./android/build/outputs/apk/debug/

3. apktool d android-debug.apk

4. Notice is no lib directory, and .so files aren't present

   $ ls -F android-debug
   AndroidManifest.xml  assets/              res/                 smali_classes2/      smali_classes4/
   apktool.yml          original/            smali/               smali_classes3/      unknown/
   

Now, perform the fix, and then perform the steps above again. You'll notice that now there'll be the lib directory in the decompiled APK, and inside it - the files that were missing.

$ ls -F android-debug
AndroidManifest.xml  assets/              original/            smali/               smali_classes3/      unknown/
apktool.yml          lib/                 res/                 smali_classes2/      smali_classes4/

$ tree -F android-debug/lib
android-debug/lib/
├── arm64-v8a/
│   ├── libgdx-freetype.so
│   └── libgdx.so
├── armeabi-v7a/
│   ├── libgdx-freetype.so
│   └── libgdx.so
├── x86/
│   ├── libgdx-freetype.so
│   └── libgdx.so
└── x86_64/
    ├── libgdx-freetype.so
    └── libgdx.so

In my case, it was happening because the :android:copyAndroidNatives task was never executed, because it was always UP-TO-DATE. Here's an SO answer that explains it in more detail.