What’s new in Location on Android 13 Developer Preview 1

As a developer, it’s always exciting when a new Android Developer Preview drops. What shiny new Application Programming Interfaces (APIs) will I be able to use in my app? 👀

Android 13 Tiramisu Developer Preview 1 was announced on February 10, 2022. Let’s take a look at the Android documentation and see what’s new in the area of Location-related APIs.

Android 13 Tiramisu Developer Preview 1 is out! (Source: Google)

Location

It looks like the Location class got a handful of new methods:

long getElapsedRealtimeMillis()

Return the time of this fix in milliseconds of elapsed realtime since system boot.

long getElapsedRealtimeAgeMillis()

A convenience methods that returns the age of this location in milliseconds with respect to the current elapsed realtime.

long getElapsedRealtimeAgeMillis(long referenceRealtimeMs)

A convenience method that returns the age of this location with respect to the given reference elapsed realtime.

These are all related to timestamps, and specifically the timestamps used to measure elapsed time, or the age of something.

Location already had a method called getElapsedRealtimeNanos(), which is defined as follows:

Return the time of this fix in nanoseconds of elapsed realtime since system boot.

This value can be compared with SystemClock.elapsedRealtimeNanos(), to reliably order or compare locations. This is reliable because elapsed realtime is guaranteed to be monotonic and continues to increment even when the system is in deep sleep (unlike getTime()). However, since elapsed realtime is with reference to system boot, it does not make sense to use this value to order or compare locations across boot cycles or devices.

All locations generated by the LocationManager are guaranteed to have a valid elapsed realtime set.

While the addition of the new “ElapsedRealtimeMillis” fields isn’t explained, looking at the source code it seems to me that they were added as a convenience for developers when using milliseconds for location age. For example, to avoid rounding issues due to a mismatch in precision — if you’re trying to compare milliseconds to nanoseconds, you need to round the nanoseconds value. And this could lead to inconsistencies depending on the rounding method used. These additions seem like convenience methods to make sure developers are doing these calculations consistently when using milliseconds.

Another new method in Location is:

boolean isComplete()

Return true if this location is considered complete. A location is considered complete if it has a non-null provider, accuracy, and non-zero time and elapsed realtime. The exact definition of completeness may change over time.

All locations supplied by the LocationManager are guaranteed to be complete.

This one is interesting. Maybe it’s a convenience method related to quality control, to make it easy for the platform and apps to check if a location has all the needed information and discard it if it doesn’t?

Again, not a lot of guidance here about when this might be used and why.

A few methods were also added to remove existing data from a Location object, including removeBearingAccuracy() , removeElapsedRealtimeUncertaintyNanos(), removeSpeedAccuracy(), and removeVerticalAccuracy() — nothing exciting here.

GNSS Measurements

The GnssMeasurement class itself didn’t see any changes in the developer preview, but GnssMeasurementRequest and it’s Builder did:

setIntervalMillis(int value)

Set the time interval between the reported measurements in milliseconds, which is 0 by default.

An interval of 0 milliseconds means the fastest rate the chipset can report.

The GNSS chipset may report measurements with a rate faster than requested.

Previously, apps could request the refresh interval of Location updates, but couldn’t request an independent refresh interval for GnssStatus or GnssMeasurements. This now allows developers to specifically request a refresh interval for GnssMeasurements. However, GnssStatus still doesn’t have it’s own refresh interval and is presumably set to refresh as frequent as possible when an app registers a callback.

This new GnssMeasurements interval could perhaps be related to a bug spotted in Pixel 6 devices on Android 12 related to wrong information in the GnssStatus APIs (and maybe GnssMeasurement APIs?) when the Location request interval was set to a value larger than one second. This setting may be used to decouple the two refresh values and make sure valid information is showing up in the APIs.

Concluding thoughts

And that’s it. So, not a lot of new changes in Location-related APIs on Android 13 Developer Preview 1, and not a lot of explanation for what’s new.

Unfortunately GnssCapabilities API didn’t see any new additions. As I wrote in this article, I’ve been hoping that Android moves towards a more explicit API structure that defines what GNSS capabilities a particular device supports (e.g., carrier frequencies/bands, carrier phase measurements) without having to infer support from other data.

Also, still no support for getting altitude above mean sea level directly from Android APIs, which is a feature I’ve previously requested here (please upvote if you’d like to see it too).

Do you have additional insight to these new APIs? What APIs would you like to see in Android related to location? Did I miss something else new? Please let me know in the comments below.