SDL2 Android - Exiting

Thanks for the link and the feedback.

So the general rule would be to not exit the native app part manually,
but only rely on SDL_QUIT event, right?

Let SDL do the onDestroy stuff and handle SDL_APP_TERMINATING or
SDL_APP_WILLENTERBACKGROUND to shut everything down or save things.

So hitting the home or power button will let SDL pause the app
internally, no need to worry about and will resume it automatically,
too. Having the app “killed” then is up to Android itself. The only
things that annoys me is the bad feeling about letting the app run
forever until a system component that I don’t have any control on will
do it at some magic time. But I will still give it a try in the next
release.

Thanks all.
Regards
MartinAm 06.01.2014 10:05, schrieb hardcoredaniel:

Hi,

according to this

http://developer.android.com/reference/android/app/Activity.html#ActivityLifecycle

an app shall just follow the lifecycle. Whether the VM is actually
shut down or not shall be left up to the system (typically only on low
memory). Just make sure that you clean up after onDestroy() such that
a call to onCreate() restores everything, just as if the VM was really
terminated in between.

Actually the VM of the app can be forcibly terminated on low memory
anytime after the onPause() call, so saving all relevant data should
be done at onPause() time. In onDestroy() you just tear down
everything so that another onCreate() will be successful in case the
VM was not terminated.

Anyway, that’s the theory (as far as I understand it). I’m not sure
that every device actually behaves like this :slight_smile:

Regards,

Daniel

Hi,

I don’t know too much about SDL in detail, so I can’t say anything about
these events.

Under the hood, SDL for Android has a “Java” and a “Native” part.

The Java part handles the Android lifecycle. So in case your app is put into
background, the onPause() callback arrives. SDL should now tell the native
part to pause executing (and maybe save important data in case the app will
be killed). Upon onResume() SDL shall also resume the native thread.

In case the onDestroy() callback is called, SDL can tear down everything and
prepare for a (possible) new start of the app.

If the app was killed after onPause() - well, no need to worry about exiting
:slight_smile:

Whenever the app is paused, it should not consume CPU, i.e. everything
should just sit idle and wait to be woken up again by an event (like
onResume()).

The only special case to SDL is that your application “payload” (your game
or whatever) does no longer want to run, say from a user dialogue “Do you
really want to quit playing?”. In this situation, it makes no sense just to
pause the app (upon resuming you would still be in the state “post-I-wanted-
to-quit”), but you really want it to reach the same state where it is upon
onDestroy(), waiting to be started again or killed.

For that, the Java part of SDL will send a “finish()” request to the Android
system, as soon as the native thread is finished, i.e. SDL_main() returns.
So when the native thread exits normally, the app will enter the onDestroy()
state automatically.

Regards,

Daniel

---------- P?vodn? zpr?va ----------
Od: Martin Gerhardy <martin.gerhardy at gmail.com>
Datum: 6. 1. 2014
P?edm?t: Re: [SDL] SDL2 Android - Exiting

"Am 06.01.2014 10:05, schrieb hardcoredaniel:

Hi,

according to this

http://developer.android.com/reference/android/app/Activity.html#
ActivityLifecycle

an app shall just follow the lifecycle. Whether the VM is actually
shut down or not shall be left up to the system (typically only on low
memory). Just make sure that you clean up after onDestroy() such that
a call to onCreate() restores everything, just as if the VM was really
terminated in between.

Actually the VM of the app can be forcibly terminated on low memory
anytime after the onPause() call, so saving all relevant data should
be done at onPause() time. In onDestroy() you just tear down
everything so that another onCreate() will be successful in case the
VM was not terminated.

Anyway, that’s the theory (as far as I understand it). I’m not sure
that every device actually behaves like this :slight_smile:

Regards,

Daniel

Thanks for the link and the feedback.

So the general rule would be to not exit the native app part manually,
but only rely on SDL_QUIT event, right?

Let SDL do the onDestroy stuff and handle SDL_APP_TERMINATING or
SDL_APP_WILLENTERBACKGROUND to shut everything down or save things.

So hitting the home or power button will let SDL pause the app
internally, no need to worry about and will resume it automatically,
too. Having the app “killed” then is up to Android itself. The only
things that annoys me is the bad feeling about letting the app run
forever until a system component that I don’t have any control on will
do it at some magic time. But I will still give it a try in the next
release.

Thanks all.
Regards
Martin_______________________________________________
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org"

Just to sum it up again:

Yes, I see - but the problem is, that even when onDestroy is called,
some static stuff in the native part is still around. And if then a
restart of the app was triggered (even after onDestroy was called) the
native part is restarted (without the java part to restart and from the
same pid) which of course leads to a lot of trouble if you have static
stuff floating around in your code.

But from my observations not all Android versions behave like this.
4.1.2 (Galaxy S3) does for example, 2.3.3 (Galaxy S) does not.

So on some devices the kill (onDestory) does not really lead to a real
kill immediatelly (and is restorable!!) - but only after some time. And
a second start of the app would lead to … strange things.

Regards
MartinAm 06.01.2014 11:42, schrieb hardcoredaniel:

Hi,

I don’t know too much about SDL in detail, so I can’t say anything
about these events.

Under the hood, SDL for Android has a “Java” and a “Native” part.

The Java part handles the Android lifecycle. So in case your app is
put into background, the onPause() callback arrives. SDL should now
tell the native part to pause executing (and maybe save important data
in case the app will be killed). Upon onResume() SDL shall also resume
the native thread.

In case the onDestroy() callback is called, SDL can tear down
everything and prepare for a (possible) new start of the app.

If the app was killed after onPause() - well, no need to worry about
exiting :slight_smile:

Whenever the app is paused, it should not consume CPU, i.e. everything
should just sit idle and wait to be woken up again by an event (like
onResume()).

The only special case to SDL is that your application “payload” (your
game or whatever) does no longer want to run, say from a user dialogue
"Do you really want to quit playing?". In this situation, it makes no
sense just to pause the app (upon resuming you would still be in the
state “post-I-wanted-to-quit”), but you really want it to reach the
same state where it is upon onDestroy(), waiting to be started again
or killed.

For that, the Java part of SDL will send a “finish()” request to the
Android system, as soon as the native thread is finished, i.e.
SDL_main() returns. So when the native thread exits normally, the app
will enter the onDestroy() state automatically.

Regards,

Daniel

http://www.caveproductions.org
http://www.ufoai.org

Message-ID: <52CA7640.4040800 at gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

Hi,

according to this

http://developer.android.com/reference/android/app/Activity.html#ActivityLifecycle

an app shall just follow the lifecycle. Whether the VM is actually
shut down or not shall be left up to the system (typically only on low
memory). Just make sure that you clean up after onDestroy() such that
a call to onCreate() restores everything, just as if the VM was really
terminated in between.

Actually the VM of the app can be forcibly terminated on low memory
anytime after the onPause() call, so saving all relevant data should
be done at onPause() time. In onDestroy() you just tear down
everything so that another onCreate() will be successful in case the
VM was not terminated.

Anyway, that’s the theory (as far as I understand it). I’m not sure
that every device actually behaves like this :slight_smile:

Regards,

Daniel

Thanks for the link and the feedback.

So the general rule would be to not exit the native app part manually,
but only rely on SDL_QUIT event, right?

Let SDL do the onDestroy stuff and handle SDL_APP_TERMINATING or
SDL_APP_WILLENTERBACKGROUND to shut everything down or save things.

So hitting the home or power button will let SDL pause the app
internally, no need to worry about and will resume it automatically,
too. Having the app “killed” then is up to Android itself. The only
things that annoys me is the bad feeling about letting the app run
forever until a system component that I don’t have any control on will
do it at some magic time. But I will still give it a try in the next
release.

Just for reference, on the Apple Newton (a PDA line from the 90’s)
apparently all apps initially NEVER truly shut down (early forms had
no true filesystem, everything was theoretically running in memory at
all points in time), it was just a question of whether they were
active right then or not. Similarly, the DGD “language driver” for LPC
will usually be told to store a copy of the current run state before
being told to shutdown, so that when it restarts later it will appear
to the user that the only thing that happened was a simultaneous clock
reset and network failure (and on *nix systems, you don’t always get
the network failure). I’m pretty certain that this level of
persistence is what’s ultimately desired in most (or possibly all) of
the mobile platforms (note that this doesn’t mean going STRAIGHT back
to the previous state of a game: I would at least pause it on resume).

You should look at your app as needing to start off with a framework
sufficient to simulate this, and just work out a good balance of
constant statedumps (good because they mean less last-minute I/O, bad
because of flash-memory degradation) and batch statedumps (good and
bad are more or less opposite of constant updates). Once you have
that, you should be able to easily hook into the framework with your
event handlers to simulate the persistence that I described in the
previous paragraph (you should also be able to do some optimizations,
since even after you’ve got the data saved out, then you only need to
read it back in if the in-memory version has to be deallocated, or you
let an external tool modify it).

You should note that in many ways this is just a “polishing” of
conventional game saving characteristics, and that once you have a
good framework or library for it up and running you should be able to
use the same technique on every platform that provides the required
underlying capabilities (e.g. it’s hard to do this if you can’t save
your data somehow, but if you can then you should be set whether it’s
iOS, WindowsXP, Windows8, DOS, or bare-metal with no OS at all).> Date: Mon, 06 Jan 2014 10:24:16 +0100

From: Martin Gerhardy <martin.gerhardy at gmail.com>
To: sdl at lists.libsdl.org
Subject: Re: [SDL] SDL2 Android - Exiting
Am 06.01.2014 10:05, schrieb hardcoredaniel:

Message-ID: <52CA8EFE.2080201 at gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

Just to sum it up again:

Yes, I see - but the problem is, that even when onDestroy is called,
some static stuff in the native part is still around. And if then a
restart of the app was triggered (even after onDestroy was called) the
native part is restarted (without the java part to restart and from the
same pid) which of course leads to a lot of trouble if you have static
stuff floating around in your code.

That would imply that a better job needs to be done of cleaning up the
static data. If you allocated it, then it’s on your shoulders, if a
library did it, then the library maintainers need to do it (figuring
out whose job it is can, obviously, be a massive headache, only
equaled by the changes required to make this work :stuck_out_tongue: . I don’t think
I ever said it was CONVENIENT. ).

So on some devices the kill (onDestory) does not really lead to a real
kill immediatelly (and is restorable!!) - but only after some time. And
a second start of the app would lead to … strange things.

Oh, another bit of bad news: eventually this will probably make it’s
way to some desktops, even (a small bit of persistent memory
apparently exists on all modern server motherboards, and
flash-replacements are being improved for this, among other things).
“Yay” (but hey, if you prepare the right tools then it should be easy
for you, even if obnoxious)!> Date: Mon, 06 Jan 2014 12:09:50 +0100

From: Martin Gerhardy <martin.gerhardy at gmail.com>
To: sdl at lists.libsdl.org
Subject: Re: [SDL] SDL2 Android - Exiting

Hi, I’ve filed two bug reports with proposed solutions regarding this issue

https://bugzilla.libsdl.org/show_bug.cgi?id=2378
https://bugzilla.libsdl.org/show_bug.cgi?id=2379

There might still be problem with static global variables not being properly destroyed, but I believe these two bugs
need to be addressed prior to that.

Regards

Alvin Beach wrote:> On 05/12/13 09:53, Gabriel Jacobo wrote:

I think this should do the trick: https://hg.libsdl.org/SDL/rev/a9c5ddad50b0

2013/12/5 Martin Gerhardy <martin.gerhardy at gmail.com <mailto:martin.gerhardy at gmail.com>>

Hi,

is there anything that speaks against putting this fix upstream? As far as I can tell, this is
still an issue.

It would at least be cool if there wouldn’t be “new SDLMain()” but “protected SDLMain
getSDLMain()” in the code. So one could override this in his own Activity class without the need
to modify SDLActivity.java (which is always a must-have for me, because I want to be able to
patch things easily).

Greetings
Martin

[SNIP]

Gabriel.

Hello Gabriel,

Your changes work perfectly! I grabbed the latest SDL2 from Mercurial, replaced my app’s jni/SDL2,
removed my call to _exit() and rebuilt the app. When main() returns, the app exits cleanly. Thank you.

Just in case anyone else tries using the latest SDL2 from Mercurial, remember to update your app’s
src/org/libsdl/app/SDLActivity.java with that from SDL2/android-project/. I forgot and, well, all
sorts of chaos ensued!

Alvin


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Sorry to bump this old thread again, but I still have issues with app closing on Android.
When my main exits (in c side) , the activity ends (onDestroy in SDLActivity runs) but the process is still active.
Maybe this doesn’t work like I think it should, I don’t know.
Shouldn’t the process terminate when the activity finishes?

There’s an enigmatic line of code / comment in the onDestroy event in SDLActivity:

@Override
protected void onDestroy() {
     
      code removed for simplicity
    

    // Reset everything in case the user re opens the app
    SDLActivity.initialize();
}

Reset everything in case the user re opens the app? Shouldn’t the app die at this point?
Reopening the app shouldn’t be a new process?
I’m confused…

Hi,

Android apps typically do not “exit”, i.e. the VM process does not
terminate, even after onDestroy(). (Unless the system decides to kill the
process, when resources become tight).

The code in OnDestroy() makes sure that everything is re-initialized (at the
Java side) if (at any later point) onCreate() is called and the VM process
has not been terminated in between.

As a consequence, C code that is loaded as a library into the VM (like SDL)
cannot use static initializers, because the C library is not re-loaded upon
OnCreate() if it was already loaded.

Regards,

Daniel

---------- P?vodn? zpr?va ----------
Od: Limanima <jorge.raposo.lima at gmail.com>
Komu: sdl at lists.libsdl.org
Datum: 27. 1. 2015 12:01:01
P?edm?t: Re: [SDL] SDL2 Android - Exiting

"

                        Alvin Beach wrote:On 05/12/13 09:53, Gabriel Jacobo wrote:

                                  
                                  
                                  
                                  
                                  
                                  
                                  
                                  
                                  
                              Quote:	 

I think this should do the trick: https://hg.libsdl.org/SDL/rev/a9c5ddad50b0
(https://hg.libsdl.org/SDL/rev/a9c5ddad50b0)

2013/12/5 Martin Gerhardy < >

Hi,

is there anything that speaks against putting this fix upstream? As far as I
can tell, this is
still an issue.

It would at least be cool if there wouldn’t be “new SDLMain()” but
"protected SDLMain
getSDLMain()" in the code. So one could override this in his own Activity
class without the need
to modify SDLActivity.java (which is always a must-have for me, because I
want to be able to
patch things easily).

Greetings
Martin

[SNIP]

Gabriel.

Hello Gabriel,

Your changes work perfectly! I grabbed the latest SDL2 from Mercurial,
replaced my app’s jni/SDL2,
removed my call to _exit() and rebuilt the app. When main() returns, the app
exits cleanly. Thank you.

Just in case anyone else tries using the latest SDL2 from Mercurial,
remember to update your app’s
src/org/libsdl/app/SDLActivity.java with that from SDL2/android-project/. I
forgot and, well, all
sorts of chaos ensued!

Alvin


SDL mailing list

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

Sorry to bump this old thread again, but I still have issues with app
closing on Android.
When my main exits (in c side) , the activity ends (onDestroy in SDLActivity
runs) but the process is still active.
Maybe this doesn’t work like I think it should, I don’t know.
Shouldn’t the process terminate when the activity finishes?

There’s an enigmatic line of code / comment in the onDestroy event in
SDLActivity:

@Override
protected void onDestroy() {

code removed for simplicity

// Reset everything in case the user re opens the app
SDLActivity.initialize();
}

Reset everything in case the user re opens the app? Shouldn’t the app die at
this point?
Reopening the app shouldn’t be a new process?
I’m confused…


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org"

This is normal behaviour then.
In that case my first SDL iOS/Android game is ready!

Thanks!

hardcoredaniel wrote:

Hi,

Android apps typically do not “exit”, i.e. the VM process does not terminate, even after onDestroy(). (Unless the system decides to kill the process, when resources become tight).

The code in OnDestroy() makes sure that everything is re-initialized (at the Java side) if (at any later point) onCreate() is called and the VM process has not been terminated in between.

As a consequence, C code that is loaded as a library into the VM (like SDL) cannot use static initializers, because the C library is not re-loaded upon OnCreate() if it was already loaded.

Regards,

Daniel
[/i]

What about running SDL activities in separate processes using android:process of so we can use C exit without killing other activities?[/code]