ubuntu-phone team mailing list archive

[Thomas Voß <thomas.voss@xxxxxxxxxxxxx>]

On Tue, Oct 22, 2013 at 12:46 AM, 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...
>
> 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.
>

Trying to distill the use-case/issue we want to solve here:
Applications running in the foreground, that is, of immediate interest
to the user should be able to prevent the system from going into
sleep/deep sleep.

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

Let's untangle the lifecycle and power mgmt policies at this point.
They are admittedly quite closely related. However, for this
particular use-case (with an app like the metronom being in
foreground), the lifecycle policies only state: The system is
responsible for providing the currently focused app with all required
resources (CPU, GPU, Memory, HW access) to ensure that it is working
correctly. Ideally, the system should be able to determine the set of
required resources automatically, ultimately informing powerd of the
requirements. For the metronom, this would specifically mean CPU
cycles, memory (both for sampling/resampling) and access to the audio
HW. With that information, the system can automatically prevent those
components from sleeping (under the assumption that we can control
suspend states fine-grained enough).

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

Agreed, with an emphasis on "whenever I use it", that is, having it in
the foreground.

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

I would rather want to avoid exposing an API that enables apps to
control the power state of the device or its components.
As a replacement, I would propose that our system services providing
HW/resource access are clever enough to inform powerd of specific
requirements. I know that this kind of functionality has been
discussed multiple times and I'm looping in Seth Forshee and Michael
Frey here.

HTH,

  Thomas

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