Coarse location on Android Automotive OS

To respect user privacy, app developers are encouraged to only request coarse location permissions. Apps that need an approximate coarse position typically use the fused network location (FLP) because it's fast and consumes less power. As compared to Android-based mobile devices, network location in automotive apps can be more challenging. You can use two Android APIs:

Many automotive apps use the FLP from the Google Play services API instead of LocationManager. FLP selects the optimal location provider based on location request criteria and policies (power and accuracy) needed by the vehicle.

You can instead opt to explicitly request and use NETWORK_PROVIDER as well as GPS_PROVIDER for fine positions, which uses android.permission.ACCESS_FINE_LOCATION permissions. On Android 12 (API level 31) and higher, the FUSED_PROVIDER, previously accessible only through the Google Play services API, is available as a location provider to LocationManager. You can see an implementation of FLP in FusedLocationProvider.java.

While it's possible to use GPS_PROVIDER with coarse permission rights only — the framework artificially degrades accuracy to align with expectations — it makes little sense for developers targeting Android phones because overall availability is poor and often slower to obtain a coarse position.

Network location in automotive

The NETWORK_PROVIDER used on Android phones (with Google Mobile Services) determines location based on nearby cell towers, Wi-Fi access points, and Bluetooth (BT) beacons. As a result, NETWORK_PROVIDER may require a data connection.

For automotive apps, device constraints differ. Because Gthe global navigation satellite system (GNSS) is usually on, no penalties are incurred due to increased power and battery usage. As a result, IVI uptime is not compromised. We strive to minimize data exchanged with our servers.

Many apps use FLP from the Play API instead of LocationManager directly because FLP automatically selects the best location provider to satisfy your request's criteria or policies, such as power and accuracy.

Unlike mobile devices, vehicles rarely appear to jump from one place to another. Vehicle position is known under the hood most of the time.

Network location provider (NLP)

Most vehicles don't implement required telephony APIs to get needed information on a Cell ID (and signal strength). As a result and, because we minimize data usage, no additional functional implementation of NLP is provided.

Fused location provider

The mobile FLP fuses information from other sensors to enhance location quality, in addition to using network and GPS providers. Conversely, the Automotive FLP uses GPS_PROVIDER as its underlying source. It adjusts the GNSS positions, adding intentional error to degrade accuracy when a client requests coarse locations.

As such, in a very few instances, there can be a longer than usual time for the first position to be available. For example, the very first time a vehicle or, to be more precise, its location subsystem is used or after getting towed.

Design apps to target mobile and automotive uses

For apps targeting mobile and automotive devices that don't require a higher quality of precision, request android.permission.ACCESS_COARSE_LOCATION only and fall back to using FLP when available. Alternatively, use GPS_PROVIDER directly with the same permissions. The framework degrades the precision of the underlying GNSS position to align with API expectations. To learn more, see Accuracy in Request location permissions.

In addition, these apps must explicitly declare the android.hardware.location.network feature as optional in their manifest. For example:

<uses-feature android:name="android.hardware.location.network" android:required="false" />

This approach helps achieve greater compatibility with devices across form factors and, therefore, maximum app availability with no code differences for getting positions when needed.