ubuntu-phone team mailing list archive

[Sergio Schvezov <sergio.schvezov@xxxxxxxxxxxxx>]

On Mon, Oct 21, 2013 at 7:46 PM, Jamie Strandboge <jamie@xxxxxxxxxxxxx>wrote:

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

qtpowerd prevents the device from suspending, but there's another hack in
the lifecycle code that prevents the app from suspending; these for v1 at
least are considered hacks.

AFAIK, once the music app uses the music hub these hacks should go away
(from music and mediaplayer).



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

Using power-cli would stop the device from suspending, but not the app.

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

For the music/sound stuff I thought apps were supposed to delegate that to
the music-hub[1].

Cheers
Sergio

[1] https://blueprints.launchpad.net/music-hub/+spec/music-hub

>
> --
> Jamie Strandboge                 http://www.ubuntu.com/
>
>
> --
> Mailing list: https://launchpad.net/~ubuntu-phone
> Post to     : ubuntu-phone@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~ubuntu-phone
> More help   : https://help.launchpad.net/ListHelp
>
>