Android - PMTiles - Asset/Local Source - Crash on Invalid Header / Decompress

[zach-snell]

MapLibre Android Version

11.8.2

Android SDK Version

35

Device

Google Pixel Tablet Simulator API 35

What happened?

I have already diagnosed the issue and will look to open a PR that works but thought I would open an issue for discussion around it.

This may occur on other platforms but I have only tested with Android for now.

In particular, the logic added around PM Tiles expects the providers to respect requested dataRange.
While this is successful with most web sources, not all (any?) of the local sources respect the range or have the ability to handle that concept. As such, when the library tries to operate on the data you have a variety of errors such as invalid compression, invalid header, unexpected data, etc. (Basically it expects a few bytes and gets the whole pmtiles archive every time).

As a stop-gap fix, I created a pmtiles_files_source.cpp modification that wraps requests and ensures the response is the appropriate offset/range. This is very likely not efficient and an improvement could be made by making the android resource provider actually handle pulling specific range of binary data.

However, it is working currently as I am working on a game for my son who likes Geography.
Will link to this issue with my variant for review.

Steps to reproduce

Launch the MapLibreTestApp
Modify one of the variants to use a pmtiles sourced as pmtiles://asset://world.pmtiles (or any pmtiles archive).

I did this by just over-riding the style.json in the simple map example.

Renderer

No response

Relevant log output

Additional context

No response

[louwers]

Thanks for the report! This is a relatively new feature so I think it is quite likely we overlooked some things. Ideally we should not only fix any problems, but also add some test coverage for loading local PMTiles files.

Thanks for sharing your fix. If you can share some more details about the problem that would be helpful as well.

cc @tdcosta100

[zach-snell]

I agree.

However, I also acknowledge I am not as in depth on this library and so tried to make the change as small as possible to show the issue and a resolution.

It may be prudent to modify this to a more comprehensive solutions.
Opened PR here to look at / discuss : #3305