Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

No graceful exit on Androids #1337

Closed
SDLBugzilla opened this issue Feb 10, 2021 · 0 comments
Closed

No graceful exit on Androids #1337

SDLBugzilla opened this issue Feb 10, 2021 · 0 comments

Comments

@SDLBugzilla
Copy link
Collaborator

This bug report was migrated from our old Bugzilla tracker.

Reported in version: 2.0.1
Reported for operating system, platform: Android (All), All

Comments on the original bug report:

On 2014-02-02 18:38:29 +0000, Peter Jankuliak wrote:

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).

On 2014-02-03 12:48:16 +0000, Gabriel Jacobo wrote:

  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?

On 2014-02-03 14:18:18 +0000, Peter Jankuliak wrote:

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

On 2014-02-03 14:19:18 +0000, Gabriel Jacobo wrote:

Awesome, thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant