Processing location updates in the background

[Sturm Flut]

We have a number of applications which need to process location updates in the background, e.g. the following:

- Navigation apps
- "Anchor watch" (alerts you when the device moves more than x meters from the initial position)
- Fitness trackers
- General purpose loggers
- Geofencing for various things, e.g. "remind me to buy butter the next time I am around the supermarket"

Each of these have different requirements:

- It might be simply enough to track the location in the background, but don't process anything, and just give the app the cached list of updates as soon as it is focused again.

- It might be necessary to just react to an event, for example "location deviated more than x meters from point x", "more than x seconds have passed since the last update", "GPS became available/unavailable" etc.

- The app might have to do an unknown amount of arbitrary processing on the data, e.g. there are fitness trackers which process every GPS update that comes in, smoothen across multiple samples to remove jitter, do text-to-speech and upload the data to a cloud service all in one go. Navigation apps might also have to do quite a lot of work, e.g. they can alert you about dangerous locations so they need to access the map data in the background.

This list is incomplete, we cannot anticipate every use case our developers might have.

The proposed solution was to register a callback handler with location-service instead of allowing the application to do background processing, but I see the following challenges with that:

- We have to limit the execution time of the callback handler somehow, but how do we find a limit that matches all devices, all situations and all use cases?

- The callback handler binary has to be freshly executed every time something happens, load all the context, process the location update, and then exit. That's quite a lot of overhead compared to an app-supplied background process that just loads all the context once in the beginning and then blocks on D-Bus calls between updates.

[Alberto Mardegan (mardy)]

At least for the third case, I would propose adding a new security policy, like "location-unfocused", which behaves mostly like the "location" policy. The difference being, that when an application carrying this policy asks for permission to use the GPS, the location service would show a different prompt to the user, where it's clearly communicated that the application will continue running in the background.

In such case we should also change the OOM setting for this application, to make it less likely to get killed than an ordinary app (reason: think of a navigation app for cyclist, which alerts you with sounds about where to turn; if it just dies, you are unlikely to get to your destination :-) ).

If we can introduce some limitations on the CPU usage (such as: let the application run only for the first X milliseconds after having received a location update) instead of just letting it run all the time, that could be a nice plus.

[Matthew Exon (ubuntu-mexon)]

For completeness, a slightly different use case. WeChat has a nice feature whereby you can share your continuously updated location with a group of friends. It's perfect for when you're all meeting somewhere unfamiliar, avoiding having to give complicated directions and keeping each other up-to-date with last-minute changes of plans. But it doesn't work, at least on iOS6, because as soon as you switch to another app you disappear from the map! There are two ways to correctly fix this problem, push and pull. With push the phone would detect when location has changed significantly and send an update to the group. With pull other phones would regularly request an updated current position. In either case I need my friends to see my current location even if I don't have the app focused.

[Thomas Voß (thomas-voss)]

I think we should disentangle the use cases a little, Geofencing and notification for signification location changes are clearly a missing feature of the location service (see https://bugs.launchpad.net/ubuntu/+source/location-service/+bug/1507474). The really interesting bit are the navigational use-cases. They imply 3 things:

  (1.) The application should not be sigstop'd when not focused, instead, it should be kept running albeit throttled in terms of resource usage.
  (2.) Suspend of the system should be inhibited such that navigation can keep on going.
  (3.) All apps operating in navigational mode have to be clearly visible to the user and surfaced in the location indicator.

With that, I'm proposing an extension to the location-service session API for applications to request navigational mode (in addition to just requesting position/heading/velocity updates). The additional semantic information allows us to tackle (1.), (2.) and (3.) throughout the system.

[Sturm Flut (sturmflut)]

Thinking about your idea: wouldn't it be possible to extend this "navigational mode" into a general "throttled background mode" and add escalations for the worst case? E.g. when a process running in the background hits the limit too often, the user is notified of it "misbehaving" and has the option to accept it (because she values the service the app provides more highly than battery life) or not. If it continues to hit the limit and the user doesn't react (e.g. because it's in the middle of the night and she is sleeping) the process gets frozen until the user decides.

The system call that is to be used to register a background process can carry as many semantic flags as we want, e.g. PRIORITY_POLL for processes that need a very very low limit because they just poll a network resource once every two minutes, or PRIORITY_BURST for a process that performs an one-shot heavy workload for a short amount of time, e.g. when the camera app needs a minute of full power to stitch a panorama together. The specific limits could be shipped with the device tarball (e.g. PRIORITY_POLL could be adjusted per device so that it usually doesn't have to increase the frequency and wake up a fast core), and when the device is connected to external power the limits could be increased or even lifted.

This would somehow pretty much solve the whole background processing question: It avoids excessive battery drain in the case of an error, the developer has a consistent experience on all devices and form factors (she can always have background processing, just the amount of available resources varies), everything always stays inside the app container and its address space(s), all the error cases (e.g. a failing network connection) can be handled by the app itself, it doesn't block the implementation of any use cases we don't yet know about, it should be quite easy to implement, and it takes all the load off of the platform developers who would have to maintain a long list of specialised background system services otherwise.

[Thomas Voß (thomas-voss)]

Sure, it is only one ingredient to a working solution, though. Also note that our lifecycle
already states exactly this behavior. The difference you are observing in reality is that we are selecting
the threshold very strictly.

Involving the user in any of these decisions is something we are trying to avoid at all cost.
Popping up a warning/notification for "misbehaving" background apps is a difficult thing to do.
Specifically as classifying "misbehaving" is notoriously difficult to get right in the general case. The other concern here is
that the assumption has to be that only a minority of applications is "misbehaving". I don't think that will be the case given our
minimal app review.

Also note that the app "tagging" its request is essentially what I'm proposing. But instead of relying on a central place
to go to, it is mediated by the respective helpers. Also note that I'm not proposing to split up an app by default, although I think
we should enforce clear separation of concerns within an app over time (it is just good practice, ultimately, and most developers will happily adhere to it).

[Randall Ross (randall)]

Tricky feature to get right, to say the least.

My point of view is that an app is "misbehaving" if it is in the background and is:
1) Consuming more resources than the app that has focus (or a significant portion thereof), and/or
2) Is consuming location data when I did not explicitly want it to do so, and/or
3) Is sending data to a third party <--- this one should send very obvious warning to the device owner

[Krzysztof Tataradziński (ktatar156)]

Any ETA for solving that bug/feature?

[Robin Heroldich (robinheroldich)]

I'd like to ask the same as Krzysztof: Is there any ETA for this? It'd be really useful for me. I use Activity Tracker 4 times a week for running and I need to charge my phone before every trainings, because it uses too much power with screen on.