ubuntu-phone team mailing list archive
-
ubuntu-phone team
-
Mailing list archive
-
Message #08647
Background services: a problem that we need to face
Currently the app lifecycle may kill an app in any moment if the app is not
on focus. Most of the apps are designed to be used when focused, but there
are many other apps that require to work even when not in focus, many
examples:
- Running apps: should count calories and distance even when not focused
- Data Sync (Dropbox, OneDrive, GoogleDrive): should continue the
up/download and syncronization when not focused.
- Torrent apps(Transmission)
- IRC and messaging platforms not covered by "Online Accounts"
- Custom Keyboards and Lockscreens (this needs even more work)
- Firewalls, antivirus, antispam (may become useful when *the platform
becomes popular*, we should take them in account)
- Other things to which I'm not currently thinking to but that may be
useful
The current approach is to use system services to achieve the results: this
is what happens with music and messaging apps. The problem with this
approach is that we may end up with the need to create really many services
and still not cover all the needed requisites. On the other hand we may
just deny the developers and the users to create and use certain kind of
apps. The advantages of not allowing background services are mainly longer
battery life and better overall performances.
I think we should *find a compromise that allow the user to use apps that
need background services but also makes him/her free to stop/resume them.*
My idea for background services:
- should need an Apparmor permission
- should warn the user that the app uses background services
- should be killable/pausable by the user and visible in the home scope
and or in the notification area
- could be autokilled/paused when battery life is low (this approach is
the one used by Samsung, Google Drive, Dropbox) but should still allow the
user to resume the service if he/she needs it even on low battery
- could be paused/resumed according to the number of running apps and
services
My consideration is that the user should always end up being able to decide
what he/she want's to use and when. We put conventions (like stop on low
battery) over user configuration, but the user should still be *free* to
change it.
Follow ups