Am 25.06.2014 11:12, schrieb Thomas Voß: > On Wed, Jun 25, 2014 at 9:41 AM, Benjamin Zeller > <benjamin.zel...@canonical.com> wrote: >> Am 24.06.2014 11:14, schrieb Thomas Voß: >>> On Mon, Jun 23, 2014 at 11:32 AM, Fabio Colella <fcol...@gmail.com> wrote: >>>> 2014-06-23 9:12 GMT+02:00 Thomas Voß <thomas.v...@canonical.com>: >>>> >>>>> 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. >>>> Yes it is, but the limit is that a developer always needs to wait that the >>>> feature is system implemented before he/she can create an app like that. We >>>> may think this today, maybe tomorrow torrent will be obsolete and new apps >>>> will need to wait until a new service is created to support this. >>> As I pointed out earlier: A strict lifecycle is a somewhat more >>> conservative choice to ensure predictable behavior for the average >>> user. Please also note that the lifecycle policy is meant to be >>> swappable for different usage scenarios, e.g., if the phone is docked >>> or connected to a power supply, we could adjust the policy to be less >>> strict. However, adjusting the policy requires deep thought about the >>> implications. >>> >>>>>> IRC and messaging platforms not covered by "Online Accounts" >>>>> Push notifications FTW, they provide an easy and straightforward way >>>>> out of the lifecycle trap. >>>> Seems this is fully covered. So, if I understood correctly, if I create a >>>> new messaging app I can also use push notifications to make my app listen >>>> while waiting for a new message. Right? >>> Yup. >> Push notifications are great, but how would you implement a app that can >> not communicate over Push? Lets take a simple example, a IRC client, >> we can hardly ask the user to install a own Push "proxy" somewhere just to >> use that client. > Well, that's debatable, specifically for the case of IRC. I would love > to see an IRC app that provides an IRC proxy ootb (ignoring privacy > issues here). In general, I agree with your point though :) There is a thing called tapchat: https://github.com/codebutler/tapchat which seems to be a IRC bouncer with push capabilities. But you need your own server to install it somewhere. There are apps for android but they are closed, I did not check the licence of the backend but it might be interesting for us if its open :). > >> Also a IRC server will not buffer your communication so you need >> to be able to react on socket events. Running it as a app does not work >> either, because as soon as the app goes into background it will be stopped. >> >> Maybe you even want to get notifications if the app is not open at all. >> >> How about using telepathy backends for things like that? > I think we shouldn't tie to specific implementations here and think in > more general terms that are applicable to all app developers. Still it would be awesome if a developer could provide his own telepathy backend ;). > >> Or alternatively a trusted helper that wakes the app/backend when data is >> available on a socket/filedescriptor? > Dispatching to a service-specific helper type definitely is an option > here, but we should (and will not) wake/start the entire app. > So seems like the general service would be a network/communication-hub > that monitors a socket for readibility & dispatches to app-specific > helpers. I don't think that helpers should be able to write back to > the network, but only be allowed to "translate" to device-local push > notifications. Otherwise, we would sign up for security issues with > helpers sending out information in the background. I agree with the security issues here, but depending on the protocol you might need to send "still alive" messages to the server. So at least there needs to be a way to wake the service somehow.
Also there needs to be a place where the app can pick up data that was received when the app was stopped/closed What we definitely need is a indicator that there is a IRC/whatever service running in the background. Maybe a services scope? > > One other thing that would have to be considered is the impact of > long-standing network connections (as would potentially be maintained > by the service) on battery life. We did some testing in the past, will > find out the results and share them here. At any rate: I think we > should work hard to stick with a push model as opposed to a pull > model. I'm using a Jolla phone with a IRC client atm, the impact on my battery life is not very dramatic but there is definately a difference. Also isn't Push nothing more than a long running request to the server? Which makes it a long running network connection as well, its just a more predictable one. Benjamin > > Thomas > >>>>>> 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. >>>> I agree with you, keyboards in particular have access to lots of sensible >>>> data and should be privacy safe. >>>>>> 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. >>>> Antispam and firewalls may probably be implemented the way you say because >>>> they're relatively download related. How would something like an Antivirus >>>> be in the same category of data sync? I also think that it would require >>>> whole disk access, or at least the whole user partition. Could a service >>>> like ADBlock be implemented using background download service? >>> Not sure why ADBlock would have to be a service. @data sync and >>> @anti-virus: Both need almost unconfined access to the system, both in >>> terms of access to files and in terms of lifecycle exceptions. >>> >>>>>> 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. >>>> If we will have a service for GPS in background, like a Runtastic app, this >>>> will be something that could happen even on ubuntu. The only way for me is >>>> to prompt the user to have access to background services. >>>>>> 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? >>>> Both, one for system ones and one for app-provided ones. >>>>>> 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. >>>> My idea is that you would need to ask the permission for background >>>> services, like many android apps do to auth google+ connection. It could be >>>> a system prompt: "The app %s is asking access to use background services". >>>> Then if the user presses 'yes' the app will have the apparmor permission >>>> for >>>> backgound services, not before. >>> And Android is the platform famous for inferior battery life ... >>> partly due to arbitrary apps (or their intents) being allowed to >>> execute in the background. The reason is simple: Most users will just >>> reply "yes" to the permission screen, assuming that the system >>> ultimately takes care (which it should). I don't think that we should >>> assume the user to maintain the list of running applications or >>> running background services. Instead, we should aim for doing the >>> right thing, even if the "right thing" for a particular usage scenario >>> (mobile device, not connected to power supply) is more >>> conservative/strict than what a tech-savvy user is used to. >>> >>>>>> 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". >>>> Pause and play could have the music icons, so could be easily recognizable >>>> and would be equally easy also to use. >>> Please see my comment before. A user shouldn't need to >>> maintain/administrate his/her phone to ensure good performance and >>> battery life. >>> >>>>>> 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. >>>> However we could loose many useful apps, or being able to implement them >>>> only months after an Android one is released. >>>> The predictable battery life would be equal, even background services >>>> should >>>> follow the policy of the other services and require really few resouces. >>> The devil is in the detail here: Implementing "require really few >>> resources" is difficult to achieve in the general case. >>> >>>>> 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...). >>>> I think that you have many good reasons for that but finding every use case >>>> seems to me an utopic task. >>>> (joke: ready for next relase? XD) It would have the side effect of being >>>> slow on innovation. >>> Looking at other platforms, I wouldn't say that iOS is slow on >>> innovation, despite its lifecycle being strict. Instead of looking at >>> Android as a reference here, we should try to distill common >>> background functionality required by classes of applications and >>> provide services for those. >>> >>> Cheers, >>> >>> Thomas >>> >>>>> 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. >>>>>> >>>> Thanks, >>>> Fabio >>>>> [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 -- 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
