Sean Barbeau

Apr 5, 2021

11 min read

Crowdsourcing GNSS features of Android devices

As the developer of the open-source GPSTest Android app, the most common question I get from users is “can a device do X”? It’s understandable — with device costs often being $500–1000 USD (or more), users want to know what they are getting for their money.

Unfortunately, this isn’t an easy question to answer for many reasons, which I’ll get into shortly. The lack of industry transparency for mobile device Global Navigation Satellite Systems (GNSS) features has become painfully obvious over the last few years when looking at dual-frequency GNSS. I wrote this article in April 2018 looking at the availability of GPS and Galileo L5 and E5a signals on Android devices. I thought it would be a short write-up about the first OEM to get a dual-frequency device to market, and after that most devices would follow with similar specs. However, I’m still updating that article almost three years later as users test new devices and share screenshots of GPSTest, with a lot of unexpected results.

So let’s step back and look at why device GNSS features are so hard to find.

Can’t I just look at the specs?

Location (GPS, Galileo, Glonass, BeiDou)

*Galileo and BeiDou coverage may be limited. BeiDou may not be available for certain countries.

Let’s say we want to figure out if the S21 supports L5 and E5a signals. The above specs don’t help. Maybe we can just look up the specs on the S21 chipset? Well…

Model variants have different chipsets

Let’s say with some Internet sleuthing we can figure out which chipset a device uses based on the exact device model number (e.g., SM-G955U) and we find detailed GNSS specs on the chipset, as we did with the S21 and the Snapdragon 888 above. Done, right? Well…

OEMs sometimes add GNSS receiver hardware

So let’s say you figure out the chipset and find a teardown video for your exact model variant that confirms whether or not the device includes additional receiver hardware. Are we done now? Well…

Devices have other limitations

Ok — this is getting crazy — anything else we need to worry about?

Regional limitations

Hold on, though…if OEMs could update some devices to support Galileo in the U.S., that means…

Software changes matter

GNSS aficionado trying to figure out what features an Android device supports

So…it’s complicated.

Because of the above issues, the best way to verify a device’s GNSS features is to run an app like GPSTest. But that means you need physical access to a device, and most of us can’t afford to buy devices just to test them.

Users of GPSTest have been kind enough to share screenshots of their devices for the dual-frequency article I wrote. But this isn’t a scalable or sustainable way to gather device information, especially for data that doesn’t appear on the user interface (e.g., raw pseudorange measurements). In fact, it’s not the first attempt to manually collect this type of information. Google previously maintained a table of device GNSS features in the Android Raw GNSS Measurements documentation, but at some point over the last few years that information was removed — presumably because of the same challenges.

What if there was a better way to share device GNSS features?

Introducing the GPSTest Database

Here’s how to contribute to the GPSTest Database:

  1. On the Status screen, wait for a GNSS fix (location)
  2. On the top Action bar, tap the “Share” icon
  3. Go to the “Device” tab and tap the upload to cloud icon
Using the GPSTest “Share” menu you can now contribute your device GNSS features to the GPSTest Database

This database is implemented as a Google Sheet and is available at https://bit.ly/gpstest-device-database. After uploading, you’ll immediately see a new record at the bottom of the spreadsheet with the data that you contributed:

The GPSTest Database (https://bit.ly/gpstest-device-database), implemented as a Google Sheet, contains crowd-sourced Android device GNSS capabilities

It’s very important to me that GPSTest continues to respect your privacy — after all, that’s one reason it’s open-source software publicly available on GitHub. As a result, no private device information that could be used to uniquely identify you or your device (latitude and longitude, IMEI, ICCID) is sent to the database.

Key features

  • Device manufacturer, model number, and name — Along with the GNSS hardware model name (see below), this identifies your specific device model.
  • GNSS hardware model name — This field is the best way to see the exact GNSS hardware in-use in the device. You’ll see something like qcom,SDM845,MPSS.AT.4.0.c2.1–00545-SDM845_GEN_PACK-2 for Qualcomm chipsets (SDM845 is the Snapdragon 845), and Broadcom, BCM4775, GLL ver. 108.20.22 478864 if additional Broadcom GNSS hardware exists. So no more waiting for teardown videos to discover the packed-in BCM4775! Also, some devices include a version number within this field that can be used to track GNSS changes across software updates. For example, based on this field and Android software build number (see below) it looks like dual-frequency GNSS was enabled for the Xiaomi Mi 10T Lite after a software update. Similarly, the Google Pixel 5 got Carrier phase support (see below) following a software update.
  • Supported GNSS — The GNSS constellations that the device supports. Examples includes GPS, Galileo, GLONASS, QZSS, BEIDOU, and IRNSS.
  • Supported SBAS — The SBAS constellations that the device supports. Examples include WAAS, EGNOS, and GAGAN.
  • Supported GNSS and SBAS carrier frequencies (CFs) — The specific GNSS signal bands that are supported by the device. Examples include B1, B2a, E1, E5a, L1, and L5.
  • Dual-frequency support — This column explicitly shows SUPPORTED if the device is receiving L5 , B2a, or E5a signals or NOT_SUPPORTED if no L5 , B2a, or E5a signals are observed.
  • Raw measurements SUPPORTED if the device APIs return valid GnssMeasurement pseudorange data, and UNSUPPORTED if it does not. Apps can use these raw measurements to calculate a location using innovative techniques that might be more accurate than the one your device OEM has implemented.
  • Carrier phase via getAccumulatedDeltaRangeMeters()— Carrier phase measurements are a more accurate way of determining your location from satellite signals than pseudorange alone by leveraging information from the radio waves that carry GNSS data (see this Google I/O presentation and this InsideGNSS article for details). If a device supports carrier phase measurements via GnssMeasurement.getAccumulatedDeltaRangeMeters() this field will be set to SUPPORTED, and UNSUPPORTED if it does not. If the device hasn’t reported measurement data at the time of submission, this value may be shown as UNKNOWN.
  • User location country code —GPSTest doesn’t send your latitude and longitude to the database for privacy reasons. However, as mentioned earlier, due to the regional device differences in GNSS availability it is useful to know from which country a user is reporting data. Therefore, the on-device Android Geocoding API is used to determine the country where the device is located at the time of submission. The resulting country code (e.g., US, JP) is sent to the database. If the device doesn’t support the Android Geocoding API, then this field is left blank.
  • Various software version numbers — Android version (e.g., 11), Android software build number (e.g., G955USQS8DTJ3) and code name (e.g., REL for production release) can all be used to track capability changes across software updates, as mentioned above. However, from data I’ve seen so far, it seems like GNSS hardware model name is the best indicator for when capabilities may have changed from a software update. These fields can also indicate if the user is running an official OEM ROM or a custom ROM on their device.

Caveats

It is encouraging to see that Android is starting to add APIs that provide more explicit indicators of GNSS feature support. For example:

  • Android 11 added an API for GNSSAntennaInfo, which indicates the number of GNSS antennas and their carrier frequencies, which should be an explicit indicator of dual-frequency support. However, as of March 2021 the data coming from this API seems to be bad for all devices reporting it. Google has indicated that this should be fixed in future updates, at least for the Pixel 5.
  • Android S developer preview hints that explicit APIs for support of raw pseudorange measurements and navigation messages are coming.

I’ll continue to update GPSTest with these explicit support indicators as they become available in Android.

Tips & tricks

Pro-tip: when you’re collecting data on a device, ideally you’d first enter the “Developer options” mode on your device and enable “Force full GNSS measurements”. This will disable duty-cycling of the GNSS chipset on your device between GNSS fixes (i.e., leave the chipset turned on) and ensure the GNSS hardware and software capabilities are maximized according to what the OEM allows. Note, however, that enabling this feature can negatively impact your battery life. The Android S developer preview hints that apps may have a way to automatically enable full measurements in the future. (EDIT Aug 2021 — On Android 12 and higher, in GPSTest v3.9.13 this is now enabled by default as an in-app setting) But for now, see this article if you’re interested in enabling this feature manually. It’s not required to upload data, so feel free to skip this step if you’d like, but should help your device report it’s maximum capabilities.

To keep the database from getting cluttered with a lot of duplicate information, I’ve implemented some scripts that will remove duplicate and some near-duplicate records from the database (see this article for more information about how these scripts work). These scripts prefer records with observations of more GNSS and SBAS, as well as records that show a particular feature is explicitly supported, assuming that the device and GNSS model fields are the same, due to the caveats discussed above. Because GNSS hardware model name seems to indicate GNSS features changed on some devices, records with different Model and GNSS hardware model names will always be retained.

If you do see records that appear to be duplicates at first glance, please be sure to check the Model field to ensure you’re looking at the correct device model, as well as the GNSS hardware model name for further hints if you’re looking at hardware variants (e.g., Qualcomm Snapdragon vs. Samsung Exynos vs. Exynos with Broadcom). Also check the GNSS hardware model name and Android software (incremental) build fields to see if the software was updated from one version to another, and finally the User location country code to see what country the user was in when they reported data.

A scheduled script also fills in the Name field, so it will be blank when you first upload data— see this article for details.

If something looks wrong, please feel free to open an issue on the GPSTest GitHub repository with more information and I’ll check it out. This is the preferred method for reporting problems as it’s easier to track than comments on this article (although other comments here are welcome!).

Closing thoughts

If you’re curious about the software behind the GPSTest Database, see this article that discusses implementation details — it’s all open-source!

Finally, thanks for all the beta testers of GPSTest, including those who provided valuable feedback during early versions when trying to collect data from devices that I don’t have access to.

So, please fire up your new (and old) Android devices, install GPSTest, and upload away! Let’s build this database together. So far over 300 devices are represented — add yours today!

Was this article helpful? Consider following me on Medium. If you’re a user of the open-source GPSTest app and you’d like to support it, you can check out the GPSTest “Buy me a coffee” page: