SoylentNews

"exec" writes:

Story automatically generated by StoryBot Version 0.2.2 rel Testing.
Storybot ('Arthur T Knackerbracket') has been converted to Python3

Note: This is the complete story and will need further editing. It may also be covered
by Copyright and thus should be acknowledged and quoted rather than printed in its entirety.

FeedSource: [ArsTechnica]

Time: 2018-08-01 12:18:14 UTC

Original URL: https://arstechnica.com/gadgets/2018/08/p-is-for-power-how-google-tests-tracks-and-improves-android-battery-life/ [arstechnica.com] using UTF-8 encoding.

Title: “P is for Power”—Android engineers talk battery life improvements in Android P

--- --- --- --- --- --- --- Entire Story Below --- --- --- --- --- --- ---

“P is for Power”—Android engineers talk battery life improvements in Android P

Arthur T Knackerbracket has found the following story [arstechnica.com]:

With the last version of the Android P Developer Preview released, we're quickly heading toward the final build of another major Android version. And for Android P—aka version 9.0—battery life is a major focus. The Adaptive Battery feature will dole out background access to only the apps you use, a new auto brightness scheme has been devised, and the Android team has made changes to how background work runs on the CPU. All together, battery life should be batter (err, better) than ever.

To get a bit more detail about how all this works, we sat down with a pair of Android engineers: Benjamin Poiesz, group product manager for the Android Framework, and Tim Murray, a senior staff software engineer for Android. And over the course of our second fireside Android chat [arstechnica.com], we learned a bit more about Android P overall and some specific things about how Google goes about diagnosing and tracking battery life across the range of the OS' install base.

What follows is a transcript with some of the interview lightly edited for clarity. We also included some topical background comments in italics.

So, we started enforcing affinity controls using the knowledge in activity manager service. We started off really simple, so background services and cached apps could only run on little cores. Foreground services could use some big cores, but not all of them, and the app you're currently interacting with can use any core. When we tried this, it kind of blew us away. It was a double-digit percentage increase in performance per watt on every test we tried. So, basically, informing the kernel scheduler, kind of constraining the kernel scheduler about what's important to the user, enables it to make much better decisions that result in much better power and performance trade-offs.

So, we've been doing that for a long time now, and even on Pixel 1, which is still a big.LITTLE CPU, but it's much less big.LITTLE than other CPUs. It's still of benefit there, so we've used it on everything.

What we did in P was we looked at what was running when the screen was off on the big cores because big cores draw significantly more power than little cores. What we found was there were a lot of things running that were related to the system. So, they were kind of system services that were running. We looked at how many of these were performance critical and it turns out, not many—when the screen is off at least. If they are performance critical when the screen is off, it ends up being bound as a normal foreground service or something else. There's some other chain that informs activity manager that this process is important.

In P, what we did was, when you turn the screen off, these kinds of system services get moved to a more restricted CPU stack. So, rather than being able to use all of the little cores and some big cores, we just restrict them to only using little cores, and it saves some battery. It makes your battery more predictable because if there is ever a case where a system service is going to use some amount of power when the screen is off, now that power draw is reduced dramatically, just because the big cores are so much bigger than the little cores and draw so much more power as a result.

The takeaway was: when the screen's off, there's probably not much that needs to happen right away. You could infer, like, "Well, maybe there just isn't that much work being generated, so then CPUs will stay low." But sometimes for different reasons, the subsystems, it'll set up alarms, set up jobs, try to do processing. And there wasn't really a way to articulate, "I have a bunch of stuff to do, but do it whenever." This gives us a better way to do that that's much more implicit, as opposed to asking all of our engineers, "Please flag what's important or not." That's gonna be hard. This makes it much more implicit.

-- submitted from IRC

Original Submission