← Back to team overview

ubuntu-phone team mailing list archive

Re: Power management policy

 

On 07/19/2013 10:47 AM, Josh Leverette wrote:
"So my specific questions were directed to how we want to manage that - since a hard sigstop when an app switches would be equivalent to a crash to almost every current app in the app store. Obviously, lots of apps will be created *for* touch, but the point all along has been that it should be trivial to migrate existing QT apps back and forth - and overly aggressive killing of apps will hinder that."

What? SIGSTOP pauses it. It doesn't kill it. The app is never made aware of the fact that it was stopped. Once you send SIGCONT to it, it picks up right where it left off.


On Fri, Jul 19, 2013 at 11:58 AM, Mike Bybee <mbybee@xxxxxxxxxxxxxxx <mailto:mbybee@xxxxxxxxxxxxxxx>> wrote:

    On 07/19/2013 09:32 AM, Zisu Andrei wrote:
    "let the user decide" is one of the reasons why foss fails with
    inexperienced users, plus, you really don't want that extra level
    of complexity on a phone.

    The game doesn't really need to run in the background when it is
    not being played. You will just do design your game loop around
    that, but, in a server - client architecture, the update loop is
    on the server most of the time, so... No problem there.

    I guess the only valid argument is the one with the loading
    browsers. Modern browsers don't repaint inactive tabs anyway, but
    javascript still runs and eats cycles you'd really wanna keep. If
    Ubuntu's gonna have something for that, it's gonna be a big plus.

    On Friday, July 19, 2013, Mike Bybee wrote:

        On 07/19/2013 09:04 AM, Thomas Voß wrote:

            On Fri, Jul 19, 2013 at 5:51 PM, Mike Bybee
            <mbybee@xxxxxxxxxxxxxxx> wrote:

                On 07/19/2013 08:45 AM, Josh Leverette wrote:

                The spec looks very promising.


                On Fri, Jul 19, 2013 at 10:06 AM, Thomas Voß
                <thomas.voss@xxxxxxxxxxxxx>
                wrote:

                    Hey there,

                    you might be interested in:

                       *
                    https://blueprints.launchpad.net/ubuntu/+spec/client-1303-add-app-model-and-lifecycle-to-platform-api
                       * and the corresponding spec in:

                    https://docs.google.com/a/canonical.com/document/d/1ij8RtPsR_eYMW3mys8Gu1Y2CVFZpjXdMpdIjIGZ1SCA/edit#

                    In summary: We will implement a very strict
                    lifecycle policy, too, and
                    one that seamlessly adapts and extends to
                    different form-factors.

                    Thanks,

                       Thomas

                    On Fri, Jul 19, 2013 at 4:46 PM, Zisu Andrei
                    <matzipan@xxxxxxxxx> wrote:

                        Hey guys,

                        What I find interesting in the iPad (I just
                        have one because I need it
                        for
                        work) and recently in Mac OS Mavericks is
                        their power managent policy.

                        Put simply, in iOS, except a few very special
                        cases, you applications
                        will
                        be stopped when they go into background. So
                        the foreground app gets full
                        reign of both memory and CPU. This also has a
                        very beneficial effect on
                        battery life - in Android, apps running in
                        the background still eat
                        cputime.

                        What OS X Mavericks is doing is taking this
                        idea further into a
                        noteboook
                        environment [1] with their application nap
                        and timer coalescing. You
                        really
                        only get the most out of your battery.

                        While this might not totally work in an
                        environment like Ubuntu, would
                        it be
                        possible to throttle the foreground
                        application and slow down the
                        background
                        ones?  What would this imply? Is it do-able
                        in the current state of
                        Ubuntu
                        Phone, or do we need extra things at kernel
                        level?

                        [1]
                        http://www.apple.com/osx/preview/advanced-technologies.html



                --
                Sincerely,
                     Josh



                So, using a common example of an IM client or media
                player - would we assume
                that would stay in "unfocused" state? You mention
                that only core apps can
                run as background - that would mean it's not a valid
                state for a normal 3rd
                party app.

            Even core apps will not be allowed to run in background.
            We have an
            exit strategy in terms of the flag described in the
            document, but we
            will most likely not use it. However, we will provide
            services within
            the system (media playback, downloads, alarms) to allow
            apps to
            describe specific background operations. We will extend
            the list of
            supported operations over time.

            HTH,

               Thomas



        I would suggest that we want to fall closer to Android's app
        model than Apple's - or perhaps let the user decide how
        heavily it policies background apps. A mobile can get by with
        very limited background apps - but a tablet will not. My
        android tablet frequently has multiple apps running that I
        switch between regularly, from allowing a slow website to
        load while I'm writing a doc to a game that I pause so I can
        look up a hint.
        Let's not paint ourselves into a corner before we even start.

-- Mailing list: https://launchpad.net/~ubuntu-phone
        <https://launchpad.net/%7Eubuntu-phone>
        Post to     : ubuntu-phone@xxxxxxxxxxxxxxxxxxx
        Unsubscribe : https://launchpad.net/~ubuntu-phone
        <https://launchpad.net/%7Eubuntu-phone>
        More help   : https://help.launchpad.net/ListHelp



-- Zisu Andrei

    By "let the user decide" I don't mean we should confront people
    with it - I just mean it should be available for adjusting, much
    like swapiness is. Most people will never touch it, but it is nice
    to have.
    I think we really need to just go for the policy of "least
    surprise", right? If you want to swap between apps, they need to
    be able to behave as you'd expect them to. Especially with a tablet.

    I mean, what if you want to copy/paste something between your
    password keeper and an app - you wouldn't want either one to
    "crash" or "vanish", nor the clipboard to vanish.

    So my specific questions were directed to how we want to manage
    that - since a hard sigstop when an app switches would be
    equivalent to a crash to almost every current app in the app
    store. Obviously, lots of apps will be created *for* touch, but
    the point all along has been that it should be trivial to migrate
    existing QT apps back and forth - and overly aggressive killing of
    apps will hinder that.

    --
    Mailing list: https://launchpad.net/~ubuntu-phone
    <https://launchpad.net/%7Eubuntu-phone>
    Post to     : ubuntu-phone@xxxxxxxxxxxxxxxxxxx
    <mailto:ubuntu-phone@xxxxxxxxxxxxxxxxxxx>
    Unsubscribe : https://launchpad.net/~ubuntu-phone
    <https://launchpad.net/%7Eubuntu-phone>
    More help   : https://help.launchpad.net/ListHelp




--
Sincerely,
    Josh

"What? SIGSTOP pauses it. It doesn't kill it. The app is never made aware of the fact that it was stopped. Once you send SIGCONT to it, it picks up right where it left off."

Ok, so that would work great then, thanks for the clarification. My biggest concern was just as a user (with my usage patterns), and as a dev, writing apps that will definitely run in the "background" on occasion.

Follow ups

References