mapbox: TileOverlay PoC implementation

[depau]

Hi!

I got to writing a proof-of-concept implementation for the Google Maps TileOverlays as discussed here: #3058 (comment)

To make the tile overlays work, I implemented an HTTP request class that intercepts requests to a special invalid domain under microg.org (though anything that can't be registered works).

Once the request is intercepted, the class determines which TileProvider it should get the data from, it fetches the data, encodes it as PNG if necessary, then returns a fake HTTP response with the payload.

In the current implementation I went out of my way to work around Mapbox's internal caching system, forcing it to not cache any of the custom tiles and instead implement a LRU cache in the interceptor class.

This is because a few apps rely on the TileOverlay.clearTileCache() to drop caches and re-render all custom tiles currently displayed, but Mapbox refuses to actually reload the images unless you make it absolutely necessary.

Why is this a PoC?

https://github.com/microg/GmsCore/pull/3481/changes#diff-06766ea2baeef42a2fc47e09f2d8e70cca8951e51c08bd010b5ef4ada9f31073R195-R199

It looks like the version of Mapbox in use, which I imagine is locked for SDK compatibility reasons, doesn't expose the method to update the moduleProvider implementation (and with it the HTTP request implementation), although later versions do.

To test the feasibility of the implementation I went ahead and used reflection to move forward, but I haven't found a cleaner way to do it.

---

This PR depends on #3058 and therefore it includes all commits from that PR. When reviewing, be sure to only check the last commit, which is the only difference between this and the other PR.

---

Some screenshots

Screenshots (click to expand)

My tile overlay test app: https://github.com/depau/gmaps-tile-overlay-demo

(Please note the screenshots are from 3 different devices, and that the overlay tile borders are not DPI-aware)

Before:

GApps:

After:

My local transport app:

Before:

After:

[depau]

This is where I've had to use reflection

[ak800i]

Hi @depau, @mar-v-in — I only found #3481 and the #3058 discussion after I'd opened #3595, apologies for the parallel effort. Since we've both implemented TileOverlay for the Mapbox renderer, I'd rather compare notes here than let two PRs drift.

Both solve the same core problem: MapLibre-Android's RasterSource only takes a URL — there's no callback tile source like maplibre-gl-js. Two ways to bridge it:

• mapbox: TileOverlay PoC implementation #3481 (yours): a MapLibre HTTP request interceptor on a sentinel domain. As you noted, the pinned Mapbox version doesn't expose moduleProvider, so it needs reflection, plus an LRU cache to make clearTileCache() work, and it currently rides on mapbox: Implement Z-index and polyline spans handling #3058.
• Implement TileOverlay in the Mapbox renderer #3595 (mine): a tiny loopback ServerSocket on 127.0.0.1 serving /<token>/<epoch>/{z}/{x}/{y}; TileOverlayImpl points a RasterSource at it. No reflection, no dependency on mapbox: Implement Z-index and polyline spans handling #3058 (standalone on master).

On the caching point you flagged — apps using clearTileCache() to force a re-render — I hit the same stale-tile issue at first (MapLibre serves cached bytes for an unchanged URL). I solved it without an LRU by baking a cache-busting epoch into the URL: clearTileCache() bumps the epoch → re-added source gets a fresh URL → guaranteed cache miss → provider re-invoked, while normal panning still benefits from HTTP max-age.

I'm not attached to mine winning — you clearly own this area and have the polyline/z-index work in flight. Happy to do whatever you and @mar-v-in prefer: fold the loopback bridge into #3481, close mine in favor of yours, or land mine standalone if a reflection-free, #3058-independent path is useful. What's your read?

[depau]

Hi @ak800i! Thanks for the ping and the walkthrough, although it sounds a lot like Claude :P

I will need to take some time to properly review your PR, I only gave a quick look.

One important note is that my other PR #3058, which this PR is based on, implements a lot of important Z-index logic, which changes a lot how other functionality that makes use of map layers needs to be implemented. I think it's best to have that PR merged first before either tile overlay implementation.

With regards to the actual tile overlay implementation... honestly I hate both 😆

I don't like reflection, but I also really don't like socket servers in Android apps. Yeah, it's a random port, but it can still be enumerated and it potentially allows other code running on the device, potentially including websites i.e. with DNS rebinding attacks, to extract tile data. This is unlikely to be an issue in the vast majority of cases, but we can't know for sure what apps are going to use the TileOverlays for, and it could be something private. On the other hand, reflection is nasty...

I'll leave the tough job of choosing either or none to the maintainers :)