We are currently migrating Bugzilla to GitHub issues.
Any changes made to the bug tracker now will be lost, so please do not post new bugs or make changes to them.
When we're done, all bug URLs will redirect to their equivalent location on the new bug tracker.

Bug 1383 - Implement Android on top of native glue
Summary: Implement Android on top of native glue
Status: ASSIGNED
Alias: None
Product: SDL
Classification: Unclassified
Component: *don't know* (show other bugs)
Version: HG 2.0
Hardware: ARM Android (All)
: P2 normal
Assignee: LCID Fire
QA Contact: Sam Lantinga
URL:
Keywords:
: 1466 (view as bug list)
Depends on:
Blocks:
 
Reported: 2012-01-20 10:43 UTC by LCID Fire
Modified: 2015-09-07 01:33 UTC (History)
7 users (show)

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description LCID Fire 2012-01-20 10:43:44 UTC 
Google does provide a native glue (see android_native_app_glue.h) for Android so it seems it is not necessary to implement that much in Java to bootstrap SDL.
Also since the *Sensor* support is not fixed, it would be easier if most of the code was implemented in C so it can be easier extended.
Another reason can be that letting the VM do as less in Java as possible, could be better for its memory imprint.

I'll probably start to port the current state, because I also need Sensors access.
Comment 1 Sam Lantinga 2012-01-20 20:07:05 UTC 
The last time I looked there wasn't a significant advantage in using native code, since it was still new and less flexible than the Java code, but that may have changed in the last year.

Go for it!
Comment 2 LCID Fire 2012-01-24 12:36:26 UTC 
The first code landed.
http://code.google.com/p/android-sdl-native/

The question to me is how to support some advanced features like
- OpenSL ES
- Sensors
Comment 3 Gabriel Jacobo 2012-05-25 07:36:53 UTC 
*** Bug 1466 has been marked as a duplicate of this bug. ***
Comment 4 Matthew Huck 2012-07-23 15:18:42 UTC 
I've got a working libSDL2 with native activities, no sensors yet, but that wouldn't be hard to add since it's demonstrated in the native activity code from google.  I've implemented it as a separate platform alongside the JNI android platform (it's called android_native).  It's built using cmake, and android ndk-r8 at the moment (just because we use cmake for all our other projects, and extern dependancies so cross compiling is easy).

How would you like to see what I've done?
Comment 5 Denis Bernard 2013-10-08 16:02:48 UTC 
@Matthew_Huck I would very much like to see your implementation. Thanks !
Comment 6 Ryan C. Gordon 2015-02-19 05:22:20 UTC 
Marking a large number of bugs with the "triage-2.0.4" keyword at once. Sorry if you got a lot of email from this. This is to help me sort through some bugs in regards to a 2.0.4 release. We may or may not fix this bug for 2.0.4, though!
Comment 7 Ryan C. Gordon 2015-02-19 05:24:18 UTC 
Whoops, that shouldn't be part of triage-2.0.4.

--ryan.
Comment 8 terry_yu 2015-09-07 01:33:53 UTC 
(In reply to Matthew Huck from comment #4)
> I've got a working libSDL2 with native activities, no sensors yet, but that
> wouldn't be hard to add since it's demonstrated in the native activity code
> from google.  I've implemented it as a separate platform alongside the JNI
> android platform (it's called android_native).  It's built using cmake, and
> android ndk-r8 at the moment (just because we use cmake for all our other
> projects, and extern dependancies so cross compiling is easy).
> 
> How would you like to see what I've done?

Hi, @Matthew_Huck can you send me ur implementation about this(a working libSDL2 with native activities), my email is yzy0@yeah.net, thx!!