Closed AntTheAlchemist closed 1 year ago
So it just looks like the RegisterNatives haven't been updated to match the SDL3 changes.
do you have the adb logcat that happens before ? there are usually some error message. nativeGetVersion is definitively there
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.
It's triggered by attempting to call nativeGetVersion from onCreate. No more info needed here.
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
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.
then try to update RegisterNatives to reflect the changes :)
I've no idea how to submit source changes to SDL, so I usually stick to just reporting the bugs :-)
just fix on your side, and tell (in this ticket), the modification to apply : while file, which line to change
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
This still isn't working with the latest source. Am I missing something? SDL2 works fine.
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.
@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.
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.
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.
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.
@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.
@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.
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.
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.
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.
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.
@AntTheAlchemist, I'll take a look next week.
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, does this fix it for you?
@slouken That's done the trick, thank you!
You're welcome!
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.