ubuntu-phone team mailing list archive
-
ubuntu-phone team
-
Mailing list archive
-
Message #15984
Re: The problem with "no background processing for apps"
My friends built this for iOS/Android https://www.moves-app.com/
And most of its success has been due to the fact that you just leave it
running in the background all the time. It works out whether you are
walking/running/cycling/driving from the motion sensor/gps data
algorithmically. There is some battery impact but small enough that people
keep using it (if they are the kind of people who like using sports
trackers in the first place)
I don't know what the ideal solution for us would be but perhaps we should
be realistic and consider at what gets us there quickest in a manner that
is both user and battery friendly.
On Fri, Oct 2, 2015 at 3:34 PM, Chris Wayne <chris.wayne@xxxxxxxxxxxxx>
wrote:
> 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
>>
>>
>
> --
> 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
>
>
References
-
The problem with "no background processing for apps"
From: Sturm Flut, 2015-10-01
-
Re: The problem with "no background processing for apps"
From: Thomas Voß, 2015-10-01
-
Re: The problem with "no background processing for apps"
From: Benjamin Zeller, 2015-10-02
-
Re: The problem with "no background processing for apps"
From: Thomas Voß, 2015-10-02
-
Re: The problem with "no background processing for apps"
From: Craig Harper, 2015-10-02
-
Re: The problem with "no background processing for apps"
From: Thomas Voß, 2015-10-02
-
Re: The problem with "no background processing for apps"
From: Andrea Bernabei, 2015-10-02
-
Re: The problem with "no background processing for apps"
From: Chris Wayne, 2015-10-02
-
Re: The problem with "no background processing for apps"
From: Michael Zanetti, 2015-10-02
-
Re: The problem with "no background processing for apps"
From: Chris Wayne, 2015-10-02
