ubuntu-phone team mailing list archive

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

On Tue, Oct 22, 2013 at 8:06 AM, Alberto Mardegan
<alberto.mardegan@xxxxxxxxxxxxx> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 10/22/2013 01:46 AM, Jamie Strandboge wrote:
>> 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)
> [...]
>> 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.
>
> The case of an application using the GPS is interesting. The nice
> thing here is that the system can know that the GPS is on and that the
> application is listening to it, so it could let the application run
> even when in the background, without the need for a specific policy flag.
> Conversely, if the GPS is off, there's generally no point in letting a
> GPS application to continue running, and it could be stopped.
>

Along the same lines of the metronom app: If the gps app is in
foreground, the location service should signal to powerd that it
should not suspend at least the gps, probably the network, CPU (and
thus, memory access).

> And maybe we could have something similar for music apps? While there
> are many applications which could emit sounds, some need to continue
> playing while in the background (music player, metronome, etc.), while
> some don't (videogame).
> So, we could have a specific policy for apps who declare to be music
> players (or more generically, whose main task is to produce a sound),
> which makes it so that the app will not be stopped if it is currently
> playing (there should be ways to detect this as well). And again,
> conversely, such an app could be stopped if it gets in the background
> when it's not playing music.
>

I think we should avoid splitting policy and instead say:

  * If an application is using audio HW directly, make sure that the
specific system components are not suspended.
  * If an application wants to play music in the background, it can
dispatch to the music-hub.

Please note that whenever we enable app developers to define own
background services, the solution with the system being clever about
who uses certain resources of the system (gps hw, audio hw) just works
(tm) while the lifecycle policy can still be agressive and strict
w.r.t. application components providing UI components.

HTH,

  Thomas

> (where I used the expression "in the background" you can extend it
> with "or the display gets turned off")
>
> I think this would be much easier than using the music hub: both for
> the developer, which doesn't have to change its code just for Ubuntu
> Touch, and probably for us as well.
>
> Ciao,
>   Alberto
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.11 (GNU/Linux)
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iEYEARECAAYFAlJmFfsACgkQVLQegMXeCFLs5ACdEgO5u5ihdMiMgGip9eoNQQof
> DeQAnjKmQAtWbo2uLK7PFVTKGNDhRFRe
> =fxep
> -----END PGP SIGNATURE-----
>
> --
> 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