User: Password:
|
|
Subscribe / Log in / New account

Blocking suspend blockers

Blocking suspend blockers

Posted May 20, 2010 10:41 UTC (Thu) by brendan_wright (guest, #7376)
In reply to: Blocking suspend blockers by dlang
Parent article: Blocking suspend blockers

Android's implementation of suspend blockers allows it to suspend the system aggressively without worrying about interrupting anything important (such as a download). And for many apps it achieves this without any risk that the app will block suspend no matter how buggy it is, because only some apps have access to the suspend blocker API.

Before an app is installed the user is shown a list of access rights the app is requesting. One access right an app can require is to "prevent the phone from sleeping". As many apps don't need this functionality they don't ask for access to the suspend blocker API, and so can't flatten your battery no matter how buggy they are.

Apps that do require access to the suspend blocker API would need to to exhibit buggy behavior *while holding a lock* in order to drain your battery. Android can also show you which apps are using the most power if you are concerned about your battery life.

Desktop distros could presumably not compile the functionality in, or restrict userspace access to the API, if they were concerned about buggy userspace code blocking suspend?


(Log in to post comments)

Blocking suspend blockers

Posted May 20, 2010 15:57 UTC (Thu) by intgr (subscriber, #39733) [Link]

> Desktop distros could [...] restrict userspace access to the API, if they
> were concerned about buggy userspace code blocking suspend?

No, desktop distros only support user-initiated suspend, which should never be blocked by user space applications anyway. A desktop computer cannot use opportunistic suspend as it stands, because:
* The hardware is not designed that way; suspending (spinning down) your hard drive every few seconds is a great way to kill it
* Current software does not acquire suspend blockers where they would be expected by the user
* Current drivers do not use suspend blockers, so the system as a whole doesn't know when it *can* suspend. If it tries, chances are that the suspend will be blocked half-way until the driver can finish its work -- time during which the system is still running, but the user cannot do anything meaningful.

This is an Android-specific feature that cannot be reliabily used in other configurations, possibly even other handsets.

Blocking suspend blockers

Posted May 20, 2010 17:59 UTC (Thu) by dlang (subscriber, #313) [Link]

I don't know what desktop distros you have been using, but every one that I have seen that does suspend does not require the user to explicitly take action to initiate the suspend, they all are setup to suspend after some defined period of 'inactivity'

Blocking suspend blockers

Posted May 22, 2010 20:24 UTC (Sat) by rvfh (subscriber, #31018) [Link]

But you do expect your movie player to block the screen saver and DPMS off, don't you? Isn't this some kind of user-space suspend blocker?

Blocking suspend blockers

Posted May 20, 2010 23:44 UTC (Thu) by brendan_wright (guest, #7376) [Link]

> No, desktop distros only support user-initiated suspend, which should never be blocked by user space applications anyway.

By desktop distros I mean Ubuntu, Fedora etc that are used on both desktops and laptops. As dlang has pointed out, laptops are often set to suspend after a certain period of inactivity by the user. This non-user-initiated-suspend can and does sometimes interrupt important activities (such as watching a movie, downloading a file etc).

> A desktop computer cannot use opportunistic suspend as it stands, because:
> * The hardware is not designed that way; suspending (spinning down) your hard drive every few seconds is a great way to kill it

Desktops/laptops are certainly different beasts in terms of hardware than mobile devices. A laptop with a solid-state drive (that isn't damaged by a suspend/resume "every few seconds") could potentially handle frequent suspend/resumes whereas a machine with a hard drive couldn't.

Currently we rely on the user or the disto to set reasonable policies in terms of how soon to suspend when running on battery power, but ideally the driver itself would inform the system of it's limitations. A correctly implemented suspend blocker API might be a way to achieve this.

Also Android's userspace API for suspend blockers (which they call wakelocks) supports multiple suspend states:
http://developer.android.com/reference/android/os/PowerMa...

Possibly a suspend blocker implementation would allow devices that are happy to suspend frequently to do so while others are kept active. A user may wish for their dual 24" monitors and 12-core CPU to suspend after 3 minutes of inactivity but not their hard drive (which would suffer too much wear). A well implemented suspend blocker API could allow the drivers to indicate when they are willing to suspend.

> * Current software does not acquire suspend blockers where they would be expected by the user

Of course nobody is using an API that doesn't exist yet. But I think you're assuming that by implementing suspend blockers distros would be forced to suspend very frequently like Android devices do, thereby causing problems for software. There's no reason why they would need to be configured this way.

But by providing the API a browser that's downloading a 600MB ISO from a server that doesn't support resuming could indicate it doesn't want the network & storage systems to be suspended till it's finished. Perhaps this might be sufficient to block a timeout-triggered suspend but a user might still be allowed to force a suspend if required?

> * Current drivers do not use suspend blockers, so the system as a whole doesn't know when it *can* suspend. If it tries, chances are that the suspend will be blocked half-way until the driver can finish its work -- time during which the system is still running, but the user cannot do anything meaningful.

Most laptops running desktop distros are suspended after a period of inactivity when running on the battery. As you point out, they do so without the system really knowing that it can. The system is forced to *assume* that it can because drivers can't tell it otherwise because they have no API with which to do so. Providing this API rectifies this problem.

> This is an Android-specific feature that cannot be reliabily used in other configurations, possibly even other handsets.

I think it's a potentially useful feature for any Linux system that runs off a battery or uses a lot of power.

Blocking suspend blockers

Posted May 21, 2010 9:41 UTC (Fri) by intgr (subscriber, #39733) [Link]

Thanks for this post! You have convinced me.

> A user may wish for their dual 24" monitors and 12-core CPU to suspend
> after 3 minutes of inactivity but not their hard drive (which would suffer
> too much wear).

Is that possible with current PC hardware? To suspend the rest of the system except hard drives?

I always thought that when you suspend the CPU, the rest of the system has to come down too. (Except on Android where hardware was specifically designed to allow this)

Blocking suspend blockers

Posted May 22, 2010 20:29 UTC (Sat) by rvfh (subscriber, #31018) [Link]

> But by providing the API a browser that's downloading a 600MB ISO from a server that doesn't support resuming could indicate it doesn't want the network & storage systems to be suspended till it's finished. Perhaps this might be sufficient to block a timeout-triggered suspend but a user might still be allowed to force a suspend if required?

This reminds of the way KDE (and I suppose the others too) will stop you from logging off when you have unsaved changes. Indeed, you'd like to have a way to back off when the app tells you 'ongoing download: do you really want to stand-by?'

Blocking suspend blockers

Posted May 20, 2010 18:01 UTC (Thu) by dlang (subscriber, #313) [Link]

the buggy behavior I expect is to raise the blocker for excessive periods of time (there has to be a way for multiple apps to raise the blocker at the same time, or the concept will fall apart in a multiprocess envrionment)

Blocking suspend blockers

Posted May 20, 2010 23:54 UTC (Thu) by brendan_wright (guest, #7376) [Link]

> the buggy behavior I expect is to raise the blocker for excessive periods of time (there has to be a way for multiple apps to raise the blocker at the same time, or the concept will fall apart in a multiprocess environment)

This is a potential problem. One advantage Android has is that most apps are installed through a market where user comments can indicate to others that software has these kinds of bugs (which should be pretty rare as most code shouldn't need to operate with a suspend block taken).

A user who notices that the problem is occurring could manually kill the app. However they won't always be paying attention to the device.

A battery operated device will eventually die through lack of power anyway, so perhaps devices should choose to ignore an apps suspend-blocking request after a certain amount of battery is consumed. This sort of functionality might seem unnecessarily complex in the desktop world but could be a life-saver in the world of battery operated devices.

Blocking suspend blockers

Posted May 21, 2010 11:03 UTC (Fri) by tialaramex (subscriber, #21167) [Link]

My understanding is that in the Android phone world what happens is this:

• User A downloads "cow bouncer" and is impressed that now their phone constantly has bouncing cows. However an hour later their phone bleeps to warn the battery is low. The "low battery" screen shows a "Why so soon?" button or link, which implicates "cow bouncer" as the reason. User A chooses to uninstall the "cow bouncer" app because it's a waste of battery life.

• User B downloads "John the ripper Android edition" and sets it to work cracking password hashes. An hour later the phone bleeps due to exhausted battery. User B plugs it into the wall, he doesn't ask why because hey, he was running a password cracker on his phone, stands to reason it will exhaust the battery.

By obligating ordinary developers to ask for this functionality if they need it and then auditing how it is used, Android make them responsible to their users - if you need to block suspend for long periods, you will need to educate your users about why that is, and persuade them that the app functionality is worth the reduced battery life, otherwise they're going to throw your app away and probably warn off other potential customers.

Blocking suspend blockers

Posted May 21, 2010 12:57 UTC (Fri) by farnz (subscriber, #17727) [Link]

Close, but not quite for the HTC Hero running Android 1.5. When you download "cow bouncer" or "JTR Android", you get warned that the application can "Prevent the phone from sleeping", and have to say OK or Cancel to the "install anyway" prompt.

There's no in-built UI for catching bad apps, but there are third party applications in the Market that use the existing API to tell you which applications are using power - they're spotted not because they're CPU hogs, but because they're holding a wakelock preventing the phone from sleeping.

Blocking suspend blockers

Posted May 21, 2010 15:58 UTC (Fri) by Aissen (guest, #59976) [Link]

HTC Hero running Android 1.5

Although it was released just over a year ago, Android 1.5 is a pretty old in the Android timeline.
Wonderful things have happened, and three releases later Android 2.2 have been announced officially yesterday.
HTC promised to update the Hero to Android 2.1, and hopefully you'll get it sooner rather than later, and see the UI everyone's talking about in the default OS.

The most important is that susupend blockers are merged so that the future of Android is one where upstream matters, and Android kernel is no longer a fork.

Blocking suspend blockers

Posted May 21, 2010 16:00 UTC (Fri) by farnz (subscriber, #17727) [Link]

Android 1.5 is the latest version available for my device; I cannot in fairness tell you how Android behaves without qualifying it with the version number, because I can't tell you if it's been improved in later versions.

However, I'd hope that in this respect, Android isn't regressing in new versions. Power management is kinda critical on a phone.

Blocking suspend blockers

Posted May 21, 2010 23:17 UTC (Fri) by vonbrand (guest, #4458) [Link]

Ever heard of dancing pigs? Fat chance that the end user will ever make an informed decision on installing an application calling for this then...

Blocking suspend blockers

Posted May 22, 2010 1:53 UTC (Sat) by swetland (guest, #63414) [Link]

It is true that users are well-trained to keep clicking until they get whatever it is that they're after, but the way we use suspend blockers in Android includes more than just warning users that the app may "prevent the device from sleeping":

- Applications that don't specifically need to prevent suspend don't request the permission, and the vast majority of apps fall into that category. The user obtains benefit here in that if non-suspend-blocking apps perform poorly, they only do so while the device is awake, which we attempt to minimize.

- Applications that keep the device awake must use suspend blockers and the statistics from their use allows us to answer the "Why is my battery running low?" question by pointing out apps that are contributing to poor battery life. The "battery low, please plug in the charger" notification has had a "Why?" button since Android 2.0, to help users discover the "what apps are using up my battery" panel.

So yes, users will certainly get their dancing pigs (or bouncing cows), especially on a platform that has no restrictions on app installation, but we can certainly help the user still have a positive experience, or at the least, understand what the cause of their negative experience is.

Blocking suspend blockers

Posted May 22, 2010 2:30 UTC (Sat) by dlang (subscriber, #313) [Link]

do the statistics tell you how long an app has blocked suspend? how many times it's done so? what percentage of the time?

a long running app that uses suspend blockers only where needed could still show up as a top item for total time blocked or how many times it's blocked.

Blocking suspend blockers

Posted May 22, 2010 3:15 UTC (Sat) by swetland (guest, #63414) [Link]

The battery statistics service tracks number of times acquired, total realtime (aka walltime) held, etc. Here's a sample from a typical bugreport. The user facing UI is, of course, friendlier looking: http://frotz.net/misc/battery-stats-unplugged.txt

It starts with an overview then provides a UID-by-UID and process-by-process breakdown of wakelocks, cpu time, sensor usage, etc.

Blocking suspend blockers

Posted Jun 1, 2010 20:11 UTC (Tue) by Duncan (guest, #6647) [Link]

Thanks for the link to a real log. That's one thing I'd not seen in all this discussion.


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds