ubuntu-phone team mailing list archive

[Roman Shchekin <mrqtros@xxxxxxxxx>]

Hi folks

First of all:

> I also really thing something should be done about this, even if you
> create a user override, allowing applications to multitask in the
> background.  Like you give permissions for applications to use the GPS.
> Then the battery life would be the users choice, personally i was looking
> for a Linux machine in my pocket that is what got me excited about Ubuntu
> Touch, but instead i got smoke an mirrors, i use Linux a lot in my life,
> computers make our lives easier when they are working for us 24/7 not only
> when we are looking at the screen.  Choosing Open Source over closed source
> is about freedom, so any choice should be based on user choice not some top
> down idea, force onto everyone.
>
> Lets get this fixed.
>

I agree with that guy for 100%. Said like God.

Now about business - why don't you want to make *an system-wide option* of
services availability? User will be able to control it himself!


2015-10-01 15:39 GMT+03:00 Krzysztof Tataradziński <ktatar156@xxxxxxxxx>:

> Hello,
> I want submit only one small note
>
> 2015-10-01 14:04 GMT+02:00 Thomas Voß <thomas.voss@xxxxxxxxxxxxx>:
>
>> Hey Simon,
>>
>> Thanks for your thoughts and ideas. Please find my suggestions and
>> replies inline:
>>
>> On Thu, Oct 1, 2015 at 1:16 PM, Sturm Flut <sturmflut@xxxxxxxxxxxxxx>
>> wrote:
>> > Good morning dear list,
>> >
>> > this has been brewing for quite some time now and the discussion
>> > Krzysztof Tataradziński started a week ago didn't lead anywhere again,
>> > so I'm starting it yet another time:
>> >
>> > In my opinion the "no background processing for apps on the phone"
>> > design decision is wrong, is already hurting us too much and has to be
>> > revoked as soon as possible.
>> >
>>
>> To state this very clearly: We are looking at a continuum of potential
>> solutions here.
>> It is unfortunately not as simple as just revoking one solution and
>> picking another one, but
>> all the different objectives have to be balanced. To this end, let me
>> clarify some of the guiding
>> principles and objectives that have to be accounted for in the context
>> of lifecycle policies:
>>
>> (1.) Battery life: One of the scarcest resources on a mobile device
>> and something that we aim
>> to protect as much as possible. Allowing arbitrary background
>> processing hurts a lot here, with Android's
>> lifecycle approach being one of the examples where battery life
>> deteriorates and becomes unpredictable
>> depending on the apps that have been installed on the device. Now this
>> wouldn't be a problem for the
>> quite technical audience subscribed to this mailing list. But it is
>> certainly an issue for the average user who
>> should not be forced to maintain a list of running apps and processes
>> just to achieve sensible battery life.
>>
>> (2.) Security & privacy: One of the worst case examples are apps
>> running in the background, feeding on a device's
>> sensor data and sending it off to the cloud. There have been numerous
>> examples exploiting the issue on Android.
>> Again, the technical audience subscribed here would be fine, the
>> average user likely is not.
>>
>> (3.) Predictable performance: A phone is expected to perform whenever
>> it is needed to, and the application being front & center
>> to the user should provide a smooth and crisp experience. To this end,
>> the system has to be able to assign as much performance-relevant
>> resources as possible to the currently focused app. If arbitrary
>> background processing is allowed, the respective scheduling problem
>> becomes
>> very very hard to solve (if possible at all).
>>
>> Please note that there are way more aspects to this problem space than
>> just the three points I elaborated on before.
>> The key point is: For a technical or tech-savvy audience, the
>> lifecycle approach we are taking for the phone might seem overly
>> restricted.
>> However, for the average user, such a harsh policy comes with a lot of
>> benefits.
>>
> But average users don't want to use phone that is limited in that way.
> For now that system is for some technical guys; if we want to target
> Ubuntu Touch for larger audience we need provide ability to work apps in
> background - why people use smartphones a lot of time? Because they can
> track their sports, use their favorite chatting app (and get notifications
> from it, even when it's 'closed'), get synced data from cloud, get notify
> about attack on their castle in favorite online game, etc.
> If we don't allow to do that things in easier way, Ubuntu will don't get
> too much big market apps, consequently Ubuntu will don't get too much
> non-technical users and that harsh policy wouldn't be useful for any one -
> there will be no people to appreciate that harsh policy.
>
>>
>> > Why? Let me make a list of examples.
>> >
>> > - Open Telegram for Ubuntu, send a picture to a friend, switch to
>> > another app or scope. On any other platform the message would continue
>> > to be sent in the background, but not on Ubuntu. Now you might say
>> > "Telegram is going to become a Telepathy plugin, and that one can run in
>> > the background", but there is no sign of a Telepathy system service and
>> > even if it were already present, you're now forcing everybody to build
>> > Telepathy plugins for their services. That's just not going to happen.
>> > Let's be honest, WhatsApp and Viber and friends will not go this way for
>> > a number of very good (economic) reasons.
>> >
>> > - Notifications for the myriads of services out there. On any other
>> > platform the app would just register a small background service that
>> > wakes up every minute or so and then goes to sleep again. Now you might
>> > say "We have the Ubuntu Push Notifications service for that", but that
>> > requires the service provider to change his whole server side, which
>> > noone except Telegram does. That's why we already have to run
>> account-polld.
>> >
>>
>> That's actually not true in the general case. Most often, the services
>> use the platform's push notification
>> infrastructure to deliver updates. Please note that we require
>> account-polld to work around the limitation that
>> facebook, twitter and google have not integrated with our infrastructure
>> (yet).
>>
>> > - An app that processes location updates in the background, e.g. a
>> > fitness tracker or a navigation app. Now this is IMO the best example
>> > for how the "no background processing" decision complicates everything
>> > to infinity: The simple solution would be to have a small background
>> > service that just does whatever it has to do. But since we can't do
>> > that, we have to come up with a very convoluted system that most likely
>> > involves registering for some list of events with location-service,
>> > which then calls a small handler binary provided by the app (like the
>> > push notifications design). But how do you prevent that handler from
>> > running amok, or from just keep running in the background? Ah, yeah,
>> > kill it after five seconds, like the push notification handlers. But
>> > five seconds on a slow CPU aren't much when I e.g. also have to do some
>> > I/O and use D-Bus, while five seconds on a fast CPU are a lot of time if
>> > I don't have to do much. So what's the right maximum runtime for a
>> > handler that covers all use cases? There is none. Will location-service
>> > support all the event/filter/callback options I need for my specific
>> > app? Most likely not.
>> >
>>
>> It will grant a certain amount of processing time to your app or
>> better its location update helper. A fitness tracker could easily just
>> store
>> the respective update for later processing. A navigation app would
>> require more sophisticated schemes, but we are happy to evolve the
>> service as required (as pointed out earlier).
>>
>> > - Cloud and P2P services like Owncloud, Dropbox, Syncthing, Tox etc.
>> > Apps that control devices via Bluetooth, like my FitBit or a Smartwatch.
>> > What's the design for those? More system services? We can't afford to
>> > write a system service for each and every use case. That doesn't scale.
>> > It already isn't scaling right now. And even if we could, is the
>> > proposed solution really to have 100 system services running for all
>> > users, instead of five to ten third party background processes that the
>> > user really needs and knowingly installed herself?
>> >
>>
>> We would not write a system service for each of them, but instead
>> provide a framework to handle the specific problem area.
>> It is a lot of work to get those frameworks right, and your help is
>> obviously greatly appreciated in doing so. Other than that, it is
>> really really easy
>> to integrate cloud services with the content-hub infrastructure and
>> thus exposing the content in the system.
>>
>> > I can come up with many more examples for how this is simply
>> > complicating our lives, and for what reason? A (tiny) gain in battery
>> > life.
>>
>> Please see the initial list of objectives and guiding principles. On a
>> very personal note, I don't think the aim should be to make "our" life
>> easier but
>> to make the life of users as pleasant as possible. If that means to
>> come up with novel and probably harsh solutions and policies to
>> address certain
>> problems ... that's what it is.
>>
>> We have many apps that cannot be built/ported right now because we
>> > are waiting for APIs and system services that haven't been coming for a
>> > year now and only have to be created because we can't just run in the
>> > background. Do we even know if the effect on battery life is really
>> > worth it? I challenge you to run e.g. Dekko as a lifecycle exception and
>> > check if the background polling is noticeable. Because it's not like
>> > those system services don't consume any resources at all, the work has
>> > to be done by somebody. A "bad" Telepathy plugin will consume just as
>> > much resources as a "bad" background process, the "better" design of
>> > using Telepathy alone is not going to prevent this.
>> >
>>
>> They do consume resources, for sure. The point is: A fixed set of
>> system services controlled and maintained by us results in predictable
>> battery life (modulo bugs).
>> The real question is not if battery life would deteriorate for
>> allowing a specific app to poll in the background. Instead, the
>> question has to target the general behavior of
>> the system with arbitrary apps being installed in the system.
>>
>> > What also really confuses me about this issue is that the "no background
>> > processing" approach apparently only applies to mobile devices and
>> > confined apps. Isn't that somehow against the whole idea of an Ubuntu
>> > that is the same on all devices?
>> >
>>
>> It certainly is not. A lifecycle policy is always specific to a
>> device, its resources and even the specific usage scenario.
>> With that, allowing multiple apps to run even if not focused in
>> desktop-like use-cases is perfectly fine. Even altering the behavior
>> in case of a phone being plugged in to a power supply would be perfectly
>> fine.
>>
>> > I would really like to hear all your thoughts on this and how we're
>> > going to solve the situation, because we quite frankly have actual
>> > problems (broken GPS, no SD card support for apps, no Bluetooth, no SIM
>> > Toolkit, etc.) which should have a much higher priority than building
>> > convoluted and complex designs just to potentially save three hours of
>> > battery life over the course of a week.
>> >
>>
>> As pointed out in my introductory comment: battery life is one of
>> multiple concerns we have to address.
>>
>> Cheers,
>>
>>   Thomas
>>
>> > cheers,
>> > Simon
>> >
>> > --
>> > Mailing list: https://launchpad.net/~ubuntu-phone
>> > Post to     : ubuntu-phone@xxxxxxxxxxxxxxxxxxx
>> > Unsubscribe : https://launchpad.net/~ubuntu-phone
>> > More help   : https://help.launchpad.net/ListHelp
>>
>> --
>> Mailing list: https://launchpad.net/~ubuntu-phone
>> Post to     : ubuntu-phone@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~ubuntu-phone
>> More help   : https://help.launchpad.net/ListHelp
>>
>
>
> --
> Mailing list: https://launchpad.net/~ubuntu-phone
> Post to     : ubuntu-phone@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~ubuntu-phone
> More help   : https://help.launchpad.net/ListHelp
>
>