Android onResume not called? Should it be called?

[phobitor]

This thread is super confusing.

Can anyone confirm if I’m understanding this right:

You start your application and then it gets backgrounded. Your lifecycle callbacks look something like:
onCreate --> onStart --> onResume --> onPause (guessing this is where you get backgrounded)

Then you restore your application. Sometimes, you don’t get an onResume callback. Instead, you end up back in main(). Does this mean that Android killed your application? Do you get any other callbacks in this situation like onStop, onDestroy, onCreate, onStart, etc?

When you’re back in main(), global state hasn’t been reset. As a work around you use a proxy lib to dlopen your game’s shared lib and dlclose when leaving main()

So there are two issues

1. onResume isn’t being called when it should
2. Android kills your activity but may leave the global state of its native libraries intact

[phobitor]

Also a follow up thought:
Shouldn’t dlclose be used on pretty much every native library to be safe? Even though global state isn’t usually prevalent everywhere in a typical library it doesn’t seem unlikely to see a few global variables here and there.

What do other cross platform libs like Qt do I wonder.

[hardcoredaniel]

Hi,

if I understand things correctly, there are 2 different things to look at:

1. Android apps are being kept “loaded in memory” while they are in the
   background, and also when they are “terminated” (from the perspective of the
   user). Rationale is probably that they typically might be re-opened any time
   soon, so it would be wasted battery to unload them, if they are started
   again soon. Just guessing.
   Code that uses static initialization will thus not function properly when
   being executed again, because static initialization only runs when code is
   loaded/classes are constructed. The Java side of SDL handles this by calling
   initialize() even in the onDestroy() callback. For your C code, you either
   do not use static initialization, or use the approach of Michael to load
   your code as library (so that static initialization runs every time you need
   it).

2. The “Activity Lifecycle” (http://developer.android.com/guide/components/
   activities.html) shows after which lifecycle callbacks an Activity can be
   killed. It states that any time after “onPause()” it can be killed. But it
   can also stay in memory after “onDestroy()”. (Plus it can be killed in very
   rare circumstances even if not paused - but I wonder whether this can/shall
   be handled by an Activity, as it seems to be an “emergency situation”).
   There is no “main()” in Android (and as Michael stated, calling “exit()” is
   also not a good idea, I don’t even know what it actually does on Android).
   So there can’t be somebody magically calling “main()” for you. SDL uses a
   dedicated (Java) thread to call into the “main” function of the native code
   (look for “class SDLMain” that eventually calls “SDLActivity.nativeInit(…)
   ”, and in SDL_android_main.c finally “SDL_main” is called). But the call
   chain will always need to originate from a lifecycle callback, no magic.

From that theory, it should never happen that “onResume()” is not called
before your app enters foreground. If your app was killed, or SDL exited
"normally" (which makes the Java code forcibly run through the lifecycle
until and including “onDestroy()”), then it will call “onCreate()” and
"onStart()" before “onResume()”. But omitting the “onResume()” should not
happen.

What is probably unexpected is that upon “onCreate()” you can be in two
different situations, either being “started from scratch” (with all static
initializers being executed) or being “started from background” (where they
won’t execute again). So you must make sure that you are in a consistent
state after “onDestroy()”, as described earlier.

Although until now I have not seen any different behaviour of SDL on the
devices I use (and gladly, I do not use static initialization in C, so I
don’t have to worry about library unloading), there might be devices that
"misbehave", e.g. they deviate from the theory. So you can see my
explanation as a theoretical one that has not been proven wrong by practice
yet

Regards,

Daniel

---------- P?vodn? zpr?va ----------
Od: phobitor
Komu: sdl at lists.libsdl.org
Datum: 17. 10. 2015 4:22:28
P?edm?t: Re: [SDL] Android onResume not called? Should it be called?

"

This thread is super confusing.

Can anyone confirm if I’m understanding this right:

You start your application and then it gets backgrounded. Your lifecycle
callbacks look something like:
onCreate --> onStart --> onResume --> onPause (guessing this is where you
get backgrounded)

Then you restore your application. Sometimes, you don’t get an onResume
callback. Instead, you end up back in main(). Does this mean that Android
killed your application? Do you get any other callbacks in this situation
like onStop, onDestroy, onCreate, onStart, etc?

When you’re back in main(), global state hasn’t been reset. As a work around
you use a proxy lib to dlopen your game’s shared lib and dlclose when
leaving main()

So there are two issues

1. onResume isn’t being called when it should
2. Android kills your activity but may leave the global state of its native
   libraries intact_______________________________________________
   SDL mailing list
   SDL at lists.libsdl.org
   http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org"

[Mark_Sibly]

There are some manifest settings which affect this stuff:

How to resume Android app where it was suspended (app not Activity)

…which suggests using:

android:alwaysRetainTaskState=“true”

and/or…

android:launchMode=“singleInstance” //also try: “singleTask”, “standard”,
“singleTop”.

But there’s also a developer setting that can apparently override this:

http://www.monkey-x.com/Community/posts.php?topic=9434&post=98174&view=all#98174On Sat, Oct 17, 2015 at 11:04 PM, hardcoredaniel wrote:

Hi,

if I understand things correctly, there are 2 different things to look at:

1. Android apps are being kept “loaded in memory” while they are in the
   background, and also when they are “terminated” (from the perspective of
   the user). Rationale is probably that they typically might be re-opened any
   time soon, so it would be wasted battery to unload them, if they are
   started again soon. Just guessing.
   Code that uses static initialization will thus not function properly when
   being executed again, because static initialization only runs when code is
   loaded/classes are constructed. The Java side of SDL handles this by
   calling initialize() even in the onDestroy() callback. For your C code, you
   either do not use static initialization, or use the approach of Michael to
   load your code as library (so that static initialization runs every time
   you need it).

2. The “Activity Lifecycle” (
   http://developer.android.com/guide/components/activities.html) shows
   after which lifecycle callbacks an Activity can be killed. It states that
   any time after “onPause()” it can be killed. But it can also stay in memory
   after “onDestroy()”. (Plus it can be killed in very rare circumstances even
   if not paused - but I wonder whether this can/shall be handled by an
   Activity, as it seems to be an “emergency situation”).
   There is no “main()” in Android (and as Michael stated, calling "exit()“
   is also not a good idea, I don’t even know what it actually does on
   Android). So there can’t be somebody magically calling “main()” for you.
   SDL uses a dedicated (Java) thread to call into the “main” function of the
   native code (look for “class SDLMain” that eventually calls
   "SDLActivity.nativeInit(…)”, and in SDL_android_main.c finally "SDL_main"
   is called). But the call chain will always need to originate from a
   lifecycle callback, no magic.

From that theory, it should never happen that “onResume()” is not called
before your app enters foreground. If your app was killed, or SDL exited
"normally" (which makes the Java code forcibly run through the lifecycle
until and including “onDestroy()”), then it will call “onCreate()” and
"onStart()" before “onResume()”. But omitting the “onResume()” should not
happen.

What is probably unexpected is that upon “onCreate()” you can be in two
different situations, either being “started from scratch” (with all static
initializers being executed) or being “started from background” (where they
won’t execute again). So you must make sure that you are in a consistent
state after “onDestroy()”, as described earlier.

Although until now I have not seen any different behaviour of SDL on the
devices I use (and gladly, I do not use static initialization in C, so I
don’t have to worry about library unloading), there might be devices that
"misbehave", e.g. they deviate from the theory. So you can see my
explanation as a theoretical one that has not been proven wrong by practice
yet

Regards,

Daniel

---------- P?vodn? zpr?va ----------
Od: phobitor
Komu: sdl at lists.libsdl.org
Datum: 17. 10. 2015 4:22:28
P?edm?t: Re: [SDL] Android onResume not called? Should it be called?

This thread is super confusing.

Can anyone confirm if I’m understanding this right:

You start your application and then it gets backgrounded. Your lifecycle
callbacks look something like:
onCreate --> onStart --> onResume --> onPause (guessing this is where you
get backgrounded)

Then you restore your application. Sometimes, you don’t get an onResume
callback. Instead, you end up back in main(). Does this mean that Android
killed your application? Do you get any other callbacks in this situation
like onStop, onDestroy, onCreate, onStart, etc?

When you’re back in main(), global state hasn’t been reset. As a work
around you use a proxy lib to dlopen your game’s shared lib and dlclose
when leaving main()

So there are two issues

1. onResume isn’t being called when it should
2. Android kills your activity but may leave the global state of its
   native libraries intact

---

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