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?

Mobile device manufacturers have been notoriously vague about GNSS features in official specifications. For example, if you go to Samsung’s website and look up specs for the Samsung Galaxy S21, you’ll see:

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

Unfortunately OEMs ship different model variants in different countries, which can include different chipsets. For example, the S21 variants in the U.S., Canada, Korea, Chinese and Japanese normally get Qualcomm Snapdragon chipsets while Europe and other areas around the globe get Samsung Exynos chipsets. The Snapdragon 888 specs say it is capable of dual-frequency, but the Exynos 2100 specs don’t even list the GNSS capabilities!

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

Some devices (Xiaomi Mi 8, Samsung Galaxy S9, S9+, S10, S10+, Note10 Exynos variants) have packed in additional GNSS receiver hardware, in particular the Broadcom 4775 series that supports dual-frequency GNSS. And the presence of this additional hardware isn’t listed on any device spec sheet, so you’ll need to rely on Internet tear-down videos for your exact model to figure out what’s inside.

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

Unfortunately even if you can confirm that a device has a dual-frequency receiver like a Snapdragon 888, it doesn’t mean the device will actually use L5 and E5a signals. Several devices (Samsung Galaxy S10, Samsung Galaxy S20 FE 5G, Google Pixel 4a 5G) include chipsets that support dual-frequency, but for some reason the signals don’t show up in GNSS testing apps. Presumably this is due to other hardware limitations on the device, such as the lack of a 2nd GNSS antenna and RF frontend for the L5/E5a carrier frequency, or licensing/purchasing contract limitations between the chipset vendor and device OEM.

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

Regional limitations

As the S21 specs say, “Galileo and BeiDou coverage may be limited”. But what does that mean? “G” in GNSS stands for “Global”, right? Well, for years the FCC restricted use of Galileo for devices in the United States, and even after the FCC lifted the ban many devices were never updated to allow it. The same restriction still seems to apply to BeiDou in the U.S. What about other countries? Do they force OEMs to limit which GNSS constellations can be used? 🤷

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

Software changes matter

Several devices have launched with GNSS features that changed with later software updates. The Google Pixel 4 and 4XL initially launched without L5 and E5a support, but a software update later added the capability. Conversely, some users have reported that entire GNSS constellations have disappeared after firmware updates due to bugs.

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

The latest feature in GPSTest sets out to solve this problem by providing a simple way for users to contribute device information to a centralized, publicly-available 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

Here are some of the most interesting device features that you’ll find in the database:

• 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

The main caveat to data in the GPSTest Database is that Android doesn’t provide an API that explicitly indicates which GNSS and SBAS are supported by a device. As a result, GPSTest can only report on what it observes from the live environment (with some emerging exceptions — see below). GPSTest tries to maximize results by forcing the user to wait for a first fix before they can submit data. But, there are certainly cases where available SBAS or other data could be influenced by the user’s position and the time of day. Ultimately, each record reflects that individual user’s experience with their particular device in that location — there is no 100% guarantee that your experience will be the same.

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

To submit data to the GPSTest Database, in the app first switch to the main “Status” screen. Before submitting, go outside and wait for a GNSS fix. On devices that do support dual-frequency, make sure you wait for the L5/E5a signals to show up before submitting the information (some dual-frequency devices will show L1-only for a few seconds before locking on L5). Then tap the upload button (the “cloud with an arrow” icon) and you should immediately see a new record appear at the bottom of the sheet.

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

I’m excited to launch this new feature and I hope it brings some much-needed transparency to the Android industry for device GNSS features. I also hope that it will encourage OEMs to publish more detailed and accurate information about device variants, and allow consumers, enthusiasts, and GNSS professionals to make more informed decisions. Oh, and if you’re wondering — looking at GPSTest Database it seems the S21 (Snapdragon and Exynos variants) does not support dual-frequency, while the S21+ and Ultra (Snapdragon and Exynos variants) do. 🤷

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.