You are here:

Basic Android Lifecycle Recommendations

The previous sections provided a basic introduction to the practical meaning of the most important application lifecycle callbacks, as well as describing the most common ordering of the calls and how they are triggered by user actions.

However, the most important question surrounding these callbacks is, "How do I map common game/application actions to these callbacks?"

All a Game Needs

At its most basic, in terms of lifecycle, most games need to know little more than:

When can I create my game data and/or rendering resources?
When should I be rendering or not rendering (playing/not playing sound)?
When should I move to an auto-pause dialog?
When do I need to shut down?

Generally, this breaks down to knowing:

When an EGL context can be created, when it can be bound, when it is lost.
When the app has a valid rendering surface that is visible and able to interact.
When something has caused the app not to be the top-most UI element and when it comes back.
When the system is shutting down the application.

The following sections will discuss important concepts to answer these questions.