Render a usable map when no Mapbox/Stadia key is configured

[ak800i]

Summary

Makes the map render a usable basemap when GmsCore is built without a Mapbox or Stadia key (the common case for community builds), and fixes the renderer failing to load under a renamed package.

Verified end-to-end on-device with Google Photos' Map/Places (MapExplore) feature, which previously showed a blank/broken map even after the crash was worked around.

Changes

• fix(maps): Correct BitmapDescriptorFactory error message.
  getDelegate() threw an IllegalStateException mentioning CameraUpdateFactory instead of BitmapDescriptorFactory.

• fix(maps): Load the renderer from the installed GmsCore package.
  MapContext hardcoded com.google.android.gms when creating the package context. When GmsCore is installed under a different package name (e.g. app.revanced.android.gms), this bound to the wrong package — or a disabled real Google Play Services install — so the bundled libmapbox-gl.so could not be extracted and the map failed to render (UnsatisfiedLinkError). It now resolves whichever GmsCore package is actually installed.

• feat(maps): Fall back to key-less OpenStreetMap tiles when no map key is set.
  When neither MAPBOX_KEY nor STADIA_KEY is configured at build time, the vector styles cannot fetch tiles and the map renders blank. Fall back to key-less OpenStreetMap raster tiles (rendered by MapLibre without any token). This fallback is gated on both keys being empty, so keyed builds keep the existing styled vector maps and lite mode. Lite mode is bypassed only in the key-less fallback, because the snapshotter cannot build the logo overlay for a raster style.

Context

Investigated as part of ReVanced discussion microg#1068 (Google Photos "Photos won't run without Google Play Services" / IBitmapDescriptorFactory is not initialized). The crash itself is fixed by a separate revanced-patches change; this PR is what makes an actual map appear.

[oSumAtrIX]

Why is the PR here needed? I would be under the impression that GmsCore upstream already implements Maps. If not, would this PR not be suitable to upstream GmsCore?

[oSumAtrIX]

MapContext hardcoded com.google.android.gms when creating the package context. When GmsCore is installed under a different package name (e.g. app.revanced.android.gms), this bound to the wrong package — or a disabled real Google Play Services install — so the bundled libmapbox-gl.so could not be extracted and the map failed to render (UnsatisfiedLinkError). It now resolves whichever GmsCore package is actually installed.

This makes sense for ReVanced, the patch is mandatory in our repository. Can you confirm that it is not already tackled by #308?

[oSumAtrIX]

feat(maps): Fall back to key-less OpenStreetMap tiles when no map key is set.

This change seems to be intended to upstream. If upstream decides that the current behaviour is right, can upstream explain why they do not implement the same fallback mechanism

Thanks for the PR!

[ak800i]

Thanks for the quick review - all three points are fair, and you are right this PR shouldn't live in the fork.

MapContext / package resolution: #308 already covers this, and more comprehensively. So this is redundant with #308.

Keyless OSM fallback: Agreed it's general rather than ReVanced-specific, so it would belong in microG upstream. But there's likely a deliberate reason upstream requires a key instead of shipping a free fallback: OpenStreetMap's Tile Usage Policy forbids using tile.openstreetmap.org from distributed apps, and the Esri/ArcGIS endpoint I used for satellite is the same. At GmsCore's scale a default keyless raster source would violate those terms and risk being blocked. I'll figure that out separately.

BitmapDescriptorFactory message: just a wrong string in an exception (CameraUpdateFactory → BitmapDescriptorFactory), no functional impact — not worth carrying on its own.

Given that, I'll close this. Thanks for the maps work in #308!

[oSumAtrIX]

BitmapDescriptorFactory message: just a wrong string in an exception (CameraUpdateFactory → BitmapDescriptorFactory), no functional impact — not worth carrying on its own.

Yeah, it can be reported as a small issue to upstream, doesn't change functionality.

Regarding the Tile Usage Policy, we can ship a key in our releases, if that's intended, correct, and free.

This states its free for non-commercial free use, which is the case here https://www.maptiler.com/cloud/pricing/

[ak800i]

Just to clarify, you are open to ship a maptiler key in the ReVanced fork releases?
Who would obtain this key?

[oSumAtrIX]

ReVanced as the organization would, however since we are registered non-profit and the use of the key is also uncommercial, I suppose we qualify for a free key?

[ak800i]

The pricing page does state that non-commertial usage is in the free tier, however, the free tier has limits. Instead of calculating if/when all the users would hit this, I think a better approach would be to expose a settings page in GmsCore (upstream) so the users can supply their own key for a map provider (currenly only Mapbox is implemented, but OSM/maptiler could easily be implemented very similiar to this PR).

And then the users can provide their own key, and choose their own map provider (Mapbox, OSM, maptiler, etc.)

This sounds worth pursuing to me. I would appreciate your input because you already have expertise in this codebase/community while I am just ramping up for the first time.

[oSumAtrIX]

I think this would breach the scope of this fork, so again this would at max be something upstream should consider. The limit I can see is regarding some storage? What is that about?

[oSumAtrIX]

If user supplied keys are the only option however, then we'd have to look if its in upstreams scope to implement user supplied keys, if not then it would become subject to our fork under the basis of their reason