Hey, On Sun, Jun 22, 2014 at 5:43 PM, Fabio Colella <fcol...@gmail.com> wrote: > 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)
The download service should be a good starting point here, with background synchronization being somewhat an exception. > IRC and messaging platforms not covered by "Online Accounts" Push notifications FTW, they provide an easy and straightforward way out of the lifecycle trap. > Custom Keyboards and Lockscreens (this needs even more work) >From my perspective, custom keyboards and lockscreens are a different category. Allowing 3rd party components to replace security sensitive components requires us to think through all the possible security implications. Not saying that it is not possible, but it takes time and attention to detail to get it right in the general case. > Firewalls, antivirus, antispam (may become useful when the platform becomes > popular, we should take them in account) They would fall roughly into the same category as background synchronization. > 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. > Sure, and I would like to add security and privacy on top: Any app or service running in the background can easily spy on the user. The flashlight-app on Android harvesting a user's location is one of the prominent examples why this is an actual issue (see [1]). Not having ordinary app's or their services (intents) running in the background helps a lot in establishing and maintaining a clean state. > 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: > Do you refer to system- or app-provided background services here? > should need an Apparmor permission If we ever allow background services provided by apps, they will be confined. > should warn the user that the app uses background services We are about to implement this feature for system services. For app services, this trust model does not hold as you cannot force an application author to prompt the user for trust. > should be killable/pausable by the user and visible in the home scope and or > in the notification area Ideally, the user should not need to take care. Please note that I'm not assuming us, i.e., the subscribers to this mailing list, but non-tech-savvy users that expect the phone to "just work". > 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 > We can certainly come up with a lot of interesting heuristics, infer information from usage patterns of the phone etc.. However, they are still heuristics and we would loose a very important property of the system: Predictable battery life & secure system behavior, no matter what applications are installed on the phone. That being said: Instead of loosening the strict lifecycle policy we should instead focus on expressing our use-cases within the lifecycle framework: (1.) Identify common functionality that should be factored out into system services. (2.) Leverage click hooks for injecting app-specific behavior into services, under well-defined and strict security confinement and resource restrictions (5 seconds max., limited amount of main memory, no GPU access...). Thanks, Thomas > 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. > [1] http://www.techrepublic.com/blog/it-security/why-does-an-android-flashlight-app-need-gps-permission/ > -- > 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 > -- 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
