SDL2 Android - Exiting

Hello,

How do you quit/exit the Android application from within C++ (e.g. libmain.so)? I feel this is a
silly question, however, when my “int main(int argc, char *argv[])” returns, the app remains
running. The README-android.txt doesn’t say.

AFAIK, Android handles actually terminating the app. In my case, I would like to force quit the app.

Alvin

IIRC issuing “exit” does the trick somewhat forcefully…

Returning from main won’t close your app because there’s two threads
active, the Java side thread and the native thread where your main function
runs.
Currently, exiting from the later won’t exit your app as the Java thread
keeps running (until it crashes or something :slight_smile: )

2013/11/22 Alvin Beach > Hello,

How do you quit/exit the Android application from within C++ (e.g.
libmain.so)? I feel this is a
silly question, however, when my "int main(int argc, char *argv[])"
returns, the app remains
running. The README-android.txt doesn’t say.

AFAIK, Android handles actually terminating the app. In my case, I would
like to force quit the app.

Alvin


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


Gabriel.

Doesn’t SDL_Quit() do the trick?

2013/11/22 Gabriel Jacobo > IIRC issuing “exit” does the trick somewhat forcefully…

Returning from main won’t close your app because there’s two threads
active, the Java side thread and the native thread where your main function
runs.
Currently, exiting from the later won’t exit your app as the Java thread
keeps running (until it crashes or something :slight_smile: )

2013/11/22 Alvin Beach

Hello,

How do you quit/exit the Android application from within C++ (e.g.
libmain.so)? I feel this is a
silly question, however, when my "int main(int argc, char *argv[])"
returns, the app remains
running. The README-android.txt doesn’t say.

AFAIK, Android handles actually terminating the app. In my case, I would
like to force quit the app.

Alvin


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


Gabriel.


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

Thank you, that did the trick. I should have tried that before posting! Normally, I tend to use
_exit() when I know there is nothing left to clean up (no open files, etc.). IIRC, exit() will does
some clean up operations whereas _exit() just terminates right then an there. Do you know of any
reason why exit() would be better to use on Android/SDL2 rather than _exit()?

Thanks,

AlvinOn 22/11/13 13:19, Gabriel Jacobo wrote:

IIRC issuing “exit” does the trick somewhat forcefully…

Returning from main won’t close your app because there’s two threads active, the Java side thread
and the native thread where your main function runs.
Currently, exiting from the later won’t exit your app as the Java thread keeps running (until it
crashes or something :slight_smile: )

2013/11/22 Alvin Beach <@Alvin_Beach mailto:Alvin_Beach>

Hello,

How do you quit/exit the Android application from within C++ ... [snip]

Alvin

I thought that would have worked too. It just shuts down SDL not the app. What becomes of the app
after calling SDL_Quit(), I’m not sure. The use case for calling SDL_Quit and not really wanting the
app to exit (SDL2 app I mean), isn’t clear to me.

AlvinOn 22/11/13 13:28, Stefanos A. wrote:

Doesn’t SDL_Quit() do the trick?

2013/11/22 Gabriel Jacobo <gabomdq at gmail.com <mailto:gabomdq at gmail.com>>

IIRC issuing "exit" does the trick somewhat forcefully...

[snip]

The Java code calls nativeQuit in the onDestroy handler. I can’t find any
relevant for the opposite direction, i.e. a check that mSDLThread has quit,
which explains why the activity keeps running.

I’m not sure if there is any straightforward way to check that, someone
more familiar with Android should pitch in.

2013/11/22 Alvin Beach > On 22/11/13 13:28, Stefanos A. wrote:

Doesn’t SDL_Quit() do the trick?

2013/11/22 Gabriel Jacobo <gabomdq at gmail.com <mailto:gabomdq at gmail.com>>

IIRC issuing "exit" does the trick somewhat forcefully...

[snip]

I thought that would have worked too. It just shuts down SDL not the app.
What becomes of the app
after calling SDL_Quit(), I’m not sure. The use case for calling SDL_Quit
and not really wanting the
app to exit (SDL2 app I mean), isn’t clear to me.

Alvin


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

Message-ID: <528F96A1.6050109 at gmail.com>
Content-Type: text/plain; charset=ISO-8859-1

Doesn’t SDL_Quit() do the trick?

2013/11/22 Gabriel Jacobo <gabomdq at gmail.com <mailto:gabomdq at gmail.com>>

IIRC issuing "exit" does the trick somewhat forcefully...

[snip]

I thought that would have worked too. It just shuts down SDL not the app.
What becomes of the app
after calling SDL_Quit(), I’m not sure. The use case for calling SDL_Quit
and not really wanting the
app to exit (SDL2 app I mean), isn’t clear to me.

I think this is a somewhat silly idea, but you might be using SDL as a
wizard, and then doing all further work non-interactively. You can say
"but Android expects your app to have a window!", but it isn’t really
relevant, since desktops are supported too.

At any rate, having SDL_Quit() actually exit the application would be
a BAD idea. If you’re only using one library, then sure, it probably
wouldn’t bite you, but if you’re using multiple libraries, where for
each one it doesn’t make sense to continue running the program after
it’s deinitialized, then you start running into questions of what
happens if more than one expects to close the program. In essence, for
libraries to play nicely together, you need to NOT do this in any
function that DOESN’T have this as it’s ONLY role: and SDL_Quit()
wouldn’t have this as it’s only role, since it’s the function that is
used to deinitialize the entire library.

In short, SDL_Quit() calling exit() or doing anything else of that
sort is an inherently bad idea.> Date: Fri, 22 Nov 2013 13:38:41 -0400

From: Alvin Beach
To: SDL Development List
Subject: Re: [SDL] SDL2 Android - Exiting
On 22/11/13 13:28, Stefanos A. wrote:

Message-ID: <528F96A1.6050109 at gmail.com>
Content-Type: text/plain; charset=ISO-8859-1

Doesn’t SDL_Quit() do the trick?

2013/11/22 Gabriel Jacobo <gabomdq at gmail.com <mailto:gabomdq at gmail.com>>

IIRC issuing "exit" does the trick somewhat forcefully...

[snip]

I thought that would have worked too. It just shuts down SDL not the app.
What becomes of the app
after calling SDL_Quit(), I’m not sure. The use case for calling SDL_Quit
and not really wanting the
app to exit (SDL2 app I mean), isn’t clear to me.

I think this is a somewhat silly idea, but you might be using SDL as a
wizard, and then doing all further work non-interactively. You can say
"but Android expects your app to have a window!", but it isn’t really
relevant, since desktops are supported too.

At any rate, having SDL_Quit() actually exit the application would be
a BAD idea. If you’re only using one library, then sure, it probably
wouldn’t bite you, but if you’re using multiple libraries, where for
each one it doesn’t make sense to continue running the program after
it’s deinitialized, then you start running into questions of what
happens if more than one expects to close the program. In essence, for
libraries to play nicely together, you need to NOT do this in any
function that DOESN’T have this as it’s ONLY role: and SDL_Quit()
wouldn’t have this as it’s only role, since it’s the function that is
used to deinitialize the entire library.

In short, SDL_Quit() calling exit() or doing anything else of that
sort is an inherently bad idea.

I agree, SDL_Quit() should not call exit() for all the reasons you listed above. Since SDL_Init()
has to be called by the C++ code, it wouldn’t be consistent (at the very least) for SDL_Quit() to
exit() the app. My statement about “SDL_Quit() and the state of the app” was concerning the state of
the threads. When main() returns, it’s thread presumably dies. This leaves the Java thread running.
I believe there is no scenario to get main() to start up again. The app needs to be terminated and
restarted for main() to run again.

I am using the most excellent android-project/ from the SDL2 source as my base. As I understand it,
its design is that there are two threads: one for the Java side (the App - the “shim” according to
Readme-android.txt) and the other that runs the C++ code (i.e. in libmain.so). My thought process
was that, for Android (iOS too perhaps, but I’m Android centric atm), if SDL_Quit() could notify the
Java side that the SDL2 infrastructure has shutdown. In this case, the Java side would do a proper
shutdown (e.g. finalise(), and destroy the SDLActivity). AFAIK, destroying the SDLActivity would
cause the Android OS to terminate the app. Perhaps, SDL_Quit() would be the wrong place for this.
Perhaps the Java “shim” could detect that the thread for libmain.so has terminated (or be notified
it has been) and then begin terminating itself as well? Again, this would only apply to Android (and
possibly iOS).

From what I can see in the source is that the Java-side of the SDL2 project properly terminates
itself when told to by the OS (i.e. onDestroy() I believe). I am wondering if there is a way to
trigger that behaviour from within the C++ code.

This all may be for not since an app is not /suppose/ to exit itself. However, main() does
eventually end, in which case there is this lingering app with only half of it running?

AlvinOn 22/11/13 23:29, Jared Maddox wrote:

Date: Fri, 22 Nov 2013 13:38:41 -0400
From: Alvin Beach <@Alvin_Beach>
To: SDL Development List
Subject: Re: [SDL] SDL2 Android - Exiting
On 22/11/13 13:28, Stefanos A. wrote:

Message-ID: <52902C26.8010509 at gmail.com>
Content-Type: text/plain; charset=ISO-8859-1

My
statement about “SDL_Quit() and the state of the app” was concerning
the state of the threads. When main() returns, it’s thread presumably
dies. This leaves the Java thread running. I believe there is no scenario
to get main() to start up again. The app needs to be terminated and
restarted for main() to run again.

Technically, this depends on the code that called main() in the first
place, but I agree with you that it’s doubtful that such a
"reincarnation" technique is incorporated there. Even if it is,
presumably anything that fixes the orphaned-thread problem can later
be extended to work in that case too.

From what I can see in the source is that the Java-side of the SDL2 project
properly terminates itself when told to by the OS (i.e. onDestroy() I believe).
I am wondering if there is a way to trigger that behaviour from within the
C++ code.

Maybe there’s a way to ask the OS to do the termination? All that’s
really needed is (at least I hope) to slip the call to main() between
the initial setup, and the final tear-down of the C++ thread, while
signalling at the end of that thread that the Java thread should exit
too.> Date: Sat, 23 Nov 2013 00:16:38 -0400

From: Alvin Beach
To: SDL Development List
Subject: Re: [SDL] SDL2 Android - Exiting

Hi,

I’m using Activity.finish() to do that. I defined myself a Handler in
SDLActivity.java

??? protected Handler exitHandler = new Handler() {
??? ??? public void handleMessage(Message msg) {
??? ??? ??? finish();
??? ??? }
??? };

and I send a message to that Handler when the SDL C thread terminates.

??? // Runs SDL_main()
??? SDLActivity.nativeInit();

??? // Log.v(“SDL”, “SDL thread terminated”);
???
??? exitHandler.sendEmptyMessage(0);
???
The call to finish() triggers the lifecycle management of the Android system
to “tear down” the app (although the virtual machine will not necessarily
exit). In the process of that, “onDestroy()” is called and that will nicely
terminate everything.

My solution is not really elegant, as it requires you to hand the reference
to the “exitHandler” all the way to the SDLMain class. But it works :slight_smile:

Regards,

Daniel

---------- P?vodn? zpr?va ----------
Od: Jared Maddox
Datum: 24. 11. 2013
P?edm?t: Re: [SDL] SDL2 Android - Exiting

"> Date: Sat, 23 Nov 2013 00:16:38 -0400> From: Alvin Beach

To: SDL Development List
Subject: Re: [SDL] SDL2 Android - Exiting
Message-ID: <52902C26.8010509 at gmail.com>
Content-Type: text/plain; charset=ISO-8859-1

My
statement about “SDL_Quit() and the state of the app” was concerning
the state of the threads. When main() returns, it’s thread presumably
dies. This leaves the Java thread running. I believe there is no scenario
to get main() to start up again. The app needs to be terminated and
restarted for main() to run again.

Technically, this depends on the code that called main() in the first
place, but I agree with you that it’s doubtful that such a
"reincarnation" technique is incorporated there. Even if it is,
presumably anything that fixes the orphaned-thread problem can later
be extended to work in that case too.

From what I can see in the source is that the Java-side of the SDL2
project
properly terminates itself when told to by the OS (i.e. onDestroy() I
believe).
I am wondering if there is a way to trigger that behaviour from within the
C++ code.

Maybe there’s a way to ask the OS to do the termination? All that’s
really needed is (at least I hope) to slip the call to main() between
the initial setup, and the final tear-down of the C++ thread, while
signalling at the end of that thread that the Java thread should exit
too.


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

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
MartinAm 24.11.2013 10:42, schrieb hardcoredaniel:

Hi,

I’m using Activity.finish() to do that. I defined myself a Handler in
SDLActivity.java

protected Handler exitHandler = new Handler() {
    public void handleMessage(Message msg) {
        finish();
    }
};

and I send a message to that Handler when the SDL C thread terminates.

    // Runs SDL_main()
    SDLActivity.nativeInit();

    // Log.v("SDL", "SDL thread terminated");

    exitHandler.sendEmptyMessage(0);

The call to finish() triggers the lifecycle management of the Android
system to “tear down” the app (although the virtual machine will not
necessarily exit). In the process of that, “onDestroy()” is called and
that will nicely terminate everything.

My solution is not really elegant, as it requires you to hand the
reference to the “exitHandler” all the way to the SDLMain class. But
it works :slight_smile:

Regards,

Daniel

---------- Pu*vodn? zpr?va ----------
Od: Jared Maddox
Datum: 24. 11. 2013
Pr(edme(t: Re: [SDL] SDL2 Android - Exiting

> Date: Sat, 23 Nov 2013 00:16:38 -0400
> From: Alvin Beach <alvinbeach at gmail.com>
> To: SDL Development List <sdl at lists.libsdl.org>
> Subject: Re: [SDL] SDL2 Android - Exiting
> Message-ID: <52902C26.8010509 at gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>

<snip>

> My
> statement about "SDL_Quit() and the state of the app" was concerning
> the state of the threads. When main() returns, it's thread
presumably
> dies. This leaves the Java thread running. I believe there is no
scenario
> to get main() to start up again. The app needs to be terminated and
> restarted for main() to run again.
>

Technically, this depends on the code that called main() in the first
place, but I agree with you that it's doubtful that such a
"reincarnation" technique is incorporated there. Even if it is,
presumably anything that fixes the orphaned-thread problem can later
be extended to work in that case too.


> >From what I can see in the source is that the Java-side of the
SDL2 project
> properly terminates itself when told to by the OS (i.e.
onDestroy() I believe).
> I am wondering if there is a way to trigger that behaviour from
within the
> C++ code.
>

Maybe there's a way to ask the OS to do the termination? All that's
really needed is (at least I hope) to slip the call to main() between
the initial setup, and the final tear-down of the C++ thread, while
signalling at the end of that thread that the Java thread should exit
too.
_______________________________________________
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

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

http://www.caveproductions.org/


https://twitter.com/MartinGerhardy

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

2013/12/5 Martin Gerhardy <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

Am 24.11.2013 10:42, schrieb hardcoredaniel:

Hi,

I’m using Activity.finish() to do that. I defined myself a Handler in
SDLActivity.java

protected Handler exitHandler = new Handler() {
    public void handleMessage(Message msg) {
        finish();
    }
};

and I send a message to that Handler when the SDL C thread terminates.

    // Runs SDL_main()
    SDLActivity.nativeInit();

    // Log.v("SDL", "SDL thread terminated");

    exitHandler.sendEmptyMessage(0);

The call to finish() triggers the lifecycle management of the Android
system to “tear down” the app (although the virtual machine will not
necessarily exit). In the process of that, “onDestroy()” is called and that
will nicely terminate everything.

My solution is not really elegant, as it requires you to hand the
reference to the “exitHandler” all the way to the SDLMain class. But it
works :slight_smile:

Regards,

Daniel

---------- P?vodn? zpr?va ----------
Od: Jared Maddox
Datum: 24. 11. 2013
P?edm?t: Re: [SDL] SDL2 Android - Exiting

Date: Sat, 23 Nov 2013 00:16:38 -0400
From: Alvin Beach
To: SDL Development List
Subject: Re: [SDL] SDL2 Android - Exiting
Message-ID: <52902C26.8010509 at gmail.com> <52902C26.8010509 at gmail.com>
Content-Type: text/plain; charset=ISO-8859-1

My
statement about “SDL_Quit() and the state of the app” was concerning
the state of the threads. When main() returns, it’s thread presumably
dies. This leaves the Java thread running. I believe there is no scenario
to get main() to start up again. The app needs to be terminated and
restarted for main() to run again.

Technically, this depends on the code that called main() in the first
place, but I agree with you that it’s doubtful that such a
"reincarnation" technique is incorporated there. Even if it is,
presumably anything that fixes the orphaned-thread problem can later
be extended to work in that case too.

From what I can see in the source is that the Java-side of the SDL2
project
properly terminates itself when told to by the OS (i.e. onDestroy() I
believe).
I am wondering if there is a way to trigger that behaviour from within
the
C++ code.

Maybe there’s a way to ask the OS to do the termination? All that’s
really needed is (at least I hope) to slip the call to main() between
the initial setup, and the final tear-down of the C++ thread, while
signalling at the end of that thread that the Java thread should exit
too.


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


SDL mailing listSDL at lists.libsdl.orghttp://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

http://www.caveproductions.org/https://www.facebook.com/caveexpresshttps://twitter.com/MartinGerhardy


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


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!

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

Hi,

I’m still not able to exit properly on the Galaxy S3 - my S(1) and S2
are working fine. But the damn S3 behaves different. I’ve put a few more
log statements into the activity. The native handleNativeExit stuff is
done properly. After that onDestroy is called, too. But when I then try
to rerun the game, i get the same pid and it looks like my C code is
rerun from the same instance.

I have no clue why the S3 behaves so much different then all the other
devices i’ve tested this on. Every little idea or hint is more then welcome.

Greetings
MartinAm 05.12.2013 16:28, schrieb Alvin Beach:

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 mailto: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
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

http://www.caveproductions.org/


https://twitter.com/MartinGerhardy

What Android version are you running on each phone?

2014/1/5 Martin Gerhardy <martin.gerhardy at gmail.com>> Am 05.12.2013 16:28, schrieb Alvin Beach:

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

Hi,

I’m still not able to exit properly on the Galaxy S3 - my S(1) and S2 are
working fine. But the damn S3 behaves different. I’ve put a few more log
statements into the activity. The native handleNativeExit stuff is done
properly. After that onDestroy is called, too. But when I then try to rerun
the game, i get the same pid and it looks like my C code is rerun from the
same instance.

I have no clue why the S3 behaves so much different then all the other
devices i’ve tested this on. Every little idea or hint is more then welcome.

Greetings
Martin

http://www.caveproductions.org/
https://www.facebook.com/caveexpress
https://twitter.com/MartinGerhardy


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

Galaxy S3: 4.1.2
Galaxy S 2.3.3
Galaxy S2 unsure at the momentAm 05.01.2014 16:15, schrieb Stefanos A.:

What Android version are you running on each phone?

http://www.caveproductions.org/


https://twitter.com/MartinGerhardy

Btw. the hack I’m using right now is to System.exit(0) in onDestroy.

Doing this made me wonder whether an app should really offer a quit
option. Pressing home would pause the app and let android itself decide
when to close it. Does anybody know a guideline for this? How do others
do that? (Especially with native app - because relying on the GC of
dalvik to shut down the app might not always work with native apps when
you are using singletons or static stuff).

Regards
MartinAm 05.01.2014 16:15, schrieb Stefanos A.:

What Android version are you running on each phone?

http://www.caveproductions.org/


https://twitter.com/MartinGerhardy

I recall having the same problem

I did the same system exit in the on-destroy.

You might want to add system exit to if the power button is pressed also, as I seen some phones go crazy. It’s basically, if want to force terminate the app, leave the power button down. If you put it sleep it can the phone to go black.

Best to test everything, volume, power.

Google recommendation is to not have an exit button at all.On 1/5/2014 11:15 PM, Martin Gerhardy wrote:

Am 05.01.2014 16:15, schrieb Stefanos A.:

What Android version are you running on each phone?

Btw. the hack I’m using right now is to System.exit(0) in onDestroy.

Doing this made me wonder whether an app should really offer a quit
option. Pressing home would pause the app and let android itself
decide when to close it. Does anybody know a guideline for this? How
do others do that? (Especially with native app - because relying on
the GC of dalvik to shut down the app might not always work with
native apps when you are using singletons or static stuff).

Regards
Martin


Pallav Nawani
Game Designer/CEO
http://www.ironcode.com
Twitter: http://twitter.com/Ironcode_Gaming
Facebook: http://www.facebook.com/Ironcode.Gaming

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

---------- P?vodn? zpr?va ----------
Od: Pallav Nawani
Datum: 6. 1. 2014
P?edm?t: Re: [SDL] SDL2 Android - Exiting

"Google recommendation is to not have an exit button at all.On 1/5/2014 11:15 PM, Martin Gerhardy wrote:

Am 05.01.2014 16:15, schrieb Stefanos A.:

What Android version are you running on each phone?

Btw. the hack I’m using right now is to System.exit(0) in onDestroy.

Doing this made me wonder whether an app should really offer a quit
option. Pressing home would pause the app and let android itself
decide when to close it. Does anybody know a guideline for this? How
do others do that? (Especially with native app - because relying on
the GC of dalvik to shut down the app might not always work with
native apps when you are using singletons or static stuff).

Regards
Martin


Pallav Nawani
Game Designer/CEO
http://www.ironcode.com
Twitter: http://twitter.com/Ironcode_Gaming
Facebook: http://www.facebook.com/Ironcode.Gaming


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