ubuntu-phone team mailing list archive

[Thomas Voß <thomas.voss@xxxxxxxxxxxxx>]

On Thu, Jun 26, 2014 at 4:49 PM, Rodney Dawes
<rodney.dawes@xxxxxxxxxxxxx> wrote:
> On Thu, 2014-06-26 at 16:09 +0200, Thomas Voß wrote:
>> I assumed that you know:
>>
>> https://docs.google.com/a/canonical.com/document/d/1ij8RtPsR_eYMW3mys8Gu1Y2CVFZpjXdMpdIjIGZ1SCA/edit#heading=h.28drra4u9knx
>>
>> given that the document has been around for quite some time now, and
>> has been referenced multiple times in other mail threads on this list.
>> It might not contain all of the details you are after, but it gives a
>> very good overview of the design that we implemented. There are also
>> multiple UOS sessions available from youtube. Anyway: I'm happy to
>> iterate on the document and adjust it if concrete points are missing.
>
> No, I didn't know about this doc. However, it doesn't actually describe
> anything about what system services will exist or how they will
> function. The only information about background tasks in that doc is a
> very short list of a few very specific use cases that might need
> background processing.
>
>> See my comment before. Also: We already put a bunch of background
>> services in place, an updated version of the location service is about
>> to land. Push notifications are well on their way, too. With that, and
>> given the numerous updates by individual teams being reported to the
>> mailing list, I wonder what else would help in terms of documentation?
>> I agree that it would be great to have complete SDK and API docs
>> available and any help is appreciated to reach that point. And feel
>> free to reach out to me on irc.
>
> Where are these services and how apps are expected to use them,
> documented? I don't need complete SDK/API docs at this point, but a
> general overview of how we expect this to look and function on a
> technical level would be nice to see.
>

Applications are expected to use them via our usual SDK. They are
transparent to the app developer in the general case. For example, we
provide a backend for QtMultimedia/QtLocation etc. that ties into
these services.

>> Sorry, but I think you are ignoring the arguments that multiple people
>> have presented in this mail thread. We have pointed out that we are
>> well aware that we are taking a somewhat conservative and strict
>> choice to ensure predictable battery life and performance. None of the
>> alternative approaches presented in this thread qualify for
>> predictable battery life and performance, they all focus on solving
>> the perceived issue of a lack of flexibility for application
>> developers.
>
> I am not ignoring any arguments. But "predictable battery life" is not
> an argument. Battery life is  unpredictable. There are way too many
> variables to predict battery life. Battery life can only be predicted in
> a controlled environment. Long running tests of minimal usage and very
> heavy usage, combined to find the average, will give you an average
> expected battery life on a particular piece of hardware, which is used
> for marketing and declared an estimate in those materials. Beyond that,
> you will have no idea what sort of battery life I will get on my phone.

Well, but I think that we can all agree on the point that if we fix
all those variables you are talking about, you would expect
predictable battery life, right? The argument then becomes: We can do
a better job of delivering predictable and good battery life no matter
what set of applications is installed if we do not allow arbitrary
app-specific code to be run in the background.

> There are way too many variables for you to make any reasonable guess.
> Where I live on the planet, how many calls I make, how I travel, how I
> carry my phone, what accessories I connect to my phone, what apps I use,
> how often I use them, etc… all have an impact on what the battery life
> of my phone will be. Yes, if I have 30 apps running in the background
> all actively doing things, it's going to be bad. But it's also going to
> be bad if I spend 4 hours straight actively playing one game.

Well, a user expects the battery to be used when actively using the
phone. In contrast, if a user is not actively using the phone, I would
think that we can safely "assume" that the user expects as little
battery to be used as possible.

> Arguing
> about battery life isn't something that will provide a solution to any
> actual problem.
>

Interesting, seems to be a recurring topic in the industry and for
people trying to build mobile operating systems, though :)

Cheers,

  Thomas