ubuntu-phone team mailing list archive
-
ubuntu-phone team
-
Mailing list archive
-
Message #15983
Re: The problem with "no background processing for apps"
I'm certainly not saying it's ideal, but anyway most people I know that run
use some sort of armband to hold their phone (I can't imagine how annoying
it would be running with a phone in my pocket). I actually like to keep
the screen on so I can glance at the time/distance, but that could just be
me :)
On Fri, Oct 2, 2015 at 10:32 AM, Michael Zanetti <
michael.zanetti@xxxxxxxxxxxxx> wrote:
>
>
> On 02.10.2015 16:22, Chris Wayne wrote:
> >
> >
> > On Fri, Oct 2, 2015 at 4:53 AM, Andrea Bernabei
> > <andrea.bernabei@xxxxxxxxxxxxx <mailto:andrea.bernabei@xxxxxxxxxxxxx>>
> > wrote:
> >
> >
> >
> > On Fri, Oct 2, 2015 at 9:18 AM, Thomas Voß
> > <thomas.voss@xxxxxxxxxxxxx <mailto:thomas.voss@xxxxxxxxxxxxx>>
> wrote:
> >
> > On Fri, Oct 2, 2015 at 10:04 AM, Craig Harper
> > <dexteruk75@xxxxxxxxx <mailto:dexteruk75@xxxxxxxxx>> wrote:
> > > I dont think you need to open any flood gates. I think we
> just need to
> > > break it down. Keep the policies as they are Strict Policy or
> you could
> > > call it Battery Saver Mode, this could be the standard mode
> that the Ubuntu
> > > Touch uses now, If people want to optimise application for
> this mode and use
> > > all the helper functions and system services. But creating
> other profiles
> > > that allow more user customised experience such a true
> multitasking,
> > > applications that need this mode and inform the users, that to
> use the
> > > application to its full potential you need to change the
> profile, with
> > > warnings about battery life, close applications when your not
> using them,
> > > etc etc.
> > >
> >
> > Please see my comment about UX later on.
> >
> > > This would also give developers a migration path, to move from
> a none
> > > optimised application, to a more Ubuntu Touch centric app, so
> still
> > > encouraging developer to port existing apps, without having to
> start of with
> > > how to get an app to work in a restrictive environment, once
> they see there
> > > application is getting users then they can invest time in
> optimising it.
> > > Maybe in the app store you can have Energy Efficiently rating
> for the app,
> > > to encourage developers to get there app optimised.
> > >
> >
> > Well, the same argument holds true in the case of a strict
> lifecycle
> > policy. Get a first port into the store,
> > potentially lacking functionality. Users will like your app,
> > and you
> > can start integrating deeper with the system without
> > us compromising on platform principles and guidelines, or
> negatively
> > impacting users out there.
> >
> >
> > Why would users like your app if it cannot even do the main task it
> > is supposed to
> > accomplish? (<insert any sport tracking app here>)
> > I'd expect a list of reviews like:
> > "this doesn't work"
> > "1 star, useless"
> > "it's useless, doesn't work when screen is off"
> > "what were you thinking? Do you think I keep my screen on when
> running?"
> >
> >
> >
> > Well, I did write a sport tracking app, and while people have complained
> > a bit about the screen needing to stay on, they're generally pretty
> > understanding and it hasn't been a big deal thus far...
>
> This might work if you have some dock on your bike or so where you don't
> constantly touch the screen but not when you want/need to keep the
> device in your pocket.
>
> Also, if keeping the screen permanently on in order to work around
> battery saving optimizations, something's gone very wrong...
>
> >
> >
> >
> >
> >
> > > In this scenario if the device is running low on power, the
> user can make a
> > > choice to switch back the the Battery Saver Mode. maybe with
> some useful
> > > information about an estimate how long battery will last in
> this mode
> > > compared to Road Runner mode.
> > >
> >
> > Now that's not really a great user experience, is it? Did you
> > ever see
> > something like that happening on iOS?
> > It's common on Android, and one of the "features" that people
> > complain
> > about a lot, including numerous guides
> > for fixing battery drain (see [1]). We can certainly do a lot
> > better than that.
> >
> > > I think from this conversation, that if there is a complaint
> about Ubuntu
> > > Touch its this one, MultiTasking is a must, we must have away
> to run
> > > application in background without them being specially written.
> > >
> >
> > Now that would be somewhat alien. Developers aiming at mobile
> > platforms are already used to structure their
> > applications differently, precisely for integrating with
> execution
> > infrastructure and services offered by the respective
> > platforms. I don't think Ubuntu is (or even should be) different
> > here.
> >
> > I'm wondering: Did you try developing an app for android or iOS?
> > It's
> > an interesting exercise :)
> >
> > Cheers,
> >
> > Thomas
> >
> > > Craig
> > >
> > > On Fri, Oct 2, 2015 at 10:46 AM, Thomas Voß
> > <thomas.voss@xxxxxxxxxxxxx <mailto:thomas.voss@xxxxxxxxxxxxx>>
> > > wrote:
> > >>
> > >> On Fri, Oct 2, 2015 at 9:20 AM, Benjamin Zeller
> > >> <benjamin.zeller@xxxxxxxxxxxxx
> > <mailto:benjamin.zeller@xxxxxxxxxxxxx>> wrote:
> > >> > Hey all,
> > >> >
> > >> > I also put my thoughts inline:
> > >> >
> > >> >> 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 <mailto: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.
> > >> >
> > >> > Agreed, having a solution that protects battery life is
> > important,
> > >> > however
> > >> > that does not mean we can't have a way for the advanced
> > user to allow
> > >> > _some_ processes to run in background. Probably something
> > that can
> > >> > be turned on in the system settings per application. Giving
> > full control
> > >> > over
> > >> > what can run in background.
> > >> >
> > >> > With convergence in mind, a user probably will need a way
> > to allow his
> > >> > terminal
> > >> > to run in background while it compiles something, lets also
> > make sure
> > >> > we can give solutions to a more technical audience. After
> > all this is
> > >> > the
> > >> > audience
> > >> > that uses Ubuntu Phone atm!
> > >>
> > >> Sure, I'm not opposed to having dev-mode settings that can be
> > >> leveraged by tech-savvy users. However, as saviq pointed out,
> > >> we have to avoid apps not working as expected if the average
> > user does
> > >> not opt-in. On top, if we just allow settings to be tweaked
> > >> there is no reason for app authors to pick up our platform
> > principles
> > >> and guidelines. The next step is a wave of apps in the store
> that
> > >> only work if you switch on certain settings on the device.
> > That's a
> > >> worst case scenario from my POV.
> > >>
> > >> >>
> > >> >> (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.
> > >> >
> > >> > But won't this be possible with a system service and
> > helpers as well?
> > >> > Lets say we have a system service that lets a helper
> > collect GPS data,
> > >> > won't the helper be able to upload that data?
> > >> > Because some apps might even need this, lets look at the
> > famous sports
> > >> > tracker
> > >> > example. It needs to collect your gps positions and upload
> > them.
> > >>
> > >> Well, that's debatable. We usually go for a very strict
> > setting (e.g.
> > >> in scopes) that prevents network access if access to local
> > >> resources is granted. You only get network access if the only
> > local
> > >> resources you access are the ones specific to your app.
> > >>
> > >> We surely cannot solve the problem of spying applications
> > once and for
> > >> all. But we can work hard to make sure that a user
> > >> stays on top of what apps _and_ the system is doing, putting
> > her in a
> > >> position of control and power.
> > >>
> > >> >>
> > >> >> (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).
> > >> >
> > >> > Couldn't that be solved by giving the background processes
> > time slots
> > >> > when they can execute? And probably an API to register
> > system resources
> > >> > that can wake them up for a time frame? Lets say a socket.
> > >>
> > >> Sure, moving processes to specific cgroups if they are not
> > visible to
> > >> the user is possible and something we have on the list
> > >> to explore. However, we are talking about heuristics, not a
> > solution
> > >> that will always work regardless of the installed apps.
> > >>
> > >> >>
> > >> >> 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.
> > >> >
> > >> > I still agree for the average user will benefit from that,
> > but until we
> > >> > reach
> > >> > that point of completeness we just lack critical APIs for
> > apps, and devs
> > >> > might not even start to write their apps or contact us to
> > tell: "Hey I'm
> > >> > missing
> > >> > this or that, could you implement it please".
> > >> >
> > >>
> > >> Well, I would argue that we already have a lot of feedback
> > that we
> > >> have to systematically work on.
> > >> We either go down the route of systematically iterating on
> > the system
> > >> capabilities or we open the flood gates and
> > >> just give up on our principles. Point being that taking
> > features back
> > >> is almost impossible
> > >>
> > >> > Another drawback of doing things completely different is of
> > course the
> > >> > higher
> > >> > cost in porting applications to our platform. There is no
> > way to port a
> > >> > Qt
> > >> > app
> > >> > that requires background processing to Ubuntu Phone without
> > rewriting
> > >> > big
> > >> > parts
> > >> > of it to use our system services and helpers. So the
> > porting is no
> > >> > longer
> > >> > effortless
> > >> > thus appdevs will wait for a critical mass of phone users
> > to appear but
> > >> > the
> > >> > phone
> > >> > users will only appear when there is a critical mass of
> > apps.... this
> > >> > problem again.
> > >> >
> > >>
> > >> I'm all in for making porting as efficient as possible. That
> > does not
> > >> imply, though, to give up
> > >> on our principles. In addition, our platform behaves and
> operates
> > >> similar to other major mobile OS's, with the
> > >> notable difference that we are working hard to ensure that
> "good
> > >> practice" is actually adhered to :)
> > >>
> > >> I think we should avoid having battery optimizers and similar
> > system
> > >> maintenance tools in the store.
> > >>
> > >> >>> 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.
> > >> >
> > >> > Even a fitness tracker might give you stats while you are
> > still running,
> > >> > e.g. Endomondo tells you how fast you managed to run the
> > last lap, for
> > >> > that is has to process the data while the screen is off and
> > not just
> > >> > store
> > >> > it.
> > >> > Not sure if the small timeslot for a helper is enough for
> that.
> > >> >
> > >>
> > >> Now that's certainly a solvable problem.
> > >>
> > >> >> 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.
> > >> >
> > >> > I agree that we should not make "our" life easier and aim
> > for a good
> > >> > solution, however we need to be careful to not aim too high
> > for a goal
> > >> > we can not reach in a suitable time.
> > >> >>
> > >> >>
> > >> >> 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.
> > >> >
> > >> > So please correct me if I'm wrong, is the idea here that
> > lets say
> > >> > Facebook
> > >> > provides
> > >> > his own closed telepathy plugin? If that is so, what's the
> > difference
> > >> > from a
> > >> > "normal"
> > >> > background process? If that plugin behaves badly we can not
> > do much
> > >> > about it
> > >> > right?
> > >> > At least not without probably breaking its functionality.
> > >> >
> > >>
> > >> There are multiple benefits to it:
> > >>
> > >> (1.) Tight integration with our platform UI and UX.
> > >> (2.) The ability to tightly control resources granted to the
> > >> respective backend.
> > >> (3.) We will likely setup a more strict review procedure
> > for those
> > >> extensions, together with domain-specific test-suites and
> > potentially
> > >> audits.
> > >>
> > >> In terms of handling extensions that behave poorly: With the
> > context
> > >> of the problem domain (e.g., messaging) handling errors and
> > confining
> > >> operation in general becomes a lot more tractable. The more
> > specific
> > >> the use-case the more specific control mechanisms can be.
> > >>
> > >> > Or is the idea here we will provide something more generic
> > that will use
> > >> > app
> > >> > helpers
> > >> > like we do in other scenarios?
> > >> >>
> > >> >>
> > >> >>> 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.
> > >> >
> > >> > +1, but it would be nice if the user could override that in
> > some way.
> > >> > Right
> > >> > now I'm also
> > >> > able to override powersaving on my laptop if I really want
> > to waste
> > >> > battery
> > >> > life.
> > >> >>
> > >> >>
> > >> >>> 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
> > >> >
> > >> > Just want to point out, I'm aware this is no easy decision
> > and with
> > >> > whatever
> > >> > we decide we have to stay with or break apps later. So
> > there is no
> > >> > temporary
> > >> > solution we
> > >> > can deprecate later without breaking apps, which is IMHO
> > not an option.
> > >> >
> > >>
> > >> +1, whatever we come up with has to be aligned with what we
> > want to
> > >> support in the future.
> > >>
> > >> Cheers,
> > >>
> > >> Thomas
> > >>
> > >> > Cheers,
> > >> >
> > >> > Benjamin
> > >>
> > >> --
> > >> Mailing list: https://launchpad.net/~ubuntu-phone
> > >> Post to : ubuntu-phone@xxxxxxxxxxxxxxxxxxx
> > <mailto: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
> > <mailto: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
> > <mailto: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
>
>
Follow ups
References
