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 <[email protected]> > >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 <[email protected]> > >> 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 : [email protected] >> Unsubscribe : https://launchpad.net/~ubuntu-phone >> More help : https://help.launchpad.net/ListHelp >> > > > > -- > Rasmus Eneman > -- Rasmus Eneman
-- Mailing list: https://launchpad.net/~ubuntu-phone Post to : [email protected] Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
