Map NOT displayed

[TIMAI2]

There seems to be something not working with OSM, especially for the Roads MapType. In Companion app it seems to work, only showing tile from centre, drag to either side and no tile shows, but with compiled app, tested on 2 devices (A13 & A16) the app starts up showing Roads type one can zoom or drag around, but if one switches to Aerial or Terrain (which seem to be working OK), then back to Roads, Roads is blank (grey hatched background).

(note, I see several Kodular users having similar problems)

Demo app
testMap.aia (1.8 KB)

[SteveJG]

@TIMAI2

if one switches to Aerial or Terrain (which seem to be working OK), then back to Roads, Roads is blank (grey hatched background).

I think this may be an issue with OSM's servers.

None of my OSM app is rendering Roads properly at the moment. Apparently an ORS issue.

Or possibly a Google Play Protect issue ??? Investigating.

Seems ALL my apps that has a Location associated with OSM does not work.

evidently to protect your data, permisions for this app will be removed if the app is unused for a few months.

o restore automatically removed app permissions on Android, first find the specific app's "Info" page by tapping and holding its icon, then select "Permissions" to re-enable them manually. To prevent this from happening in the future, you can disable the "Remove permissions if app is unused" setting for individual apps in their respective permission settings within the device's main settings app.

To manually restore permissions:

1. Find the app: On your phone's screen, tap and hold the icon of the app whose permissions were revoked.
2. Go to App Info: A pop-up window will appear; tap the "Info" icon (usually in the top right) to go to the app's information page.
3. Select Permissions: Tap on the "Permissions" option on the App Info page.
4. Re-enable permissions: You can now tap on a specific permission to allow or deny it.

To disable the "Remove permissions if app is unused" feature:

1. Open Settings: Go to your phone's main Settings app.

• Navigate to Apps: Tap on the "Apps" (or "Apps & notifications" or "Application Manager") option.
• Find the app: Scroll through the list to find the specific app.
• Go to Permissions: Tap on the app and then select the "Permissions" option.
• Turn off the toggle: Find the toggle for "Remove permissions if app is unused" and turn it off to prevent it from revoking permissions in the future.

Why this happens:

• Android introduced the "permission auto-reset feature" in Android 11 to protect user privacy.
• It automatically revokes runtime permissions (those that prompt the user for access) for apps that haven't been used for a few months.

-- Steve

[maiwolf]

I am having the same problems as described above.
An app which was working for years using OSM road type map does not show any map anymore. I can also reproduse the behaviour of your nice little test app: road works first, switch to aerial (any see only a resolved map at higher zoom levels!), switch back to road and get an empty map.
Very strange and very frustrating.
I have tested this in online and offline app inventor, no difference in the build apps.

Is there somebody working on this?
All the work which I did put in programming my app is kind of obsolete now.

[maiwolf]

I have tried your suggestions, but, unfortunately, it did not bring back my map.

[Akash_Gite]

@ewpatton @Susan_Lane
Hi everyone,
I’ve been investigating this issue locally and can confirm the behavior described here.

I can consistently reproduce the bug on a locally built MIT AI2 Companion:

• Road → Aerial works
• Aerial → Road results in a blank/grey map

I traced this to OSMDroid’s tile provider behavior when switching tile sources. The MapType property does update, but switching back to Roads does not reliably reload tiles unless the tile provider state is reset.

I experimented with clearing the tile cache and resetting the tile source in NativeOpenStreetMapController.setMapTypeAbstract, which improves behavior, but Roads still sometimes fail to reload after Aerial.

Questions for maintainers:

1. Is there an expected or recommended way in App Inventor to fully reset the OSMDroid tile provider when changing MapType?
2. Would recreating the MapView or its TileProvider on map type changes be acceptable from a performance standpoint?

I’m continuing to test locally and can share a PR once the behavior is fully stable.

[ewpatton]

I think the issue was mainly introduced when we added support for custom tile layers. My guess is that if you compare the behavior before and after that commit, it should reveal the change that needs to be made to correct the problem.

[Akash_Gite]

Hi everyone,
I wanted to share an update now that I’ve been able to fully reproduce and debug this issue locally.

This problem is not related to app permissions, Google Play, or user code. The root cause is in how the Road map component fetches OpenStreetMap tiles.

The Road map uses OpenStreetMap tiles via an internal map library. Since around September 2025, the OpenStreetMap tile server (tile.openstreetmap.org) changed its behavior and now responds with HTTP redirects. The version of the map library currently used by App Inventor does not follow these redirects, so tile downloads fail silently and the map appears blank (grey background).

This explains why:

• Apps worked for years and suddenly broke without any app update
• Only Road maps are affected (Aerial/Terrain still work)
• Switching from Aerial → Road often results in a blank map
• Play Store vs APK installs appeared inconsistent

I tested a fix that bypasses the redirect entirely by using OpenStreetMap’s load-balanced tile endpoints directly. With this change:

• Road maps render correctly again
• Switching map types works reliably
• Previously published apps start working again once rebuilt

I’m preparing a pull request to App Inventor with this fix so it can be included upstream.

Thanks to everyone who reported logs and symptoms — they were very helpful in tracking this down.

[Django_s_Android_App]

You are right!
I managed to get 8 Map Types working in my DjMaps extension ( update not released yet)
code snippet:

@SimpleFunction(description = "Change the map style. Choose from 8 different providers.")
    public void SetMapType(@Options(DjMapType.class) int mapTypeInt) {
        if (mapView == null) return;

        Configuration.getInstance().setUserAgentValue(context.getPackageName());
        DjMapType mapType = DjMapType.fromUnderlyingValue(mapTypeInt);
        ITileSource tileSource = null;

        switch (mapType) {
            case Mapnik:
                tileSource = TileSourceFactory.MAPNIK;
                break;
            case Satellite: 
                tileSource = TileSourceFactory.USGS_SAT; break;
            case CartoVoyager:
                tileSource = new XYTileSource("CartoVoyager", 0, 19, 256, ".png", 
                    new String[]{"https://a.basemaps.cartocdn.com/rastertiles/voyager/", "https://b.basemaps.cartocdn.com/rastertiles/voyager/"});
                break;
            case OpenTopoMap:
                tileSource = new XYTileSource("OpenTopoMap", 0, 17, 256, ".png", 
                    new String[]{"https://a.tile.opentopomap.org/", "https://b.tile.opentopomap.org/"});
                break;
            case USGSTopo:
                tileSource = TileSourceFactory.USGS_TOPO;
                break;
            case PublicTransport:
                tileSource = new XYTileSource("PublicTransport", 0, 18, 256, ".png", 
                    new String[]{"https://tile.memomaps.de/tilegen/"});
                break;
            case Cyclosm:
                tileSource = new XYTileSource("Cyclosm", 0, 18, 256, ".png", 
                    new String[]{"https://a.tile-cyclosm.openstreetmap.fr/cyclosm/"});
                break;
            case OpenSeaMap:
                tileSource = new XYTileSource("OpenSeaMap", 0, 18, 256, ".png", 
                    new String[]{"https://tiles.openseamap.org/seamark/"});
                break;
            default:
                tileSource = TileSourceFactory.MAPNIK;
                break;
        }

        if (tileSource != null) {
            mapView.setTileSource(tileSource);
            mapView.invalidate();
        }
    }

[Akash_Gite]

Thanks for confirming
This aligns well with what I found while debugging App Inventor’s Road map issue.

Your extension works because it uses direct XYTileSource endpoints that avoid the redirect behavior introduced on tile.openstreetmap.org. The fix I’m preparing applies the same idea inside App Inventor’s core Map component so existing projects work again without requiring custom extensions.

Appreciate you sharing the snippet — it helped validate the root cause.

[ewpatton]

The MAPNIK entry in osmdroid does declare the use of the a, b, c tile servers, so your analysis isn't entirely accurate. The real issue is that it uses http: URLs which now direct to https:, and that's where the redirection failure comes from.

[Akash_Gite]

Thanks for the clarification — that makes sense.

You’re right that MAPNIK already defines the a/b/c tile servers, and the core issue is the use of http URLs that now redirect to https, which the current osmdroid version doesn’t follow.

My initial investigation focused on the observable failure mode (tiles not loading due to redirects), and the fix intentionally avoids the redirect path by explicitly using HTTPS tile endpoints. With this change in place, Road tiles render correctly again and switching between map types is reliable.

I’ve verified the behavior locally in both the Companion and a compiled APK. Let me know if you’d prefer adjusting this to reuse MAPNIK with enforced HTTPS instead, or if the current approach looks acceptable.

Appreciate the insight — it helped tighten the root cause explanation.

[maiwolf]

Many thanks to all of you.
For all the ideas and the fix of the issue.
When can a "normal" user benefit from the fixed map component? Will this be in the next release?
And when could I use it in the MIT App Inventor offline version?

[SteveJG]

@maiwolf

when could I use it in the MIT App Inventor offline version?

offline versions of App Inventor are made by third party vendors. You might ask them; they frequently update their software soon after a version of App Inventor is updated.

[ewpatton]

The fix you are looking for is available on ai2-test.appinventor.mit.edu for testing. There is a separate companion you will need to download from the Companion Information dialog. Alternatively, if you connect an older companion, it will prompt you to upgrade.

[maiwolf]

Using a little test app (just a map component and buttons to change the map_type) I can confirm, that the map component works in the test-environment. One can switch the map-type back and forth and the road map is showing again. Just the “aerial” and the “terrain” tiles are not highly resolved in Europe.
Thanks for the quick fix.

[ewpatton]

The aerial/terrain tiles are provided by the USGS, so the quality outside of the US does not surprise me.

[SteveJG]

This is not an USGS issue @ewpatton

Problema di zoom con componente MAP

There is no problem, what you experience is a feature of OSM. You can use the Google Maps Static API instead of the Map control. 1 - the Map component uses OpenStreetMap tiles, not Google Map tiles. 2 - the tiles are based on USGS surveys in the USA and other sources outside the USA. The ability to zoom tiles depends on the map base. Outside the USA the maps are not as detailed so users cannot zoom the maps as in the USA, especially when using Terrain and Aerial MapType. Us…

@SteveJG

the tiles are based on USGS surveys in the USA and other sources outside the USA. The ability to zoom tiles depends on the map base. Outside the USA the maps are not as detailed so users cannot zoom the maps as in the USA, especially when using Terrain and Aerial MapType. Users can zoom the most using Roads. See Map组件中roads类型地图无法显示 - Roads type map in Map component cannot be displayed (in Mainland China) - #4 by SteveJG

[ewpatton]

I'm not sure what you're trying to claim with those posts @SteveJG. OpenStreetMap is only used as the tile provider for the Road map type. The other two types use a tile provider hosted by USGS. Of course, now that we have the Custom option people can provide their own tile provider URL so long as the provider offers the tiles in the WebMercator projection.

[SteveJG]

@ewpatton

The aerial/terrain tiles are provided by the USGS, so the quality outside of the US does not surprise me

Tiles come from various services. When a Map zoom is 8+ or so for some regions (Europe etc), Aerial and Terrain tiles become probable because the USGS does not have a licensed version. Higher zooms in these case become pixelated since a higher resolution image is not available (on the USGS server).

@maiwolf

Just the “aerial” and the “terrain” tiles are not highly resolved in Europe.

The maps for these versions of map tiles are based on quality USGS Quadrangle maps and other images for the USA and some other regions. The images in Europe come from various other sources. Many aerial/ terrain tile images outside the US at these resolution (8+ zoom) are based on aerial photographs and instead of showing additional resolution are pixelated versions of the best data USGAS has available).

@ewpatton

Of course, now that we have the Custom option people can provide their own tile provider URL so long as the provider offers the tiles in the WebMercator projection.

This?

Feature is not available using Blocks.so it doesn't show this info to users when using tooltips

It would help to have the clarifier " offers the tiles in the WebMercator projection.' thanks
(see Maps custom

Does an example exist?

[ewpatton]

@SteveJG

This?

Feature is not available using Blocks.so it doesn't show this info to users when using tooltips

It would help to have the clarifier " offers the tiles in the WebMercator projection.' thanks
(see Maps custom

Does an example exist?

There is now a CustomUrl property in the blocks to switch the URL. Here's a test app that uses OpenTopoMap as an alternative topology layer:
MapLayerTest.aia (2.2 KB)

Yes, I agree the documentation could be improved on this front.