The application life cycle in LibGDX is a well-defined set of distinct system states. The list of these states is pretty short: create, resize, render, pause, resume, and dispose.

LibGDX defines an ApplicationListener interface that contains six methods, one for each system state. The following code listing is a copy that is directly taken from LibGDX's sources. For the sake of readability, all comments have been stripped:

public interface ApplicationListener {
public void create ();
public void resize (int width, int height);
public void render ();
public void pause ();
public void resume ();
public void dispose ();
}

All you need to do is implement these methods in your main class of the shared game code project. LibGDX will then call each of these methods at the right time.

The following diagram visualizes the LibGDX's application life cycle:

Note that a full and dotted line basically has the same meaning in the preceding diagram. They both connect two consecutive states and have a direction of flow indicated by a little arrowhead on one end of the line. A dotted line additionally denotes a system event.

When an application starts, it will always begin with create(). This is where the initialization of the application should happen, such as loading assets into memory and creating an initial state of the game world. Subsequently, the next state that follows is resize(). This is the first opportunity for an application to adjust itself to the available display size (width and height) given in pixels.

Next, LibGDX will handle system events. If no event has occurred in the meanwhile, it is assumed that the application is (still) running. The next state would be render(). This is where a game application will mainly do the following two things:

Afterwards, a decision is made on which the platform type is detected by LibGDX. On a desktop or in a web browser, the displaying application window can be virtually resized at any time. LibGDX compares the last and current sizes on every cycle so that resize() is only called if the display size is changed. This makes sure that the running application is able to accommodate a changed display size.

Now, the cycle starts over by handling (new) system events once again. Another system event that can occur during runtime is the exit event. When it occurs, LibGDX will first change to the pause() state, which is a very good place to save any data that would be lost otherwise, after the application is terminated. Subsequently, LibGDX changes to the dispose() state where an application should do its final cleanup to free all the resources that it is still using.

This is also almost true for Android, except that pause() is an intermediate state that is not directly followed by the dispose() state at first. Be aware that this event might occur anytime during an application runtime when the user has pressed the Home button or if there is an incoming phone call in the meanwhile. In fact, as long as the Android operating system does not need the occupied memory of the paused application, its state will not be changed to dispose(). Moreover, it is possible that a paused application might receive a resume system event, which in this case would change its state to resume(), and it would eventually arrive at the system event handler again.