How to implement the Android Application Lifecycle in Monogame?

1

In my experience everything works excellently
when the app follows the OnPause -> OnResume flow.
On the other hand when the app follows the OnPause->OnStop->OnCreate->OnResume it always crashes due to my code throwing exceptions.

Android_Logcat-Activity-Starts.jpg522×684 35.3 KB

My doubt is the following:

  • When my application gets killed following the onStop->onCreate i would expect the process to be killed completely, instead i find myself with the memory already allocated, and probably the threads still running…
2

What you are referring to is the activity life cycle. This is separate to the process. An activity can be stopped and created but the process remains. Members of your activity are freed when the activity is destroyed, but any objects referenced by a static member remain as they are considered to be part of the process.

3

Thank you for the quick response!
So there are different lifecycles?

  1. an activity lifecycle
  2. a process lifecycle

darn this is troublesome XD
So the activity by itself remains but the process is killed, and then calls OnCreate with all the stuff still in memory…
Sorry if i bother you with questions but what does it mean in monogame that the Process is killed?
Is it correct then for a game made with monogame to Recreate the Game Instance in the onCreate method following a Stop->ProcessKilled->Create path?

4

The other way around. The activity is killed but the process remains. The idea behind is that it allows for faster relaunches of the app.

In MonoGame, the Game object is created in the Activity.OnCreate() and disposed in the Activity.OnDestroy(). If the activity is destroyed, you really want to free up resources, which is why the Game object is disposed.

5

But then in the OnStop->Terminate Process->OnCreate pattern (leftmost in the diagram)
i should call what is in the OnDestroy before calling the OnCreate to have everything
clean for the new game instance, is that correct?

6

Continuing the discussion from How to implement the Android Application Lifecycle in Monogame?:

Hello, I’ve got similar problem.

I get it that it would be nice to have faster game lanches but come on my game process is left in memory after Exit() and it still costs over 90MB !! What shoud we do to release it completely or at least mostly? Can you provide some robust solution to this? (after some time after exiting game my phone alarms that there is grave battery usage because of this huge monogame process left)

Thanks!

7

If the process is killed, everything is gone. Re-launching the app is like starting it again from scratch.

8

At this point, Game.Exit() on Android calls Activity.MoveTaskToBack(true) which moves the activity to the back of the stack. This pauses the activity but does not destroy the activity, therefore the Game instance is not disposed. The Game object will trigger the OnActivated and OnDeactivated events in these cases.

Another thing I have found recently is that the version of openal-soft we are using on Android may not be pausing and resuming its audio mixer thread when the activity is paused and resumed. This will lead to excessive battery usage when the app is in the background. It was only quite recently that pausing the audio mixer thread was added to the library. That is on my list of things to check into.

9

Your answer actually explained a lot to me. Though i’m not sure it’s such a good idea that the activity is not destroyed after Exit() call :stuck_out_tongue: Hope this changes in future updates.

Anyway in the mentioned OnDeactivated(), what should we do? Dispose of everything and then reinitialize it in OnActivated() to minimaze the garbage left? Would that be smart?

10

Hi KonajuGames! Your last comment about OpenAL not pausing/resuming the audio mixer thread caught my attention. We have recently released SnakeRewind on Android, made with Xamarin/Monogame. Some user are reporting heavy battery usage when the game is in the background (we exit by calling Game.Exit() which in turn calls MoveTaskToBack() like you describe).

snakerewind_bgbattery.jpg716×520 60.2 KB

Do you think that this could be related to the OpenAL issue you mentioned? The AudioMix label in the wakelock list certainly hints in that direction. We don’t use any wake locks in our own code so I guess it must be something inside MonoGame. I already tried to call MediaPlayer.Stop() in the OnStop() method when the app is taken to background but that didn’t prevent the game from using battery in the background.

You say that the fix is recently added to OpenAL – is there a new version somewhere that we could try out?

This is a bit off topic though so maybe it would be better to start a new thread about this…