how can an app running in the background consume CPU if it is not a service?

[Tom]

As an experiment to help me understand the constraints on apps running in the background, I kicked off a large copy of multiple files from my device to my NAS via the AndroXplorer app.

When I switched out of the app back to my home/launcher and then brought up Spare Parts to look at the CPU load of different tasks, the AndroXplorer task was shown to be using a non-zero amount of CPU resources (~15%), but it's status was "BACKGROUND".

However, if I go into "Settings -> Applications -> Running Services", there does not appear to be and background service running associated with the AndroXplorer app. 

I was under the impression that the only way an app can consume CPU in the background is if it is running a service.

What exactly is going on here?

[Tom]

I did some more research.

Although it is preferred that an application not consume CPU resources if it is not in the foreground. It seems that this is complicated if multiple threads are running (which is likely to be the case in order to keep the main UI thread responsive). From what I have read so far, it doesn't seem like there is anything that explicitly prevents a worker thread from continuing to execute even if its parent UI thread has been moved to the background/suspended.

I imagine the correct way to handle things is for the main UI thread to kill any worker threads when onPause() is called and start them up again when onResume is called. This guarantees that there truly is no CPU load for the application while it is not visible (well, except for Services and Broadcast Receivers). The main thread should be careful to save any state needed by the worker thread(s) so that they can start up again when the application comes to the foreground and pick up  from where they left off as if they were never killed in the first place.

However, what's to prevent an application from behaving badly and NOT killing its worker threads? Based on all the high-level talk about the OS not letting backgrounded applications use CPU resources, I had just assumed that ALL threads/processes associated with an app that are not Services or Broadcast Receivers are somehow suspended when an application moves out of the foreground. Instead it seems that it would be very easy for a badly managed worker thread to keep running until it is unceremoniously killed by the OS. 

In theory, I suppose you could let a worker thread continue to execute in the background if a.) the run time is guaranteed to be finite (e.g. loading a web page), and b.) the user wouldn't care if the thread was killed before completing its finite workload (e.g. a web page could just be reloaded if necessary). However, for the AndroXplorer file copy that I mentioned in my previous post, since this "background" thread is not running as a service, how would the user ever know if thread executing the copy was killed before the operation was complete? This seems like it could be a problem.

In general, although the platform provides all of the tools necessary to implement persistent applications without using CPU resources, it is the developer's responsibility to play nicely. Given that resources (i.e. battery/engery) are scare in a mobile environment, it seems like it would have been better to "break" applications that don't behave nicely instead of letting badly behaved applications break the system (by wasting resources). You could even have a worker thread simply spinning in the background, doing nothing but using CPU. Obviously, it would be killed eventually, but not until the memory was needed.

Am I way off the map here or is my understanding more or less correct?

[Nigel Sheridan-Smith]

I think this is a key difference between iOS and Android - and I would prefer it that way, because not all "applications" are foreground, some are utility functions.

On iOS you need to work hard to keep your application alive - usually needs to be VoIP, GPS or audio enabled. As soon as you stop using the feature you are suspended or terminated.

Cheers,

Nigel

--
You received this message because you are subscribed to the Google Groups "android-platform" group.

To view this discussion on the web visit https://groups.google.com/d/msg/android-platform/-/_Fv3N1W2jDMJ.

To post to this group, send email to android-...@googlegroups.com.
To unsubscribe from this group, send email to android-platfo...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/android-platform?hl=en.