ubuntu-phone team mailing list archive

[Thomas Voß <thomas.voss@xxxxxxxxxxxxx>]

On Thu, Jun 26, 2014 at 5:07 PM, Rodney Dawes
<rodney.dawes@xxxxxxxxxxxxx> 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.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.

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