ubuntu-phone team mailing list archive

[Jamie Strandboge <jamie@xxxxxxxxxxxxx>]

Recently someone asked me about adding an apparmor policy group for qtpowerd so
that apps could stop application lifecycle from suspending the app. I said to
file a bug and I'd look at it because I was thinking this seemed reasonable for
a number of reasons (which I'll list below). We were told that apps should not
generally have this permission. This particular case was a 3rd party music
player and in this case it was easy enough to punt and say that 3rd party music
players should use the upcoming media service. However...

I think we may be too strict on this. Consider the following apps:
 * a metronome app for musicians to practice to (2 are in the app store now)
 * a white noise app to help people sleep (1 in the store)
 * a navigation app that speaks the directions to you as you drive (none in the
   app store AFAIK, but this would be a wonderful addition)
 * internet radio apps (there are at least 2 in the store)
 * a 3rd party alarm clock (perhaps the API that the core app clock uses is
   sufficient-- I haven't checked)

AIUI, all of these apps either do or would suffer from the same limitation: they
could all be suspended when the screen blanks which severely limits their
utility. I tried to use one of the metronomes and also the white noise app, but
our current application lifecycle power management suspends them after 30
seconds. I didn't even bother with the second metronome because I figured it
would suffer the same fate (a shame if our users think the same thing). Note, in
many of these cases, the app is still the foreground app (metronome, white
noise, navigation). I guess a workaround for the user is to call powerd-cli in
the terminal app-- that is certainly not what we want normal users to do.

Currently, we are not allowing developers to inhibit power management of the app
or we allow it for certain apps if they run unconfined, like the music-app. I
defaulting to suspending the app is a great default and it makes sense for us to
continue to build out our APIs and services (eg, the media service) to
accomodate various use cases, but I also think that we should allow for
developers to opt into inhibiting app suspend at the very least for apps that
are in the foreground because we aren't going to be able to predict all the use
cases developers will need. We can implement this as an apparmor policy and
expose it to QML apps in some manner (heck, it could even have trust-store
integration with a prompt saying that the app can inhibit, but personally I
think not even this is needed). We can then let user reviews handle apps that
misbehave ("This app sux-- whenever I use it, my battery drains after 37 minutes
when normally I get 37 hours of life!! <1 star>").

Do we have a plan for apps like this? If not, could we create an API that allows
inhibiting reasonably? Note, there was a related thread ('Catching CPU run-aways
on Touch') that might be useful to take a look at if we are going to implement this.

-- 
Jamie Strandboge                 http://www.ubuntu.com/

Attachment: signature.asc
Description: OpenPGP digital signature