0

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

Benjamin Mesing
  • 4,075
  • 1
  • 18
  • 22
  • 2
    You definitely should build a mechanism to update the configuration data. As the doc states, there's no guarantee at all that the background process will be destroyed, and even in that case, when will that happen. It depends on the available memory, wether the app is in foreground / background, wether the background process has pointers to live objects, wether it is doing stuff or just sleeping, wether the app is first on the backstack or deep inside ... Besides it all, the term "reasonable" is too subjective ! – rupps Oct 13 '16 at 14:27

1 Answers1

1

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".

CommonsWare
  • 986,068
  • 189
  • 2,389
  • 2,491