ubuntu-phone team mailing list archive

[Rasmus Eneman <Rasmus@xxxxxxxxx>]

>I think we are misunderstanding; I'm not saying that the user should be
>asked (at install time or at run time) for granting a permission. There
>would be a policy groups "background_gps", "background_music" which the
>app developer can declare in its manifest file. Then, if the application
>is defocused while it's using the GPS or playing music, it wouldn't be
>stopped. If it's not using the GPS or playing music, it will be stopped.
>It seems much simpler to me, and I don't see what could go wrong here.

Personally I don't really see a win by doing this instead of an ordinary
wakelock,
it creates a lots of policy groups and the developer can still do the same
stuff.

One thing I thought about is a "two staged" background running process.
By default each app can only use a very limited one with very capped CPU,
network and may easily be killed if needed. And one that requires a user
confirmation that enables more conventional background polices and let the
app use more CPU, network and isn't killed unless really necessary.

One other idea is too change "recent apps" into "running apps" or add a
category for running apps (however I don't think that would be necessary,
stopped
apps may still be in here. For what the users worth it's still "running").
Then the user sees very easily what's running and may choose to stop it if
wanted.

If an app is closed (from "running apps" or the HUD) it should be really
closed,
and no background processes or anything should be running.

I think this simplifies the Android model quite a bit, while still giving
the same
flexibility and makes the user more aware of what's running and why. By
having a user aware of this battery is saved. This would also make users
feel
that the phone works similar to the computer they already uses.

This together with the already suggested things to limit the things apps
need
background services for could be a pretty good solution.


2013/10/27 Alberto Mardegan <alberto.mardegan@xxxxxxxxxxxxx>

> On 10/25/2013 08:48 PM, Thomas Voß wrote:
> > One thing that strikes me: Instead of trying to solve the problem a
> > lot of "won't work" statements are made in this thread, going along
> > with a request for removing all of the lifecycle policies. And to be
> > clear: With strict policies in place, it is always possible to find an
> > example that breaks. So I think we can stop collecting breaking
> > examples here.
>
> I think that Ubuntu should strive to do *better* than other platforms,
> not equal or worse. So, given that we are at the early stages and we are
> still in a position to correct the design and improve the
> implementations, we should spend some time to think of use cases which
> we don't support with the current design, and address them.
>
> Especially given that it might not be easy to change this stuff in the
> future.
>
> >> Yes and no. As I wrote before in this thread, in some cases it's
> >> possible to detect when an application will need to run or can be
> >> killed. We don't have to allow all applications to run in the
> >> background. But why not let a navigation application declare in its
> >> manifest file that it wants to be left running if it's defocused while
> >> the GPS is on?
> >
> > Because that is an open invite to any app developer to leverage that
> > way out, too. We do not do install time application permission
> > verification by the user for a good reason.
>
> I think we are misunderstanding; I'm not saying that the user should be
> asked (at install time or at run time) for granting a permission. There
> would be a policy groups "background_gps", "background_music" which the
> app developer can declare in its manifest file. Then, if the application
> is defocused while it's using the GPS or playing music, it wouldn't be
> stopped. If it's not using the GPS or playing music, it will be stopped.
> It seems much simpler to me, and I don't see what could go wrong here.
>
> >> As for GPU resources, Qt can release all of them when the window is not
> >> exposed, if told to.
> >
> > Hmmm, people said that about cooperative multi-tasking, too: Sure, the
> > app will happily give up its timeslice (tm).
>
> You are right that we cannot depend on this. But the display server can
> know the amount of GPU resources that each application is using, and
> kill those which use more of them; in this way, an application which
> properly releases all the GPU resources would probably be saved.
> Anyway, I now realize that this is actually not the issue we were
> discussing (this is about killing, while the discussion is about
> stopping), so we can forget about this second topic. :-)
>
> Ciao,
>   Alberto
>
> --
> 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
>



-- 
Rasmus Eneman