@Mikaela Thanks, this is a good idea. It could also cover displaying the info:

• GNSS and SBAS detailed info - More detailed stats for each constellation, including counts of satellites with almanac and ephemeris data and used, Show "# Sats" in X/Y/Z format #365, Put tallies next to each item in the legend on Sky tab #438
• Errors in data
  • CF errors (Indicate errors in CF output in UI #295)
  • Satellites that are shown in list without alamanc or ephemeris data but with elevation and azimuth (Show "# Sats" in X/Y/Z format #365 (comment))
  • Satellites without C/N0 or almanac or ephemeris (see above)
  • GPS week number rollover issue (Flag wrong times from GPS week rollover issue #369)
  • NMEA DTM datum, geoid offset and altitude MSL (ortho height) errors - see Alt MSL - Reported value is wrong on some devices #503 and Parse DTM and display some info if it is non-standard #527
  • Disagreements between GnssStatus and raw meaurements APIs for CF - see Mi 8 Beidou signal marked as B1C instead of B1I #538
  • Disagreements between dual frequency signals on almanac and ephemeris from same satellite
• Support for:
  • dual-frequency - including number of dual-frequency satellites in view and used - Add clear "dual-frequency support" label #265
  • raw measurements
  • navigation messages
  • inject time
  • inject XTRA data
  • Vertical accuracy - see Accuracy Enhancements #442
  • GnssAntennaInfo
  • carrier-phase via getAccumulatedDeltaRangeMeters() API data is valid (Could you show if the carrier-phase is valid in your app？ #421). Showing the human readable constant values like ADR_STATE_HALF_CYCLE_RESOLVED instead of the raw integer values would also be helpful.
  • automatic gain control
  • hardware clock
• Device info:
  • GNSS satellite blacklist info (doesn't seem to be accessible by apps?)
  • GNSS hardware year, which is currently buried in the Help section. See https://developer.android.com/reference/android/location/LocationManager#getGnssYearOfHardware()
  • GNSS hardware model name - https://developer.android.com/reference/android/location/LocationManager#getGnssHardwareModelName()
  • Requested vs. avg actual location update rate (e.g., if you request minTime=.5s, but it updates every second.
  • SafetyNet pass/fail - or some other way to tell if you're running an official build
  • System version info (Android API, build names, etc.)

The caveat here is that Android APIs only tells applications about satellite properties in view of your device right now - there isn't any way to query general support for satellites. So, for example, if your device hardware and software supports QZSS, but you're not in a location where QZSS satellites are visible, GPSTest has no way of knowing that your device supports QZSS.

But a simplified view of what the device supports based on satellites currently in view is a good idea.

An example of another app that has a simplified view of device info is https://play.google.com/store/apps/details?id=com.eu.nsl.gnsscheck

I've started working on logic that can support this at #355.

So here's a very rough UI mockup for this screen showing device GNSS support. It would appear as another top-level navigation item, likely "Dashboard", along side "Status", "Map, "Sky".

Any feedback/suggestions/alternate proposals welcome!

Interesting idea proposed here:
https://groups.google.com/g/gpstest_android/c/W1OB-L_o5kQ/m/LKO80NPAAQAJ

Could we score overall device GNSS capabilities?

adding a numeral field with a formula to score total gps capabilities (for example bands, frequencies, antennas,... )

Not sure what that exact formula would look like, but ideas are welcome.

This issue has been automatically marked as stale because it has not had recent activity. Please comment here if it is still valid so that we can reprioritize. Thank you!

I would still find this feature helpful

This issue has been automatically marked as stale because it has not had recent activity. Please comment here if it is still valid so that we can reprioritize. Thank you!

Android U adds new methods to the GnssCapabilities API that will allow us to read things like signal support directly from the API versus relying on real-time observation of signals, so we should use that as well.

This issue has been automatically marked as stale because it has not had recent activity. Please comment here if it is still valid so that we can reprioritize. Thank you!

Not stale

This issue has been automatically marked as stale because it has not had recent activity. Please comment here if it is still valid so that we can reprioritize. Thank you!

I do still sometimes find myself missing this only to find out there is an open issue.

Agreed, not stale