[Android] Decide on how to get location updates

[ianthetechie]

Android is an unmitigated disaster when it comes to location services. We can hack things up with the core Android Location APIs, but will need a better long-term solution.

Here is the shortest summary I can muster to describe the state of Android location services:

• Android (AOSP) has the LocationManger class. It mostly works, but it's pretty low level and doesn't fuse updates. You have to manually subscribe to updates from GPS, network, etc., decide what to do with the updates, and handle sub/unsub yourself to manage power consumption.
• Google made their own fused location provider, which is ostensibly more battery-friendly, but may also be wildly inaccurate. I'll give Google the benefit of the doubt here though, and assume that the devs writing this should simply be filtering based on quality, and the provider is probably doing its job as designed, so this is probably the best option. Unfortunately, instead of improving the Android core, Google shoved this in Play Services, which is unavailable, sandboxed, or shimmed with implementations of unknown quality on many Android devices.
• It is technically possible to ask your local Android "distro" what providers it has available, but many implementations either lie or implement the fused provider poorly. See this issue on the Organic Maps repo for a sampling of what could go wrong. I assume this is not exhaustive.

I am not currently aware of any open-source projects within the Android developer community which attempts to mitigate the above issues via a common "better fused location client" that has wide adoption. I hope that I'm just missing something, but I've confirmed most of the above with others in the Android community.

If this is indeed the case, we may simply have to push this down a layer and suggest that developers building apps with Ferrostar will have to consider this for their use cases individually. The Organic Maps issue doesn't inspire much confidence as they seem to have implemented workarounds specific to F-Droid.

[ianthetechie]

Minor update: to make matters even more confusing, both the Google Play Services and core Android APIs use an interface of the same name but with a different namespace and definition for the listener ;)

• Google Play Services LocationListener
• android.location.LocationListener

The onLocationChanged method is shared across both interfaces; the Android core one adds several others.

[ianthetechie]

Potential solution available in #28; sounds like they are solving this problem directly.

[ianthetechie]

I think at the end of the day we are going to have to build multiple location providers. We can build first passes of each in separate modules. They have to be separate because not all Android builds include Google play services, and Naurt is a commercial product.

[ianthetechie]

Assigning to you @Archdoog since you're pretty far down the path of passing a location engine into Ramani. High-level integration steps (mirroring that of iOS):

• Create a StaticLocationEngine (better names welcome :P just rolling with that since it's what I have from iOS) that implements LocationEngine. This can live in the MapLibreUI gradle project inside Ferrostar; I somewhat doubt it's worth the effort to upstream this to Ramani compose playground.
• Implement the location provider using the Google Fused Location Client when it is available, falling back to something like this in MapLibre otherwise. I think we can do this with runtime checks to see if Google Play Services are available. We'll put this directly in Ferrostar.
• Hook up the NavigationMapView to update a local instance of the StaticLocationEngine, which drives updates (most of the time; via tracking with heading) rather than direct manipulation via cameraPosition