FRED CHUNG: Long lasting battery is the most important factor
for Android users.
And by extension, developers should care about it too.
While we want to achieve reliable battery
life for Android, apps should have some flexibility
to run in the background.
The platform needs to provide consistent restrictions
as guardrails to prevent a few misbehaving
apps from draining the battery.
This is important, such that you can design your apps to run
consistently across devices.
At the same time, users should have some control
and visibility to app battery usage.
How does Android balance these considerations?
From Android Lollipop to P, the platform
has introduced a series of features
that aim to offer power management based
on three main dimensions.
Firstly, device idle state, or how long
the device has been unplugged and with the screen off.
The device could enter doze, where all apps cannot acquire
wake locks.
No job services and sync adapters can be run.
You are likely familiar with this already.
The second one is based on giving users
control and visibility.
There are a couple of relevant features.
In Android P, battery saver has been
enhanced for users who want to have extended battery
life over everything else, possibly
at the expense of some feature degradation,
such as restricted location services during screen off.
Users can turn this on any time, or set
it to turn on automatically when the device drops
below a certain threshold.
So developers should account for these restrictions
and test against them.
There are times when apps might be too aggressive in acquiring
wake locks, or, in general, doing
things that are considered bad for battery drain.
New in P there is the background restrictions feature.
Based on Android Vitals, The device
monitors and detects apps that demonstrate
known bad behaviors, and flags to the users
who can then choose to restrict these apps from running
jobs, alarms, background services, and so on.
Most users only use a small number of installed apps
regularly.
When you think about it, the total number
of installed apps on a device really
should have no correlation to battery life.
The third dimension aims to tackle this issue
based on app usage patterns.
In Android P, the system can, in a fine grained way,
apply restrictions to apps that haven't been used recently.
Apps are classified into five buckets,
ranging from active to never.
We call them app standby buckets.
Apps that haven't been actively used for a certain time
would be put into an appropriate lower bucket.
Accordingly, the system would progressively
differ app tasks, such as alarms, jobs,
and network access.
Further, the system uses machine learning techniques
from DeepMind to intelligently move apps between buckets
in order to achieve the highest efficiency.
And it gets better over time.
Device manufacturers can adopt this ML model,
implement their own, or use the AOSP algorithm.
Various battery management features
boil down to restrictions and deferred access
to some combination of background tasks.
For developers, therefore, it's important to test
against these restricted scenarios.
Let's go over some design and testing best practices.
Ensure proper testing over a range
of increasing restrictions.
ADB commands are available to simulate the conditions.
You can simulate doze using these commands.
You can also exit these states through similar commands,
available in the developer docs.
How do you test against app standby buckets?
Since it's based on user behaviors, which can vary,
expect your apps to be moved between buckets.
Always assume that your jobs and alarms
will be deferred, and ensure that your design can
work under those restrictions.
The good thing is that most apps will be fine
if they are already following best
practices, such as using jobs, or targeting at least API level
26.
Also note that in the frequent and rare app
standby buckets, high priority Firebase Cloud messages are
kept, and any messages beyond the threshold
will be treated as normal priority, which
could be delayed when the device enters doze.
Again, test against these conditions thoroughly.
You can use a couple of ADB commands
to set and retrieve buckets for your package.
Before running them, make sure your device is unplugged.
There are also framework APIs to get an app's current bucket.
Or you can use usage stats manager
to query the list of events associated with your app, which
includes bucket changes.
Want to test under battery saver conditions?
Yep.
There are ADB commands for that.
If your app uses location, for example,
you can use this method to verify
how your app behaves when it uses location
services during screen off.
When battery saver is turned on, you
can further save battery by entering your UI's dark theme
if available.
You can either check for this mode
explicitly, or respond to a broadcast.
In the event you need to refactor existing background
surfaces, in most cases the new WorkManager API can be
used to fulfill many use cases.
Use only foreground services for user triggered actions
and that users expect them to run immediately,
such as music playback.
By the way, it's good practice to also include
a stop [INAUDIBLE] instant notification.
We have talked about some design and testing best practices.
During development and post-launch
there's a couple of related tools.
The energy profiler is a new feature
available in Android Studio 3.2, currently
on the Canary channel.
After you deploy your app to a connected device,
the profiler shows a live timeline
of how your app uses system resources,
such as partial wake locks, wake up, alarms, jobs,
and location requests.
The profiler also estimates your app's energy usage
of CPU, network, and location resources.
Refer to energy profiler documentation for more details.
In the Play Developer Console, Android Vitals
exposes performance metrics that are tightly
associated with battery usage, which includes excessive wake
ups, stuck wake locks, and background network access.
Refer to Vitals documentation for more detail.
With standard ways to manage power intensive tasks,
and with proper testing, developers
can create apps that work consistently across devices,
and collectively can achieve good battery life for users.
To learn more about these features and tools,
check out the links below.
Thanks for watching.
[MUSIC PLAYING]