Unfortunately, the documentation is not very clear in many areas. This is one of them.
In theory, if Android was supposed to destroy your activity while it was stopped, then it would call onDestroy() , and GC would restore memory. In fact, Android never destroys individual actions to free up memory. In fact, this means that it kills the entire OS process . In this case, onDestroy() will never be called for any actions in this process. GC does not care about cleaning anything, because the virtual machine (virtual machine) immediately dies along with everything else in the process, and the entire amount of memory used by this process is restored by the operating system.
When your user navigates to your application, Android will create a completely new process for your application, and then create a new instance of your activity. In this case, of course, he will receive a completely new memory block for the instance. You will also see that the calling constructor is called and onCreate() will also be called. However, since Android saves the state of activity representations, this state will be restored by the action of calling super.onCreate() .
There are several cases where Android destroys an instance of an action and automatically creates a new one. This is done, for example, when changing the configuration (i.e., Orientation). In this case, Android calls onDestroy() in the old instance and creates a new instance of the action. The new instance receives the saved state of the old instance and therefore can restore the state of the views as capable. In this case, since a new instance is being created, it, of course, will have a different address in memory.
Once a component is destroyed , it is effectively dead, and the memory that it uses can be fixed by the GC. Android will never reanimate a dead instance.
Hope this clarifies the situation for you.
EDIT Add more details.
Android tracks tasks and actions in these tasks in its internal data structures. For each action, it stores a copy of the Intent that launched the activity, the most recent Intent sent to this action, and saves a Bundle containing the saved state of this action. Android calls onSaveInstanceState() in action to give the activity the ability to save everything it takes to restore activity if Android decides to kill it. The default implementation of onSaveInstanceState() saves the state of all types of activity. Your implementation should save something else that the action will have to restore itself if it is killed and recreated by Android (for some reason). Your private activity member variables and static variables are not automatically saved or restored in the Bundle , so if you need them to recreate your activity correctly, you must save them yourself using the Bundle provided by onSaveInstanceState() . Static variables will remain throughout the application process, but since Android can kill a process at any time (to restore resources) without warning, you also cannot rely on static variables that always have the expected values (in case Android killed and recreated your process).
If your activity (or process) was killed by Android, and the user later switches to your activity, Android uses the information that it has in its internal data structures to create a new instance of the action. It then calls onCreate() on the new instance, passing the state of the saved Bundle instance as a parameter. This can then be used to restore activity to the state that was before the original instance was killed. Android will also call onRestoreInstanceState() after calling onStart() so that you can also restore your state in this method if you don't want to do this in onCreate() .
Note. Remember that everything you want to save / restore in the Bundle must be either primitive ( int , boolean , etc.), or it must implement Serializable or Parcelable .
The onSaveInstanceState() documentation also contains useful information about this.