To respect user privacy, app developers are encouraged to only request coarse location permissions. Apps that need an approximate coarse position typically use the 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:
LocationManager API requires you to explicitly identify the preferred location provider.
Google Play Services API offers a more simplified way for your to work with location with the introduction of the Fused Location Provider (FLP).
Many automotive apps use FLP from the Google Play Services (GPS) API instead of LM. FLP selects the optimal location provider based on location request criteria and policies (power and accuracy) needed by the vehicle.
You can instead choose to explicitly request and use
NETWORK_PROVIDER in LM, as well as
GPS_PROVIDER for fine positions, which uses
android.permission.ACCESS_FINE_LOCATION
permissions. In API 31, the FUSED_PROVIDER,
previously accessible only through the GPS API, is now
available as a location provider to LM. You can view a more simple
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) has
changed from determining location based solely on nearby cell towers to
also use Wi-Fi access points or even Bluetooth (BT) beacons. Use of
NETWORK_PROVIDER may require a data connection.
For automotive apps, device constraints differ. Because GNSS is normally on, no penalties are incurred due to increased power and battery usage. As a result, IVI uptime isn't compromised. We strive to minimize data exchanged with our servers.
A lot of apps therefore use FLP from the Play API instead of LM directly as FLP automatically does the smart thing by using the location provider best able to satisfy location request criteria/policies (namely power and accuracy) under the hood.
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
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, in addition to smartly using network and GPS providers as
appropriate, fuses information from other sensors to further enhance the
quality of locations. The current implementation of Automotive's FLP on the
other hand takes advantage of the aforementioned assumptions and uses
GPS_PROVIDER as an underlying source all the time. It fudges the positions
from GNSS, adding some errors to be more inaccurate when needed. For example,
when coarse locations are provided to a client.
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
We recommend that 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, as a last recourse, use GPS_PROVIDER directly
with the same permissions. The framework degrades precision of the underlying
GNSS position to align with API expectations. To learn more, see Accuracy.
In addition, these apps must explicitly declare the
android.hardware.location.network
feature optional in their manifest.
For example:
<uses-feature android:name="android.hardware.location.network" android:required="false" />
This approach ensures maximum compatibility with devices across verticals and, therefore, maximum app availability with no code differences for getting positions when needed.