Couldn't load shared library 'gdx' for target

后端 未结 4 924
没有蜡笔的小新
没有蜡笔的小新 2021-01-18 17:18

I\'m having the same issue as in this question, but the answers there doesn\'t solve my problem.

I didn\'t create project by gdxsetup.jar, I just included gdx.jar an

相关标签:
4条回答
  • 2021-01-18 17:32

    I found out this is pretty simple : add

    static { System.loadLibrary("gdx");}
    
    0 讨论(0)
  • 2021-01-18 17:37

    The problem I had was that for some reason libgdx.so was not copied to any of the armeabi, armeabi-v7a or x86 folders in the android project's lib folder.

    Copying these over from the libgdx distribution worked for me.

    0 讨论(0)
  • 2021-01-18 17:38

    My problem was that I was trying to make my GDX app within a shared library (aka, not the thing that gets compiled into an APK), but hadn't finished setting up all the GDX-including stuff in my lib.

    So I had:

    MyProject
    -->MyMainApp
    -->-->build.gradle <-- no updates required, doesn't do anything with GDX
    -->MySharedLibraryWhereMyGameEngineIs
    -->-->build.gradle <-- this is where the problem was
    

    In the shared lib's build.gradle, I hadn't included the sourceSets parameter.

    Adding it fixed my problem. GDX now starts up successfully.

    apply plugin: 'com.android.library'
    android {
        ... config stuff ...
    
        sourceSets {                       // this wasn't here before
            main {                         // this wasn't here before
                jniLibs.srcDirs = ['libs'] // this wasn't here before
            }                              // this wasn't here before
            instrumentTest.setRoot('tests')// this wasn't here before
        }     
    
        ... a bunch of other config stuff ...
    }
    
    0 讨论(0)
  • 2021-01-18 17:51

    I actually just faced the same problem after I uploaded by first update to my app ("October Bro"). While the first release has been run perfectly when installed from the Play Store, the update crashed right after launching. Checking Logcat, I exactly have been facing this issue.

    The reason why my first release worked without a problem, but not the update was simple: because I only wanted to fix a minor bug, I checked out the project from GitHub, only ran the Desktop app once to verify the fix, and then created the signed AppBundle right away. It looks like I simply had to run the "android" run configuration at least once, before creating the AppBundle. Or to be more precise, the build.grade of the android module, which performs these tasks:

    // android/build.gradle
    
    ...
    
    // called every time gradle gets executed, takes the native dependencies of
    // the natives configuration, and extracts them to the proper libs/ folders
    // so they get packed with the APK.
    task copyAndroidNatives {
        doFirst {
            file("libs/armeabi/").mkdirs()
            file("libs/armeabi-v7a/").mkdirs()
            file("libs/arm64-v8a/").mkdirs()
            file("libs/x86_64/").mkdirs()
            file("libs/x86/").mkdirs()
    
            configurations.natives.files.each { jar ->
                def outputDir = null
                if (jar.name.endsWith("natives-arm64-v8a.jar")) outputDir = file("libs/arm64-v8a")
                if (jar.name.endsWith("natives-armeabi-v7a.jar")) outputDir = file("libs/armeabi-v7a")
                if(jar.name.endsWith("natives-armeabi.jar")) outputDir = file("libs/armeabi")
                if(jar.name.endsWith("natives-x86_64.jar")) outputDir = file("libs/x86_64")
                if(jar.name.endsWith("natives-x86.jar")) outputDir = file("libs/x86")
                if(outputDir != null) {
                    copy {
                        from zipTree(jar)
                        into outputDir
                        include "*.so"
                    }
                }
            }
        }
    }
    

    I thought that this android/build.gradle is executed anyways once I hit Build > Build Bundle(s) / APK(s). But that does not seem to be the case.

    0 讨论(0)
提交回复
热议问题