Duration 25:44
16+
Play
Video

Don't let your app drain your users' battery

Madan Ankapura
Product Manager at Google
+ 2 speakers
  • Video
  • Table of contents
  • Video
2018 Google I/O
May 10, 2018, Mountain View, USA
2018 Google I/O
Video
Don't let your app drain your users' battery
Available
In cart
Free
Free
Free
Free
Free
Free
Add to favorites
8.78 K
I like 0
I dislike 0
Available
In cart
Free
Free
Free
Free
Free
Free
  • Description
  • Transcript
  • Discussion

About speakers

Madan Ankapura
Product Manager at Google
Benjamin Poiesz
Software Engineer at Google
James Smith
Software Engineer at Google

About the talk

This session will cover the steps to ensure users have a good battery experience. It will review the latest changes your app should make to optimize power, while enabling the use cases you care about.

Share

Afternoon morning lunch dish welcome everybody. Thank you for coming to talk about battery. So it's another year and I'm here again to talk to you about about power. It's an ongoing ongoing projects. And as you probably saw from the keynote Dave talked about not suppose or his own version of the pyramid and I think it's actually a lot is is in this image battery is is foundational to everything you're doing on your phone. Right? If you don't have power you don't really have any other cool features. You want the camera. I don't be stiff then battery exist to power all

the other things and it's a struggle for us and it's a struggle of I think for all of you as well as you want to do awesome things for users and you also want to save power so they can do those things for longer and batteries actually really easy problem to solve you. Just take just kill everything. Fixed I'll take my promotion. It's always great. The problem is it's obviously much more nuanced than that. And that is a struggle that we have internally everyday talking about power and what are the right trade-offs for users and that's always a really hard question and we're going to

talk a little bit about that and some other things that were building into Android P to to make it a lot easier. It's the first thing I want to talk about is where it where is it? Where is it going in? This is like a horrific Lee simplified. I'm sure some the engineers that they're like, oh my God, he's showing this but you have Hardware things even like how much RAM you have in your device. I'm cause a persistent drain on what's happening there. So what Hardware is the OEM is selected what Hardware you're using? How big your screen is how bright your screen is all play into that that affect

you have the OS itself is the colonel being really efficient is a waking up alot. Is it doing a lot of overhead? Do you have disk encryption? Is that disk encryption and software or Hardware those thing? To all effect on your overall power profile to happening under the hood. The next thing is absent services and this is where we're going to spend a bit of time talking today obviously would ask you have on your phone in the service is running on that phone tripower substantially larger than a CPU in through network connectivity. And then the last one is the user's interaction with

the device itself how they behave what applications they use how quickly they respond the notifications or don't all impact the overall picture of where battery ends up really complicated topic. We're going to talk about the bottom corner today, but I think I'm going to just give us before we get into that is what it what other things have we done and how does the stuff we're going to talk about in pee affect the overall strategy with lollipop with a job scheduler and drops. It was a very powerful tool to avoid apps of having to hang out in service is all the time

processing in the background, but you could schedule a piece of work and have that piece of work done in a finite amount of time and the OS I have some variability on when the schedule it. Next windows and doors was largely targeted at cases where you have your tablet or phone you put it down. You're not using it you put in a drawer and you forget about it. And hopefully when you pull it back out and use it again a few days later, it still has battery and those are really trying to at the Target that problem then was largely successful at dealing with that. We didn't we had to go further

though. And that was with those on-the-go ordos white as we call it internally ketosis faster is that was targeted at phones and like I have my phone hanging out in my pocket. I'm not using it right now, but I'm moving around so I'm not in the drawer that is then the next by step of how do we get that to be a good scenario and goes in the goal is trying to look at that scenario of your phone screen is off your maybe moving around so you're probably not wanting all your apps to be quiet all those but you still need there be a little bit backed off normal scenarios. The screen is on. We

still need to do more and go deeper. The next thing was looking at background limits and just as long as you talk it at background services at the hole now. We had jobs around for quite a while. We also were looking at background limits for location and trying to figure out what the right balance of applications looking at location in the background versus the fairgrounds. And should there be different thresholds of what is appropriate really good fact that the only downside if you weld what we did with Oreo was we need to add apps to Target the Oreo SDK and I'll talk about that support

this and then obviously since we're here we're going to talk about some more stuff. The one thing I wanted to take a moment because we're mostly cuz I got to make really cool and I'll and other exciting things is there was a lot of just Brute Force optimization that the engineering team has also done. This was looking at a few a fast file system work this was looking at how do we choose between whether our process should be on a small core or big core looking at when we should do CPU boost so that you have nice buttery smooth sliding, but you're not just burning car. When the screen is on

in anticipation that the user might interact with the screen and these are all a bunch of things that been done over the years. This is a sad that we just did on auntie and the spice two more that were trying to get done. And then that's the thing is that there's still some some of those big big challenges out of remaining and this is what we're talking about today is what we noticed was battery drain was roughly proportional to number of as you had on the phone. Not the number that you were using but how many you had installed and I obviously that's not ideal. Its we want to try to remedy

that we also saw a lot of scenarios where apps are accidentally making mistakes. Like if you're working with wakelocks your kind of playing with fire and what happens when a mistake happens and usually the battery would suffer also some developers to be really aggressive with their use case. I'm trying to be like I must be there all the time ready to go at a moment's notice and sometimes that might take off on a battery to achieve that and is that really in the interest of the user and how can we help help balance that back out to the last part is even when an app was aggressive or not had

a mistake. It wasn't obvious to the user as to what to do. I didn't know the battery when you going to help me. To tell me everything that they catch all the cases some of the cases none of the cases and even when you saw High battery value. Now what do I uninstall do I live with it? Do I call the developer and send a message to Graham? And so that's something else you want me to look into and the very last one I mentioned before is the Oreo SDK having apps haragan at STK to say I understand. How is back on this work. I understand how I can use jobs and use alarms that have using

services that you probably saw there was a now it's been late last year talking about targeting requirements for applications on the Play Store. You haven't seen that please go Google it and find out about it. You should be looking at it because those requirements are kicking in later this year and that's going to ensure that done on the majority apps on your phone or not running the Oreo STK and all these features was talking about work. So that I don't think we're talking about here is a battery which I think the two different socks already

and then also additional restrictions on background processing that we've been been looking at in this is also how to help users understand. When can I make it stop can I have another Choice other than uninstall something in the middle between live with it and remove it and that's like this the kind of pyramids trying to articulate here is we all want a good Tower efficiency. I would like batteries that last a long time we weren't really cool apps and we don't even have to manage between these things. Like do I want to do it with her efficiency? No one wants to have to be forced to make a

choice. It's difficult. I don't want to make it no one wants to make it we going to just to work and that's what this whole project has been all about without an invite to James up here to talk about. The battery next. I got to kiss. Hi everyone. Good morning. I'm James. I'm representing the deepmind team today just to say they were really pleased to be here and working with Android and excited about what side we built together. So I say user you shouldn't have to

closely manage. How are your apps behave on your device a modem intelligent operating system. She just take care of it. And that's where machine learning can help. We could develop to this feature with Android called adaptive battery it intelligently a lions app power consumption with app usage. Apps can still run in the background when they need to and users don't need to micromanage. So it's active battery uses the concept of standby buckets. Every app on the device is assigned to one of these buckets.

Each packet has different limits on background activity and there are four buckets ranging from active to rare. Hops in the rear bucket will have the most restrictions. And we use the ml model to assign apps to buckets based on their predicted usage. So for example apps that are predicted to be open in the next few hours. I'm here at Iowa. So I might be using the Iowa City Iowa is going to be in the active bucket, but in a few days time when I'm back at home adaptive battery is going to automatically determine that I'm unlikely to be using

this app and put it into the rear bucket. So it's not unnecessarily consuming resources like that to me. So what are the restrictions that are flights? Jobs alarms Firebase Cloud messaging on network are all restricted in Android P depending on which bucket the app is in. Apps in the active bucket have no restrictions just like it is today. Working set has some restrictions on jobs and alarms and frequent and rear buckets introduced restrictions on the number of

high-priority Firebase Cloud messages messages be on the cap will be treated as normal priority so that we batch together with other messages to save battery. Generally as developers you should assume the background activity will be the first and ensure that your aunt can work under those conditions. But one thing to remember is that once you this device is plugged into Power all of the restrictions are lifted. There are ADB Commands that you can use to test your app in each bucket to make sure that it performs as expected. You can also use

new framework apis to get your aunt's current bucket at runtime. Most apps should be fine. If they're already following best practices such as using jobs for background work and targeting recent API levels, like Android Oreo has been just said this is going to be a requirement for app updates on the Play store later this year. So, please make sure you're targeting the latest SDK versions. So let's talk a little bit about machine learning. The Mortal was built by Android and deepmind to predict which apps go into which bucket.

We could have done this with simple heuristics or we could have even just use past behavior on the device. But we find that machine learning allows us to capture the Nuance of how users behave with their apps and I'll go into some detail on how we built the immortal in a second. For those of you who are interested in the architecture of the Moto were using it to layer deep convolutional neural net with a feed-forward neural net on top and use used to predict the probability that an app will be opened in a given interval. You might have heard of convolutional neural

Nets before tickly. They're quite common in image classifiers, but we've used them here to measure higher levels higher level patterns of app usage over time. All of this is happening on device using tensorflow. And that's actually a first for deep might we've never deployed a production models on the computer of a single device on a single mobile device with their limited compute power that's available isn't particular set of challenges out. Of course, we're building this machine learning model with the intention of attempting

to save power and if we're doing machine learning on device, we have to be careful that we're not spending more time than we are saving. Going to be making this model available to all device manufacturers so they can take it if they wish for their devices on Android P or they can Implement their own or they can take an Android open source version of it as well. So the model we train the model on millions of sequences of opens and transitions to discover the patterns of how users behave so an example would

be if you use a nap at 8 in the morning every morning. You're probably quite likely to open it tomorrow at 8 as well. But if you only use a certain app on weekends like a game or a travel app, then you're probably not going to open it on Monday morning and the motor was able to capture this New York's. The model looks at user's behavior and roots of probability of when your next going to open a particular app. Immortal compares the usage to the patents we've observed in the data and the behavior on device will influence the prediction is given by the modem.

So we've also built this model with satin principles and Minds with trying to make it fair. There is no favoritism of one app over another if you use one particular in exactly the same way that I use a different app than the motor will fit the same predictions and they will be assigned to the same buckets. It's privacy sensitive. There's no personally identifiable information used by the Moto both when it strains and when it runs on the device the Moto only compare the app usage on device to arnone sequences of millions of app Transitions

and it predicts when your next going to use that up. So if you combine the apps on by buckets and their restrictions with this model that predicts when your next going to open the apps, that's the adapter battery feature is a system that if that's the phone to you is used to personalize the OSS Behavior to adopt it's how you use the phone. So the apps that you use get to run in the background on the app, so you don't don't we hope this will create a more consistent battle experience for users. I'm not going to

pass over to Madonna is a product manager on Android to talk about the battery saver features. Thanks very much. Thank you James. Let's talk about battery saver. How many offers actually ran through the day and asked me into work today? We realized that oh, I won't be able to actually make it and Battery Saver is there to actually save you remember those red bars when are animations that word janky in oreo who like those so we got rid of them? Beyonce actually turn off location that helps battery features, like

ambient display as an example are also turned off all of these add up in order to save battery and prolong the device battery so that you can go back and charge the device. We have also made some changes in the UI so that you can live on this more for longer. Now. You have a slider that you can actually increase all the way to the right which probably allows you to stay on this more if you choose to But what's also interesting is what we found is if an app is being used by the user in this more. Having a dark theme

really helps our internal test show that apps using Dark theme save power compared with the ones that don't are developers that already supports Dark theme. Please do think about switching to Dark theme when you detect that the device is in battery saver. There are few commands that you can use. 280 be to force the force that divides into battery saver and test them. and for those of you who already support. More there are API like if power save mode and

broadcast that you can use to switch your device your app team, too dark. Let's jump into the battery settings itself actually. Goes into a battery settings probably they are having a bad battery day. You want to make the user they easy to take actions? You want to keep the UI simplify? And we will tell you exactly what applications might be causing their battery drain. I mean, I just sent it. I just called down love to be able to see how long your battery will last and that number is also powered by animal Margaret.

Let's jump into that opinionated background restrictions. So we have some principles upon which we have built this particular feature. User asked for control they want to know like which app is doing water so that they can take a quick action on them. We also want to make sure that apps that don't necessarily Target Oreo are also be well managed by the user. And lastly our goal is to make sure that I have don't get restricted in the first place. So that way I have fundamentally are better battery citizens.

So with P we will actually launch the feature with two specific criteria. The first one is still not targeting and has a background service. The second one is if an object holds wakelocks or what we call a stack weight loss for more than an hour in the background. Both of these are very well understood causes for battery drain. There are more such reasons. Which represents those reasons within console and we call them Android waiters. So we are in the future going to be looking

at many set signals in order to incorporate into coming up with new rules for background restrictions. So what does it mean for your app in case if the user decides to restrict them? Has James talked about Job salon services and network. The apps will not be able to do any of those in the background. There are some explicit sentence for example location will not be trying to minimize the reasons why a nap should be able to use device resources when it is in the background. And lastly even Arby's in the background and restricted it won't

be able to use for ground services. So as I spoke earlier, I hope many of you are already familiar with Android White House. If not, I would strongly recommend you to go take a look into what signals do we actually show in there today and how your app is behaving? We have heard many success stories off application developers using this data in order to improve their applications. And in fact use some of these signals internally also to make OS better. Trying to figure out like what kind of changes we could be

making in order to have the right guard rails within the Warriors to make sure that happens early don't accidentally drain battery. There was a session about it. If you haven't had a chance to listen to those, please take a look at that according. So Remain the UI simplify, but they might be several of you. Who would fall into as power users so you do like grass and you do like number of percentages? So we do have it in the world flow menu. Now they got these improved

why are better predictions and the user can take action from this screen if you see any app that is not necessary that surprises you as being consume more battery. The from here you can directly preemptively restrict applications or unrestricted. This is a good user control for users to have So, how do you test for this again? There is a TV commands that you can use to put your app. Do a restricted state are under strict them and test them while they are in the note that even an app that has been restricted would still be used by the use by launching them explicitly.

You want to make sure that they still work. So we have gone through some of the key features and T. And what does it mean for you as an app developer to continue to actually deliver. You are a feature using various Ford on the way. It's our first Lake jobs alarms and so on so far. What does it mean for you to do a background work? You might have actually seen this flowchart before been presented last year. It literally went through. What is it that you want to do and offered some choices. We want to simplify our

recommendation and thanks to Jack Park in it. We have a great tool. Search extremely simplified now, hopefully so if you want to think about doing anything in the background, we highly recommend you to actually value at work manager as a go-to thing. And if you think it is something that is really important and must happen. Now, of course, you have the ability to use for ground services, but you have to tell the user while you are using it far because there will be a notification and you'll have to justify yourself

as to why you think it is important. I know because of that if you change your mind go back to work manager. So if none of this work think about actually doing the work when the app actually is launched and being actively used by the user. So the choices are hopefully very simplified. All of this really help us manage battery better and that will lead to having a better battery life. There have been some sessions that have already happened. So I want to call shout out to Jetpack with stocks about what manager there was. Also a

session on Android vitals and there is a dirt bike video documentation of the features that we talked about. Please head over to D. Android.com power. And thank you.

Cackle comments for the website

Buy this talk

Access to the talk “Don't let your app drain your users' battery”
Available
In cart
Free
Free
Free
Free
Free
Free

Access to all the recordings of the event

Get access to all videos “2018 Google I/O”
Available
In cart
Free
Free
Free
Free
Free
Free
Ticket

Interested in topic “Software development”?

You might be interested in videos from this event

September 28, 2018
Moscow
16
159
app store, apps, development, google play, mobile, soft

Similar talks

Fred Chung
Developer Platform Manager at Google
+ 2 speakers
Dan Galpin
Team Lead at Google
+ 2 speakers
Eric Kuxhausen
Software Engineer at Google
+ 2 speakers
Available
In cart
Free
Free
Free
Free
Free
Free
Vince Wu
Product Manager at Google
Available
In cart
Free
Free
Free
Free
Free
Free
Krishna Kumar
Product Manager at Google
+ 1 speaker
Mariya Nagorna
Senior Technical Program Manager at Google
+ 1 speaker
Available
In cart
Free
Free
Free
Free
Free
Free

Buy this video

Video

Access to the talk “Don't let your app drain your users' battery”
Available
In cart
Free
Free
Free
Free
Free
Free

Conference Cast

With ConferenceCast.tv, you get access to our library of the world's best conference talks.

Conference Cast
558 conferences
22059 speakers
8190 hours of content