| Summary: | Improvement to android port | ||
|---|---|---|---|
| Product: | SDL | Reporter: | lennie.araki |
| Component: | main | Assignee: | Sam Lantinga <slouken> |
| Status: | RESOLVED WONTFIX | QA Contact: | Sam Lantinga <slouken> |
| Severity: | enhancement | ||
| Priority: | P2 | CC: | gabomdq, philipp.wiesemann |
| Version: | 2.0.1 | ||
| Hardware: | All | ||
| OS: | Android (All) | ||
| Attachments: | SDL2 patch file | ||
The patch modifies a Visual Studio project file. Is this needed for the Android changes? Also it includes several copies of SDLActivity.java. Is simply extending SDLActivity class as documented in README-android.txt not working here? If it is not working maybe the related comments should be removed from the new AndroidManifest.xml files because they are no longer valid there (e.g. package was replaced). Yes you can still build your project that way (but then you have to copy or symlink SDLActivity.java + create another java source file with your own unique com.company.app extending this class). If you prefer to do it this way you can just leave SDL_PREFIX undefined and it will behave exactly as before but I build on windows using MSYS mingw which does not support symlinks (so I didn't want to keep copying all the source files). Typically an app or game will want to customize the android resources (icons, permissions, etc) and additionally you often need to change the SDLActivity (e.g. modules loaded: SDL_audio, SDL_ttf, external libraries). Yes probably good to remove the (old) comments in there - I just copied and pasted the files and made the minimal edits for them to compile... The changes to the Visual Studio project are to build the other examples (which aren't built by the default included project) to test that the code is truly cross platform. Lennie (In reply to lennie.araki from comment #2) > Yes you can still build your project that way (but then you have to copy or > symlink SDLActivity.java + create another java source file with your own > unique com.company.app extending this class). But having five additional copies of the same file without automatic synchronization (by script or symbolic link) is somehow a maintenance problem. Maybe the main SDLActivity.java could just be linked in the projects' build files. Or something like androidbuild.sh (from SDL's build-scripts) could be created (which I though was enough for simple test programs, just assets need to be moved/linked). You can't just refer to the .java file as it has the package hardcoded in the source and to its path. I can create a shell script using sed to modify the files if you'd prefer that. If we go to this approach I suggest modifying the "source" SDLActivity.java and android manifest file, etc. to make it easier to automate (e.g. take out all the comments telling you to modify it). Again the main advantage of doing this is to build/test *all* the samples. With the default android-project build method (which you copy manually the android-project "template") unless you edit these files and paths by hand you can only install them one at a time (they overwrite each other since they are all "org.libsdl.app") The build-scripts/androidbuild.sh script takes care of building the tests automatically without need of having multiple SDLActivity files We solved this by making it easy to subclass the SDL Activity for your needs. |
Created attachment 1556 [details] SDL2 patch file We are using SDL 2.x to port an application to Android/OUYA. In the process we generalized the build process to eliminate the dependency on org_libsdl_app (for Native functions called from Java) using macros: #ifndef SDL_PREFIX #pragma warning Defaulting to org.libsdl.app #define SDL_PREFIX org_libsdl_app #endif #define CONCAT1(p,f) CONCAT2(p,f) #define CONCAT2(p,f) Java_ ## p ## _ ## f #define JNI(f) CONCAT1(SDL_PREFIX,f) used as follows: -void Java_org_libsdl_app_SDLActivity_onNativeResize( +void JNI(SDLActivity_onNativeResize)( I also added and enhanced (android) projects for: drummix fireworks spritetest2 testgles testjoystick Also uses a SDL2_HOME environment variable to eliminate the symbolic link (not supported by MSYS mingw) Lennie