ubuntu-phone team mailing list archive

[Rodney Dawes <rodney.dawes@xxxxxxxxxxxxx>]

On Thu, 2014-06-26 at 07:50 +0200, Thomas Voß wrote:
> On Wed, Jun 25, 2014 at 11:17 PM, Rodney Dawes
> <rodney.dawes@xxxxxxxxxxxxx> 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.
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). 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.

> 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 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.

> 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. 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.

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. :-/