I'm using NativeActivity and android_native_app_glue.c/h and the android_main function on the c++ side.
I just learned that when the app is completely destroyed (APP_CMD_DESTROY event is generated), the Linux process of the app is still NOT destroyed but keeps running; instead just android_main() returns and will be called again when the app restarts.
The funny effect that this has is that there will be some memory which is not freed even when the app is completely destroyed. For example if I make a global variable in my c++ code called int test; and set a value 123 to it, it will still be the same 123 when the app will be created the next time.
I assume that I'm supposed to free all the memory that I've allocated when APP_CMD_DESTROY is generated and android_main will return. Is that assumption true? The question is: is there some rules about how much memory can stay in the memory and not be freed? Is a kilobyte ok? Is 500k ok? Is 50 megs ok? Is 400 megs ok?
The reason why my app is destroyed in the first place is because the user is doing something in another app and will then return to my app, and the other app will tell my app what the user did in the other app. It would be the most convenient if I could just keep all the data that I need in the memory (through a global variable) so that the app would just know where to continue after it was destroyed. Even though I know that making global variables is generally thought to be a bad idea.
So is it a good idea to free absolutely all the memory that I've allocated, or can I keep a little, or can I keep a lot and trust that the Android operating system will go ahead and kill the actual Linux process in the case that it really wants to get rid of the allocated memory? Because I would appreciate if my app restarted really fast after resuming from the other app and it wouldn't need to load some resources in the beginning.