Data Usage of GMS Applications & Services

This is the seventh in a series of blog posts looking at the considerations around adopting a GMS deployment in the enterprise.  Each post features a summary along with recommendations. For other posts in this series please see the links below:

• Preventing unattended application updates initiated via the Play Store
• Understanding Google’s terms of service and privacy policy
• The managed Google Play Store
• Application deltas between Android GMS and AOSP
• GMS Location services and tracking
• Distributing private apps in the Managed Play Store
• Data usage of GMS applications and services
• Factory Reset Protection
• The setup wizard and how to bypass it

A common concern of customers moving from AOSP to GMS is just how much data the new features and applications are going to consume from their data plan.  Whilst customers using devices on a WLAN network are unlikely to give much consideration to their data consumption, those using devices outdoors on a WAN data plan need to ensure they are managing their data usage effectively, particularly when a deployment can consist of hundreds or thousands of devices.

Summary

Unfortunately (and at the risk of sounding facetious), the answer to “how much data are GMS applications and services using in my deployment?” is “how long is a piece of string?”.  Each deployment is just too different and it is not possible to provide a comprehensive answer:

• How much time will the applications be on WLAN vs. WAN?
• Is Data Saver turned on?
• Are the devices managed?
• Are applications on the device using Google Maps?  Chrome?  Gmail? What are the use cases?
  
  • Even within the apps data usage can vary wildly e.g. how many emails are received or web pages visited.
• Is the device configured to share data in line with Google’s privacy policy, as described in the earlier post​ in this series
  
  • If so, what data is being shared?
• Etc. Etc. Etc.

This post will present the results of a fabricated, ‘typical usage’, scenario as well as give you the tools to get realistic data for your own deployment

A ‘Typical Usage’ scenario

As I stated in the introduction, there is no ‘typical’ scenario for our customers: there are so many devices, configurations, applications, use cases and variables that it is not possible to provide general and reliable figures for data usage, but let’s try…

Let us assume the following:

• TC25 device running Nougat and the latest OS at the time of writing (03.11.03, Update 03)
• Data saver is on, the assumption being that the administrator wishes to restrict background data usage.

By default, Play Services (com.google.android.gms) are exempted from this restriction but you can change this in the device settings.  This exemption was left unchanged for this scenario.

• Device is on the Vodafone 4G network in the UK
• Device is a managed Android device, the EMM has allowed access to the following applications:
  
  • Chrome
  • Maps
  • Gmail

• Any 'data sharing' or ‘share usage statistics’ were left on their default values, including for the keyboard and Chrome.
• Device was allowed to perform any requested updates and provisioning whilst on WiFi before the test started.
• WiFi was off for the duration of the test
• Device was allowed to doze but was woken up periodically throughout the test period by manually pressing the power key.

The test was conducted as follows:

• I wanted to mimic a typical transport & logistics (T&L) use case where the device would travel around in a vehicle and be periodically woken up to perform some work (e.g. deliver a package, take a meter reading etc).  In order to achieve this, my wife kindly took the device with her on a recent car journey with her parents to London, occasionally waking the device up.
• Network usage statistics were captured for each application using the test app described later in this post.

  Results of a ‘typical usage’ scenario

Figure 1: Data sent (orange) and received (blue) in KB during the test.

Following the "shift", data was seen to have been exchanged with 3 uids associated with GMS services:

Why the results are filtered by uid is explained later in this post

Start time: 08:11, 6^th Feb 2018

End time: 17:46, 6^th Feb 2018

UID	Associated packages	Data sent (KB)	Data received (KB)	Packets sent	Packets received
10018	com.google.android.gms com.google.android.gsf com.google.android.gsf.login	116	209	664	641
1000	com.symbol.mxmf.csp.wifi com.qti.service.colorservice and 42 others…	37	29	316	197
10069	com.google.android.googlequicksearchbox	12	24	101	85

The device was then left overnight following the "shift", during this time a significant amount of data (23MB) was received by UID 10018 with a corresponding minor increase in the amount of data sent (1MB).

There was nothing on the device to indicate the nature of the data i.e. there was no notification that so-and-so service had received an update.

Remember that by default Play Services (com.google.android.gms) are exempted from the Data Saver setting and this partially explains the spike.

When the test was repeated but Play Services ability to use background data is turned off, no such traffic is seen. 

This setting to turn off Play Services background data usage can be found under Settings --> Data Usage --> Cellular (or Mobile) Data Usage for Nougat but may be elsewhere on other versions of Android.  Depending on your EMM, you may be able to configure this setting remotely.

Conclusions from a “typical usage” scenario

It is very difficult to make any concrete conclusions from such a small data set of a fabricated scenario but the data tends to indicate:

• During the simulated shift the amount of data transferred was negligible in the grand scheme of things in 2018, totalling only 427KB (KiloBytes)
• Overnight, additional usage was observed but it is difficult to draw conclusions from that – devices will typically be off, charging or connected to WiFi back at base overnight.  It is also difficult to say whether this would happen every night and lends weight to the importance of testing in a more realistic scenario for your deployment.
• It is possible to entirely eliminate background data from Google Play Services but this is not the default state out of the box.

Testing usage in your own deployment

Android offers a couple of APIs to measure the network traffic usage for applications on your device, these are:

• The Traffic Stats API added in API level 8 and returns data transferred per application uid since the device was booted.
• The Network Stats Manager added in API 23 (Google recommends using this API for more robust statistics).  Again, the API will return data transferred per application uid but also allows you to specify a start & end time.

I have written an application called ‘Network Stats Logger’ which uses the Network Stats Manager API to allow you to determine each application uid’s data usage over a given period of time:

The application is available on both GitHub and the Google Play Store and is designed to be used as follows:

1. Select ‘Start test’
2. Perform a typical task e.g. undertake a day’s work in your deployment.  The test will continue to run in all circumstances except a factory reset, enterprise reset or uninstalling the app.
3. View the current statistics at any time with one of the ‘Update Stats’ options. Statistics are given for:
   
   1. Total sent and received data as well as the breakdown of how much was over Wifi and how much was over mobile (in that order)
   2. Total sent and received packets, again along with the breakdown over Wifi and mobile.
4. When you want to stop recording, select ‘Stop Test’.
5. Statistics for each application are written to internal storage under the ‘Documents’ folder, retrieve that file by connecting the device to your computer.

Important things to note about the test application

• The application uses the Network Stats Manager API and as such will only run on devices with API 23 (Marshmallow) or higher.  This was done to simplify the testing process.
• Android will store the network statistics in 2 hour ‘buckets’, it is therefore recommended to have your test length exceed one of these buckets to increase accuracy of the results.
• The application requires several permissions including the PACKAGE_USAGE_STATS permission; ensure you allow all permissions on startup
• Each package has an associated kernal user-id (or uid) assigned to it, this uid is used by the Network Stats API to differentiate between packages however it is not unique on the device. What this means is that you may see multiple applications reporting the same Rx/Tx statistics because under the covers because they share the same uid.  To help avoid confusion, the uid for each package is given along with an indication whether it is shared with others on the device.
• Some of the applications reported may seem unfamiliar, the earlier post in this series on GMS applications might help understand some of these.
• There are literally hundreds of applications out there which measure network traffic on your device but I chose to provide my own as many others are non-transparent, do not provide their source code and are likely to bombard the user with ads.

As ever with my test applications, this app does not come with any kind of guarantee or warranty from Zebra

Recommendations

If you are concerned with how much data your device is sending and receiving then there is no better advice than to capture reliable statistics under scenarios that are realistic to your deployment.  Though I would personally recommend making use of the test application provided in this blog post, you are of course free to modify the source or use an entirely separate application but the principle of obtaining realistic data remains the same