search

stadiamaps / ferrostar

A FOSS navigation SDK built from the ground up for the future
https://stadiamaps.github.io/ferrostar/
Other
179 stars 25 forks source link

Android Auto integration #7

Open ianthetechie opened 1 year ago

Archdoog commented 2 months ago

Some updates for discussion:

We must provide our own custom Map "surface" behind the CarApp Template(s). Unlike CarPlay on iOS where UIKit is supported for this layer, Android only seems to offer android.graphics.Canvas to draw this layer. Which from research typically results in an FPS constrained bitmap generation process. Where a Handler draws a bitmap on the canvas on the surface at a high rate. There are several avenues to go on this:

  1. There is an ongoing discussion happening from this PR https://github.com/maplibre/maplibre-native/pull/2802. In summary, Flitsmeister posted that code in slack, this PR originated from that and now Bart has followed up to determine if Flitsmeister want's to provide the code with proper license. It sounds like they're interested in providing the code, so if that happens and an android auto map surface will likely get merged into maplibre-native. We could consider that, but have to rebuild our symbols, zoom, etc on it.
  2. This seems to be extremely tricky, but many of the pieces exist to generate a bitmap from a ComposeView. The issues with this approach are leveraging the Lifecycle, SavedStateRegistry and Window. All of which don't seem to exist as Compose expects in the CarContext/Screen. I've done several passes of this and may well be close on one of them, but it's a lot of crashing for things like null lifecycle, Window issues etc. This seems like an ideal solution, but it may well require someone with deep android platform and Compose knowledge (Aka someone building core Android Compose 😆).
  3. Lastly, we could hack these two solutions together by essentially piping an underlying MaplibreMap from the maplibre-compose-playground MapView into the Flitsmeister surface renderer. The idea being that the compose view in the Android application context (even if not visible) could essentially be running the stateful map, which is then injected into the surface as a pre-configured MaplibreMap to render as a bitmap. Janky, probably has tons of issues, but might be a way to get our rendering of symbols, without having to reconstruct it. Last note here, this may actually be a good excuse to totally re-think the MapView in the compose playground to get us one step closer to BSD-3 or MIT on that library.
Archdoog commented 2 months ago

@haysmike #2 is the one where the major questions are!

Archdoog commented 1 month ago

Not sure if this is useful, but might be:

thanhdang198 commented 1 month ago

Additional information, you can create the MapLibreMap as an XML component and it can be converted to the bitmap too. :D Flitmeister said they will create a repo with a sample app, but they have no timeline for this yet though.

Archdoog commented 4 days ago

Flitsmeister posted their example under MIT license https://github.com/flitsmeister/MapLibre-Android-Auto-Sample. We can absolutely go this path, but I still think it's worth further exploration into the Compose view as map surface.

That'd allow us to much more effectively adapt our Android Auto map with content driven by our compose work. Using the filtsmiester sample, we'd have to do what Mapbox does where we have to recreate bitmaps of all the components like speed limit signs, the route polyline, etc.