Mobile data use is costly and even more so where data plan costs are not affordable by all. Android users need the ability to reduce data use or block it from apps altogether. The Data Saver feature in the Android 7.0 release provides this functionality to the user.
The Data Saver feature can be turned on or off by the user. App developers should use a new API to check if Data Saver mode is on. If it is on, the app developers can handle the situation gracefully by tuning their applications for low- or no-data access.
End users benefit as they will be able to control which apps can access data in the background and which can access data only while in the foreground. This ensures desired background data exchange when Data Saver is on per user control.
Since the Data Saver is a feature in the platform, device manufacturers gain its functionality by default with the N release. Find the source files in: packages/apps/Settings/src/com/android/settings/datausage
A default Data Saver settings user interface is supplied in the Android Open Source Project (AOSP). See the screenshots below for examples.
These screenshots show the Data Saver mode in use.
Important: Device implementers should not whitelist apps. Even if they do, users may remove them. Including other apps forces users to decide on which to apply Data Saver.
All app developers must act to implement Data Saver, including OEMs and carriers with preloaded apps. See Data Saver on developer.android.com for app developer instructions on detecting and monitoring Data Saver states. See the sections below for additional details helpful to partners.
To optimize for Data Saver mode, apps should:
- Remove unnecessary images
- Use lower resolution for remaining images
- Use lower bitrate video
- Trigger existing “lite” experiences
- Compress data
- Respect metered vs. unmetered network status even when Data Saver is off
Conversely, to work well with Data Saver, apps should not:
- Autoplay videos
- Prefetch content/attachments
- Download updates / code
- Ask to be whitelisted unless background data is truly part of core functionality
- Treat whitelisting as a license to use more bandwidth
Implementers can ensure their version of the feature works as intended by running the following CTS test:
adb commands can be used to conduct tests manually by
first running this command to see all available options:
adb shell cmd netpolicy
For example, this command returns the UIDs of the whitelisted apps:
adb shell cmd netpolicy list restrict-background-whitelist