Droid Sector

I’ve already received multiple emails from people who are excited for iOS 4’s multitasking because they can’t wait for this to finally stop being an issue, because they think Instapaper will be able to download articles periodically in the background.

It’s painful to respond, crushing their hopes, to tell them that the iOS multitasking system doesn’t allow me to do that.

By naming these features “multitasking”, Apple has set customers’ expectations to include what apps can do in a traditional computer multitasking environment.

It’s going to mislead people into expecting such behavior from apps, but we can’t actually deliver most of it.

Some people will notice that no apps can do these things and properly focus their disappointment on Apple. But many others will only notice the shortcomings in one particular app that they need to do the “impossible” and blame that application, leading to dissatisfaction and negative thoughts about the app.

As long as iOS “multitasking” can do much less than traditional multitasking — which will probably always be the case — this is going to be an issue.

www.marco.org

An excerpt from Service API changes starting with Android 2.0 by Dianne Hackborn / Android Developers Blog. Learn how to manage background services and make your phone faster:

Our final issue to address is the case where there are simply too many service running in the amount of memory available on a device. This may be due to bugs or design flaws in installed applications, or the user simply trying to do too much. Historically users have had no visibility into what is going on at this level in the system, but it has become important to expose this, at least for lower-end devices, as the use of services has had an increasing impact on the user experience.

To help address this, Android 2.0 introduces a new “Running Services” activity available from the Application system settings. The main content is a list of all running services that may be of interest to the user, organized by the processes they run in. In the example here, we see three services:

• GTalkService is part of the standard Google application suit; it is running in Google’s “gapps” process, which currently consumes 6.8MB. It has been started for 3 hours 55 minutes, which on this device is the time from when it was first booted.
• ActivityService is part of the Phonebook app, and its process consumes 4MB. This also has been running since boot.
• SoftKeyboard is a third party input method. It has been running since I switched to it, about 4 minutes ago.

The user can tap on any of these services to control it; for normal services that are running because they were explicitly started, this will present a dialog allowing the user to explicitly stop it.

Some other services, like the input method, are running for other reasons. For these, tapping on the service will go to the corresponding UI to manage it (in this case the system’s input settings).

Finally, along the bottom of the screen are some obscure numbers. If you know how to interpret them, this gives you a lot of information on the memory status of your device:

• Avail: 38MB+114MB in 25 says that the device has 38MB of completely free (or likely used for unrequired caches) memory, and has another 114MB of available memory in 25 background processes it can kill at any time.
• Other: 32MB in 3 says that the device has 32MB of unavailable memory in 3 unkillable processes (that is, processes that are currently considered to be foreground and must be kept running)

For most users, this new user interface should be a much more effective way to manage the background applications on their device than the existing “task killer” applications. In the vast majority of cases the reason for a slow running device is too many services trying to run. This prevents the system from being able to run any background processes (which speed up app switching), and ultimately can result in thrashing through the services when not even they can all be kept running. The Running Services UI is intended to provide very specific information about the services that are running, to help make a good decision about what should be stopped. It also does not use the API to force stop an application, which can unintentionally break applications in numerous ways.

Androcheck from xda-developers forum has figured out how to configure Android’s internal taskkiller:

We all know that Android uses a different way of handling processes. Instead of killing every process after its Activity ended, processes are kept until the system needs more memory. These processes usually should not harm the overall performance and should give speed improvements if you start an Activity again. That’s the idea.

But when does Android kill a process? And which process? As far as I understood android keeps a LRU (last recently used) list and starts killing the oldest unneeded process. This way it is much smarter than any of the taskkillers we see in the Market.

Android seems to group running processes into 6 different categories:

FOREGROUND_APP:
// This is the process running the current foreground app. We’d really
// rather not kill it! Value set in system/rootdir/init.rc on startup.

VISIBLE_APP:
// This is a process only hosting activities that are visible to the
// user, so we’d prefer they don’t disappear. Value set in
// system/rootdir/init.rc on startup.

SECONDARY_SERVER:
// This is a process holding a secondary server — killing it will not
// have much of an impact as far as the user is concerned. Value set in
// system/rootdir/init.rc on startup.

HIDDEN_APP:
// This is a process only hosting activities that are not visible,
// so it can be killed without any disruption. Value set in
// system/rootdir/init.rc on startup.

CONTENT_PROVIDER:
// This is a process with a content provider that does not have any clients
// attached to it. If it did have any clients, its adjustment would be the
// one for the highest-priority of those processes.

EMPTY_APP:
// This is a process without anything currently running in it. Definitely
// the first to go! Value set in system/rootdir/init.rc on startup.
// This value is initalized in the constructor, careful when refering to
// this static variable externally.

These 6 categories are reflected by 6 memory limits which are configured for the lowmemorykiller in the kernel.

Default values varies from 6 mb (foreground app) to 24 mb (empty app). This means that the system will keep the apps in memory while you have at least 24 mb free. If you feel that more free memory and less apps in background will make your phone faster, these values can be increased.

Read more on xda-developers forum: How to configure Android’s internal taskkiller.

A few days later, oldskool73 released an app for tweaking these values:
http://www.dustypixels.com/blog/2010/01/30/android-app-minfreemanager/