ubuntu-phone team mailing list archive

[Chris Wayne <chris.wayne@xxxxxxxxxxxxx>]

On Fri, Oct 2, 2015 at 4:53 AM, Andrea Bernabei <
andrea.bernabei@xxxxxxxxxxxxx> wrote:

>
>
> On Fri, Oct 2, 2015 at 9:18 AM, Thomas Voß <thomas.voss@xxxxxxxxxxxxx>
> wrote:
>
>> On Fri, Oct 2, 2015 at 10:04 AM, Craig Harper <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...



>
>
>> > 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>
>> > wrote:
>> >>
>> >> On Fri, Oct 2, 2015 at 9:20 AM, Benjamin Zeller
>> >> <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>
>> >> >> 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
>> >> 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
>
>