ubuntu-phone team mailing list archive

[Rasmus Eneman <Rasmus@xxxxxxxxx>]

One simple add:
I do say background services a lot, however just letting apps run in the
background would basically be the same thing. That's a weigh between
simple code (portability?) and forcing developers to not do anything
"graphical" while in the background.


2013/10/27 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
>



-- 
Rasmus Eneman