libsdl-org / SDL

Simple Directmedia Layer
https://libsdl.org
zlib License
9.71k stars 1.8k forks source link

SDL3 Android Studio build broken: No implementation found [...] nativeGetVersion() #6854

Closed AntTheAlchemist closed 1 year ago

AntTheAlchemist commented 1 year ago

Something has broken the native links in SDL3 when using Android Studio. I've no idea what I'm looking at really, but I followed the instructions to create a fresh new basic project and the same happens.

12:56:15.127  E  FATAL EXCEPTION: SDLActivity
                 Process: org.libsdl.app, PID: 28789
                 java.lang.UnsatisfiedLinkError: No implementation found for java.lang.String org.libsdl.app.SDLActivity.nativeGetVersion() (tried Java_org_libsdl_app_SDLActivity_nativeGetVersion and Java_org_libsdl_app_SDLActivity_nativeGetVersion__)
                    at org.libsdl.app.SDLActivity.nativeGetVersion(Native Method)
                    at org.libsdl.app.SDLActivity.onCreate(SDLActivity.java:352)
AntTheAlchemist commented 1 year ago

So it just looks like the RegisterNatives haven't been updated to match the SDL3 changes.

1bsyl commented 1 year ago

do you have the adb logcat that happens before ? there are usually some error message. nativeGetVersion is definitively there

AntTheAlchemist commented 1 year ago

The error message is there "No implementation found" because the native symbols haven't been updated to match the changes to the function interfaces made since SDL3.

AntTheAlchemist commented 1 year ago

It's triggered by attempting to call nativeGetVersion from onCreate. No more info needed here.

1bsyl commented 1 year ago

nativeGetVersion is there. in src/code/android/

if some methode failed to register, there is an error message.

maybe your build has stripped the methods

AntTheAlchemist commented 1 year ago

I posted the error message in the first post, there's nothing more. It's not finding some native functions because the interface for them have changed and the symbols passed to RegisterNatives haven't been updated to reflect the changes, so the error posted above is accurate.

1bsyl commented 1 year ago

then try to update RegisterNatives to reflect the changes :)

AntTheAlchemist commented 1 year ago

I've no idea how to submit source changes to SDL, so I usually stick to just reporting the bugs :-)

1bsyl commented 1 year ago

just fix on your side, and tell (in this ticket), the modification to apply : while file, which line to change

AntTheAlchemist commented 1 year ago

just fix on your side, and tell (in this ticket), the modification to apply : while file, which line to change

FYI, my fix wouldn't have worked because the bug was a lot more complicated than that

AntTheAlchemist commented 1 year ago

This still isn't working with the latest source. Am I missing something? SDL2 works fine.

madebr commented 1 year ago

What error(s) are you getting? Yesterday, I built a dummy Android SDL3 application without issues. I used the build-scripts/android-prefab.sh script to create SDL3-3.0.0.aar that I copied to a dummy sdl app. (Due to my lack of knowledge of the gradle build system, it's currently failing to build with SDL2)

Make sure to treat warnings as errors because the compiler might silence critical issues. e.g. SDL_CreateRenderer accepts a const char* as 2nd argument instead of an int that caused me a segfault at first.

AntTheAlchemist commented 1 year ago

@madebr I can't run .sh scripts. I noticed the fix for this was a .sh script to generate the correct code to link to native calls. That only works for Unix users.

I'm using Windows 10 and Android Studio.

The errors I'm getting is in the first post, I cut and pasted the most relevant part, basically Java isn't finding native calls, no need to really know any more than that. The problem is that native calls aren't being linked, it's nothing to do with warnings or deeper errors.

madebr commented 1 year ago

The issue was that no JNI specific symbols were exported from libSDL3.so. Current main exports JNI_OnLoad, which registers all native methods. The error you're describing happens when using a libSDL3.so library that has no exports, thus before the patch.

It would be nice to verify you can build + run my test app. If you can run it, then perhaps you can find out what makes your build system different.

Here is a SDL3-3.0.0.aar for current main. This aar contains the shared library + java source + java classes. Since the aar carries the SDL java sources, you must remove all SDL org.libsdl.app java sources from a project using it.

AntTheAlchemist commented 1 year ago

If I try to build and run your app in Android Studio, it will come up with the same error. I'm literally taking the Gradle project from SDL3 and creating the most basic main.c. It compiles and runs. It crashes and causes a logcat error saying the native function cannot be found. I don't know how many times I have to repeat. I do not have a problem building and running. It's a problem with SDL3 + Android Studio + Native functions not being linked, because gradle doesn't use the .sh script.

madebr commented 1 year ago

The .sh's are for building a SDL3 android archive that you need to include in your build.gradle like this. At no point does any gradle script execute a shell script.

Please provide us with a minimum example showing the issue. Because this looks like a build system issue, I need to see how exactly you're including/building SDL3.

AntTheAlchemist commented 1 year ago

@madebr my build is in android-project. I haven't changed anything. Look there for the problem, hence why I'm posting this. The problem is not on my side or with my source code. If something needs to be included in the build.gradle, then it should be added to the included android-project. Minimum example is in android-project included with the SDL3 source. Just create a dummy.c with main() {} to reproduce. And use Android Studio on Windows 10, not unix.

AntTheAlchemist commented 1 year ago

@madebr to clarify, your solution only works on unix. I am Windows 10 and Android Studio. I cannot run .sh scripts. That's not how SDL works, that's not how the android-project works.

madebr commented 1 year ago

The shell script builds an android archive that users can just dump into their android project, without having to build SDL themselves. I'm striving to make this android archive available on maven central, such that you can simply add org.libsdl.android.sdl to the dependencies section of your build.gradle. The SDL3-3.0.0.aar I posted in the message above is an android archive built this way.

That said, I modified the android-project and it worked just fine. See https://github.com/madebr/SDL/tree/android-sdl-app Tested with Android Studio on Linux. An error with Android Studio on Windows is unlikely.

AntTheAlchemist commented 1 year ago

I'm not saying this again: I'm using Windows 10, so none of that makes any sense to me and only works for unix users. SDLs android project builds from source, not from an archive - your solution has gone way off track.

madebr commented 1 year ago

I'm sorry, but please look at the link I posted above (https://github.com/madebr/SDL/tree/android-sdl-app) and you'll see my modifications is 100% android, nothing unix specific.

Please verify if this project works. If it isn't, then your build system/android installation is at fault.

AntTheAlchemist commented 1 year ago

I'll say it one last time. I don't have a build problem. It builds no problem. It's spitting out a logcat error because the native links are broken. SDL3s gradle project is broken. Try using android-project (and not modifying it) to create an Android Studio project on Windows 10 without running any .sh files and without pre-building any archives and without drawing from any foreign repositories. it does not work.

Keep in mind that SDL2 does work 100%. Therefore it's nothing I am doing, it's specific to a change in SDL3, namely the way native code is linked. The problem was already identified and this bug closed, but it was fixed with a .sh file, which doesn't work for the gradle project. I am not asking for anyone to find the problem.

slouken commented 1 year ago

@AntTheAlchemist, I'll take a look next week.

slouken commented 1 year ago

So I may have fixed this with 21a1508ce. Android.mk now uses a version script to list the exported symbols in the library, and I accidentally removed JNI_OnLoad(). Before this commit I was getting unsatisified link errors when the SDL library was present, and now my SDL3 Android application is working correctly.

@AntTheAlchemist, does this fix it for you?

AntTheAlchemist commented 1 year ago

@AntTheAlchemist, does this fix it for you?

@slouken That's done the trick, thank you!

slouken commented 1 year ago

You're welcome!