we have an App which keeps some configuration data in memory. The configuration data is fetched from the server on start of the application. However, we would like this configuration to be updated from time to time (so new configuration data from the server gets propagated to the client). Our App does usually not stay in the foreground for very long.
According to the Android documentation, a background process can be killed to free some memory. However there seems to be no guarantee, that this will happen within a reasonable amount of time (say e.g. 4h). So the app might be alive forever, if no memory is required. https://developer.android.com/guide/components/processes-and-threads.html
Can we rely on Android to kill background tasks after some time? Or do we have to build a mechanism, to update the configuration data while the app is running?
Can you provide some documentation or well founded experiments for either one or the other side?
Best regards
Ben
However there seems to be no guarantee, that this will happen within a reasonable amount of time (say e.g. 4h).
Correct, there is no guarantee.
So the app might be alive forever, if no memory is required.
That would only occur on a device that never needed to fork a new process, and where all existing processes' sum total of needed system RAM fits within available system RAM. It is extremely unlikely that both of these are true for any given device. It might the case in specific scenarios, where you control Android, the hardware, all sources of data, etc. (e.g., using Android in an embedded system).
Can we rely on Android to kill background tasks after some time?
For some value of "some time", yes. However, "some time" could be longer than four hours.
Or do we have to build a mechanism, to update the configuration data while the app is running?
Well, you already have a way of lazy-loading this configuration data from every entry point of your app (e.g., every activity). Otherwise, your implementation of "the configuration data is fetched from the server on start of the application" is already broken and needs repair.
If you have this, then "update the configuration data while the app is running" is merely a matter of tracking the time when the data was loaded, and including a stale-ness check as part of the lazy-loading algorithm. IOW, whereas right now your algorithm is "if the data is missing, kick off the background download operation and tell the caller that it will get the configuration data asynchronously", now it becomes "if the data is missing or is too old, kick off the background download operation and tell the caller that it will get the configuration data asynchronously".