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 2378 - No graceful exit on Androids
Summary: No graceful exit on Androids
Status: RESOLVED FIXED
Alias: None
Product: SDL
Classification: Unclassified
Component: main (show other bugs)
Version: 2.0.1
Hardware: All Android (All)
: P2 major
Assignee: Gabriel Jacobo
QA Contact: Sam Lantinga
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-02-02 18:38 UTC by Peter Jankuliak
Modified: 2014-02-03 14:19 UTC (History)
3 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Peter Jankuliak 2014-02-02 18:38:29 UTC
Currently it seem to be recommended that developers call ::exit(0)
at the end of their SDL_main function. See e.g. the first Android tutorial
linked from the wiki page: http://www.dinomage.com/2013/01/howto-sdl-on-android/.

The main problem with this workaround is when the app needs to run some services
even after the main activity has finished. The situation right now is this:

If SDL_main finished and exit is not called, the SDLActivity stays active
but to the user app appears as if it's frozen (because the native main loop is no longer running).

If SDL_main finishes and it does call exit, it prevents the SDLActivity from
finishing gracefuly and if there are any android services still active, they
are all wiped out.

I think the correct solution to this would be to do a JNI call SDLActivity.finish() from inside

Java_org_libsdl_app_SDLActivity_nativeInit(...)

right after the SDL_main is done executing.

Unfortunately for this to work, another bug needs to be fixed. That is, after
the SDL_main function exits, the SDLActivity should not do any more native calls. From what I've tested, it was enough to set a boolean flag inside the
SDLActivity.onDestroy and then exit immediately in function
SDLActivity.surfaceDestroyed if this flag is set.

There is no such flag in the 2.0.1 release, but the latest code in the repo has
boolean SDLActivity.mExitCalledFromJava which get's set in the onDestroy
function so it can be used for this purpose (though I think mActivityDestroyed would be more appropriate name for it).
Comment 1 Gabriel Jacobo 2014-02-03 12:48:16 UTC
1) We recommend that you don't call exit from native code. This will terminate both the native and Java threads immediately.
2) We call SDLActivity.finish here: https://hg.libsdl.org/SDL/file/b9b66e0a8250/android-project/src/org/libsdl/app/SDLActivity.java#l182

Having said that, and assuming you are using the default SDLActivity.java and that you are exiting your native loop *without* calling exit, what's the buggy behaviour you are experiencing?
Comment 2 Peter Jankuliak 2014-02-03 14:18:18 UTC
I have previously only tested with the 2.0.1 release, where the SDLActivity.finish wasn't called. When I inspected the latest code in mercurial I've missed the trick with another thread waiting for the main one to join and then calling the SDLActivity.finish function.

So I've now tested with the latest code from the repo and the issue seems to have been resolved.

For completeness I'll try to describe the buggy behavior in 2.0.1

Say an SDL application is running its main loop and renders to screen. Then for some reason (e.g. user pressed an 'in-game' quit button) the main loop finishes and SDL_main quits without calling the the exit function. Now we're in a state where the SDLActivity doesn't know the main loop has ended and is still pushing events to the SDL event queue. The latest frame from when the main loop was still running is still on the screen but nothing ever happens from this point on so the app appears frozen. 

Regards
Comment 3 Gabriel Jacobo 2014-02-03 14:19:18 UTC
Awesome, thanks!