Crowdsourcing GNSS features of Android devices

Can’t I just look at the specs?

Model variants have different chipsets

OEMs sometimes add GNSS receiver hardware

Devices have other limitations

Regional limitations

Software changes matter

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

Introducing 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
The GPSTest Database (, implemented as a Google Sheet, contains crowd-sourced Android device GNSS capabilities

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.


  • 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.

Tips & tricks

Closing thoughts




Improving the world, one byte at a time. @sjbarbeau,, I work @CUTRUSF. Posts are my own.

Love podcasts or audiobooks? Learn on the go with our new app.

Recommended from Medium

First Look at iOS 14!

Early computer technology was quite unhuman and largely misunderstood by the masses.

Why is Ethernet faster than WiFi?

Why You Should Care About 5G.

Are You Ready To Trust Technologically Advanced Cars Just Yet?

Pandemic Accentuates Need for Business Technology

Augmented Reality Isn’t Magic

Should you buy Samsung Galaxy buds plus or Apple AirPods pro in 2020 for Android?

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Sean Barbeau

Sean Barbeau

Improving the world, one byte at a time. @sjbarbeau,, I work @CUTRUSF. Posts are my own.

More from Medium

Intermediate: ToDo Task Scheduler in Huawei Mobile Service Based Android App

How to Create a Firebase Authentication in Android studio.

How to Get Full Control of Your Android Phone

Creating & Deploying the app on Play store: My experience