This is a quick guide explaining the structure and lifecycle of an Android app.
There are a lot of tutorials on the Internet explaining how to create apps with various tools, but it took a while to actually understand how apps work. This is not obvious, particularly if you have a background writing applications under a desktop operating system like Windows or Linux.
This is intended to be development-tool-agnostic, keep in mind that each development tool will have its own idiosyncrasies. My experience has been with Basic4Android (see Links), a development tools using Visual Basic-like syntax generating Java code that is compiled to create native Android apps.
An Android app is composed of one or more Activities and optionally one or more Service modules, Class modules and Libraries.
An Activity is a block of code (a module) that is associated with a particular screen layout (a Layout in Android parlance,) composed of buttons, labels, pictures, text boxes and other graphical elements.
Since in Android only one Activity can be active at any one time (unlike Windows or Linux where you can have multiple running windows sharing the screen), any Activity that is not currently visible is suspended and can even be unloaded from memory by the OS. Note that in Android 7.0, multiple apps may run in multi-window mode but only one is active at a time, the others are paused.
A Service module does not have a GUI component. A Service continues running in the background even if the app is not visible, so a Service is the only way to have code running while the app has no visible activity. However, a Service cannot have any visible element (except for Toast messages).
Activities may communicate with a Service module, Class modules and Libraries (both ways) via shared global variables and subroutines.
This is where it becomes interesting, particularly if you have experience writing software for a desktop operating system like Windows or Linux.
The Android OS is designed to optimize battery and memory usage. Therefore Android can and will stop (and unload from RAM) any process that is not currently active (note that a Service module will only be unloaded if the OS has already unloaded paused Activities and still needs more resources). You have no control of this, it may happen immediately or after a short delay depending on how busy the device is.
The consequence of that is that if you have an app composed of an Activity and you momentarily leave your app to check your mail for instance; even if you do not close the app when you check your mail, the Activity will start anew when you return to it. The OS will not automatically save the state of your app for you. If you want to return where you were in the app, you have to save the state yourself. That sounds like a pain and it is, but it is better than having the OS guess what you want to keep and what not. There are reasons for this.
Interestingly, rotating your phone while your app is running, or if the device' screen turns off because of inactivity will close the activity currently on screen, so unless you save the state, it will be very frustrating to re-enter all your information each time that happens. It does make sense when you think about it. Rotating the phone will usually require to reorganize the GUI elements according to the new layout. Android has no way to know how to lay them down after rotating the phone, so it leaves it up to you and forces you to do it in an organized fashion by closing the activity.
There are a couple of ways you can save the state of your app while you do something else or the phone goes to sleep. You can add a service module to your app and save the Activity's info into global variables declared in the service module (Service modules are not terminated automatically when you open another app.) When the Activity restarts, you check those variables and use them to restore your Activity's state. Alternately, you can save the state into a file that is saved in the filesystem (non-volatile Flash memory). When the activity restarts, you read that file to restore the state. Of course, you can also use a combination of both. The filesystem solution has the advantage that you can restore your app even if the app is totally closed (phone rebooted for instance).
Note that Basic4Android has a third method to save state, the State Manager (see link).
Android has a process that makes it a little easier: before closing the Activity (because the screen paused or you rotated the phone or for any other reason), the OS will call the onPause() event, which will give you a chance to save your data before the Activity is closed.
Similarly, when the Activity is “unpaused”, the onResume() event is called where you can restore the state.
When you want to terminate an Activity, or a process in general, you are actually asking the operating system to terminate it. Android will schedule this but typically will not do it immediately unless it needs the memory for a higher priority task. It is common to want to close an app and reopen it immediately, so to save battery power, Android does not immediately remove a process from memory when the user terminates it.
Android also may not terminate a process if another process is trying to access it. An example would be a timer in a Service module that regularly calls a subroutine in an Activity. If the user tries to terminate the Activity, Android will reload it when the timer fires, so to make sure the Activity is terminated, you need to make sure that all timers and other externally driven processes that may try to revive it (like sockets) are closed.