On Thu, Jun 26, 2014 at 5:07 PM, Rodney Dawes <rodney.da...@canonical.com> wrote: > On Thu, 2014-06-26 at 07:50 +0200, Thomas Voß wrote: >> On Wed, Jun 25, 2014 at 11:17 PM, Rodney Dawes >> <rodney.da...@canonical.com> wrote: >> > On Wed, 2014-06-25 at 17:10 -0300, Sergio Schvezov wrote: >> >> On miércoles 25 de junio de 2014 16h'29:10 ART, Rodney Dawes wrote: >> >> > On Wed, 2014-06-25 at 14:44 -0400, Marc Deslauriers wrote: >> >> >> On 14-06-25 02:11 PM, Rodney Dawes wrote: ... >> >> > >> >> > No. It means the app is running, whether it is in the foreground or >> >> > background. It doesn't need to be the current foreground app. Running >> >> > apps, the automotive data logging app I linked, etc… continue running >> >> > even in the background, to be able to monitor location, log performance >> >> > data from BT/ANT+ devices, and perform actions based on location or the >> >> > data stream from a connected device. >> >> >> >> Please take the time to read the full length of the document I linked to. >> > >> > The Apple doc? It clearly indicates to me that long-running background >> > processes remain running. >> > >> >> Okay, let's take a look at the iOS documentation: > >> The background execution state is not a persistent state, it is a >> transitional one, with "Suspended" (a.k.a. SIGSTOP'd) being the usual >> follow-up state. Also note that the system reserves the right to >> transition apps from "Background" to "Suspended" or even "Killed" at >> any time. The grace period that apps can request cannot be extended >> indefinitely. Obviously, both iOS and Ubuntu try to keep as many apps >> as possible in the "Suspended" state to ensure fast resurrection >> (i.e., SIGCONT) of apps. However, in the case of Ubuntu, if memory >> pressure arises, the oldest suspended apps are automatically killed. > > No. There are TWO levels of background state on iOS. There is the > short-term background processing state, which is what you're talking > about. There is also a long-term background processing state. Please > read the FULL documentation there, and not only the first paragraph. In > particular see this section: > > https://developer.apple.com/library/ios/documentation/iPhone/Conceptual/iPhoneOSProgrammingGuide/ManagingYourApplicationsFlow/ManagingYourApplicationsFlow.html#//apple_ref/doc/uid/TP40007072-CH4-SW24 > > It explicitly states that apps declare in advance that they use > long-running background tasks. When declaring one or more of the > background modes as documented in this section, the app is continually > running, or waked from the sleep state, in order to process such events.
And the flag is subject to review iirc. > These apps are not shoved into STOP and left there until the user brings > the app back to the foreground, nor are they arbitrarily killed (unless > there are extenuating circumstances that might require it). We don't kill apps either without further notice either. They get a chance to save their state. Did you actually take a look at our SDK docs? > The apps are > live and have plenty of time to process things before being put back to > sleep state. On iOS, the app can even see how much time it has left > before being killed, and can request more time when processing in the > background. > Which the system might or might not grant to the app. >> Please also note that our lifecycle explicitly states: We only >> guarantee an app to be running while it is in the foreground. If it is >> in the background, it may or may not be running. This is exactly the >> same contract between the apps and the system as on iOS. Sure, we >> might think about extending grace periods before suspending an app, >> but we are free to do so as we did not, should not and will not give >> any guarantee on the amount of resources granted to an application >> running in the background. > > It is not exactly the same contract as iOS. It is similar. The contract > in iOS depends on what the app declares it needs, in advance. I've also > seen no evidence that iOS actually uses STOP/CONT for background > processes in this case. The documentation says "sleeping" or "suspended" > but does not clarify what that means exactly. Given the list of items > under "Being a Responsible Background App" though, it seems this is more > likely to be the "Sleeping" state and not SIGSTOP. > >> The difference between sleeping and stopped is significant, though. >> Sleeping means cooperation by app authors which we cannot assume. >> Stopped can be and is enforced by the system according to our >> lifecycle state machine. > > Sleeping can be enforced somewhat "somewhat" is not what we aimed for. > by creating CPU quotas, and it is > possible to examine apps for bad behavior in a sandbox during automated > review. It simply requires the effort to do so. If we can reliably wake > from SIGSTOP and have the app respond to callbacks, it doesn't matter to > me if it's actually sleeping or STOP though. The important part here is > that the app is waked by the system service, has its registered callback > run in its event loop, and that it can request more time to process if > needed. The same way it works on iOS. > I'm wondering if you tried writing an app for Ubuntu, yet? The SDK helps quite a bit with state-specific maintenance. >> They are transitioned to suspended once their grace-period has ended. >> One thing to point out: our lifecycle allows an app to be woken up (by >> calling out to lightweight helpers) whenever important events >> happened. The set of important events is defined by the system >> services that Ubuntu offers. While app authors will certainly say: >> *My* app needs more, because *my* app does super important and useful >> things with event x,y,z in the background, I don't think that we >> should give in to that. As pointed out earlier: Just periodically >> waking up entire applications is a naive sampling approach to the >> problem of identifying and understanding events and services that are >> of real use to the *user*. > > It's not a matter of giving in or developers thinking their app is more > important. It is a matter of allowing developers to do what is needed > for certain activities. Sure, they get that and we will certainly identify further requirements in the future. At which point we will add features to satisfy common requirements. > A "lightweight helper" is not a solution to > this. It's unnecessary extra work for the developer. I don't think we > should have or encourage the concept generally. Maybe there is a > specific use case where they make sense, but I don't think they make > sense for the general background processing need. > Well, how is a lightweight helper not a solution? It is application code executed in the context of a specific event. Seems to be exactly the functionality you were asking for. > Ubuntu has no idea whether an event is important or not. If I'm a runner > or cyclist, and I"m using my phone to log data, then location, > bluetooth/ant+, and music events are going to be more important for me, > while I'm out on a run or biking. The way I tell the system those things > are important, is by using specific apps that tell the system those > things are important. Thus, the apps need to tell the system what is > important. That is exactly how it works on iOS. And it's pretty much how > it should work here. But from the conversation I've seen, that's not how > I understand it will work. :-/ > > > -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
