The SDL forums have moved to discourse.libsdl.org.
This is just a read-only archive of the previous forums, to keep old links working.

I am submitting a patch for inclusion that improves the build process,
usage process, and quality of the binaries for Android. (It does
contain some code fixes too.)

My repo may be found here:
https://bitbucket.org/ewing/sdl_android_cleanup


This patch makes it possible to build SDL using CMake.
- This attempts to leverage a lot of the existing infrastructure which
hopefully ensures correctness and enables optimizations (e.g.
architecture specific optimizations)
- Additionally, the build process is geared so it is possible and easy
to distribute SDL binaries for Android (for armeabi, armeabi-v7a, x86)
which should vastly improve the user experience.
- I also have a working libSDLmain.so.

I also have posted separate example projects of how to use prebuilt
binaries using the official NDK external module system
(NDK_MODULE_PATH). I have one example done in Ant, and the other in
Gradle. Unfortunately, we are in this sucky transition period where
Google is ditching Ant/Eclipse for Gradle/Android Studio, and the NDK
support is still a disaster.

The external projects can be found at:
https://bitbucket.org/ewing/helloandroidsdl-ant
https://bitbucket.org/ewing/helloandroidsdl-gradle
Also, the download page for each project contains the prebuilt Android
SDL binaries I built. So you can download them and test. (Eventually,
we should be able to do official binary releases.)
I would eventually like to deprecate/remove the existing project
template and either put these in its place, or just put documentation
on how users can create their own projects (because there isn't that
much infrastructure needed once you have prebuilt external SDL
libraries in the external NDK module system).



There is a lot of information to cover. I'm sure it will be
information overload. Android development sucks in general so expect
this to be painful. My goal in doing this is to make everybody's lives
less painful on Android because what I have now is a significant
improvement believe it or not. This is the 4th real world project I've
done through this (Chipmunk, ALmixer, JavaScriptCore, the latter being
absolute hell) so I'm pretty confident about all this. (This is the
first time I've tried Gradle though.)



There is a README-AndroidCMake.txt in build-scripts which discusses
how to build SDL using Android-CMake. (Note: I require the use of the
Android NDK 'standalone toolchain').

My Android.mk contains additional information on how to use the
NDK_MODULE_PATH system because the Google documentation is terrible.

My external example projects both contain README.txt files on how to use them.


Areas of discussion I would like to have:
- About the SDLmain and hardcoded libMySDLMainActivity.so name. I
think we could make this more flexible by making it possible to pass
the library name through the nativeInit() function as an extra
parameter. (I think another fair discussion is if SDLmain was really
worth it.)

- Also, my binaries are built with -Os. I did a little, but not much
performance testing. I didn't see any difference in speed using -Os,
so I think this should be the default (which is what I committed in my
helper scripts).

- How to improve the project templates (like is there a way we can
make an actual project template in Android Studio?)


Please feel free to ask questions.


My commit log message is pasted below for convenience:

The goals of this Android-CMake patch are to:
- Build SDL correctly
- Build SDL for all the proper Android architectures (currently
armeabi, armeabi-v7a, x86)
- Build SDL for Android with the best optimizations and features enabled
- Build an External NDK Module (distributable binaries) suitable for
everybody to use so everybody doesn't have to build SDL from scratch
- Leverage a single/correct/authoritive build system to minimize
accidental differences in the build process or from one system getting
neglected/stale
- Simplify things

See the build-scripts/README-AndroidCMake.txt for more information.

Here are some interesting code related areas concerning this patch:

- I removed the -O3 from the CMake script. This is the wrong thing to
do because it clobbers anything specified by the CMake build type.

- SDLmain now works but has caveats:

-- libSDLmain.a doesn't work because it is dropping the symbols during
linking. I think the problem is that since we need to build a .so on
Android instead of an app, linking libSDLmain.a causes unused symbols
to be disregard

--- I noticed the libSDLmain.a is always built for every platform.
This should be reconsidered, but I didn't change it.

-- libSDLmain.so is provided as an alternative. But this required some
fancy dancing with SDL_LoadObject/SDL_LoadFunction to defer symbol
resolution to runtime because there is no SDL_main yet when we build
libSDLmain.so.

--- Additionally, we need to hard code the name of the user .so. I
have picked libMySDLMainActivity.so to help disambiguate any confusion
between the user's stuff and the libSDLmain.so we provide.

- JNIEXPORT / JNICALL needed to be used for all our JNI bridge
functions because CMake is using symbols=hidden by default. This is
correct thing to do anyway, and shrinks binary size and improves
calling performance.

- SDL_Android_Init gave me a lot of trouble because this also needs to
be exported now that we have a libSDLmain that must call private stuff
in the libSDL2 library. This symbol must be exported, but for reasons
I don't understand, the standard DECLSPEC macros didn't work for me.
So I just used gcc visibility attributes directly.

- I removed the use of SDL_internal.h in the SDL_android_main.c. It's
bad since that lives outside SDL. It also appears it is unneeded.


- There seems to be a bug in the Find Pthreads module for CMake where
it was using check_c_source_runs instead of check_c_source_compiles.
(The former will never work in a cross-compiled environment.)

- I bundled a copy of my version of the android.toolchain.cmake. It is
a fork from the one OpenCV posted. I made a lot of fixes to it. I
haven't yet figured out if they are still maintaining it and if we
can/should merge.



Thanks,
Eric
--
Beginning iPhone Games Development
http://playcontrol.net/iphonegamebook/
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org