We received reports from users about Mapsforge native crash with Skia on Android 6.

Devices:

• Motorola Droid Maxx 2
• Motorola Moto G (2nd gen)
• Motorola Moto G (3rd gen)
• Motorola Moto X Play
• Motorola Moto E (2nd gen)

Report: "as soon as you move on the map app crashes. only happened after upgrading to Marshmallow".

backtrace:
#00 pc 001febe8 /system/lib/libskia.so (NofilterDXExecutionBuffer565::GenerateUpscaleProgram(int, int, int, int)+128)
#01 pc 001ff604 /system/lib/libskia.so (NofilterDXExecutionBuffer565::GenerateProgram(int, int, int, int)+132)
#02 pc 001ff704 /system/lib/libskia.so (NfDXEB565Cache::prepareShaderProc32(int, int, int, int)+232)
#03 pc 001fd4b0 /system/lib/libskia.so (SkBitmapProcState::beginRect(int, int, int)+336)
#04 pc 001fdcb4 /system/lib/libskia.so (SkARGB32_Shader_Blitter::blitRect(int, int, int, int)+1568)
#05 pc 0011ec33 /system/lib/libskia.so
#06 pc 0011ecfb /system/lib/libskia.so (SkScan::FillIRect(SkIRect const&, SkRegion const*, SkBlitter*)+194)
#07 pc 0011edc5 /system/lib/libskia.so (SkScan::FillRect(SkRect const&, SkRegion const*, SkBlitter*)+138)
#08 pc 0011eeb5 /system/lib/libskia.so (SkScan::FillRect(SkRect const&, SkRasterClip const&, SkBlitter*)+56)
#09 pc 000f9f83 /system/lib/libskia.so (SkDraw::drawRect(SkRect const&, SkPaint const&, SkMatrix const*, SkRect const*) const+522)
#10 pc 000fb5db /system/lib/libskia.so (SkDraw::drawBitmap(SkBitmap const&, SkMatrix const&, SkRect const*, SkPaint const&) const+452)
#11 pc 000f2d19 /system/lib/libskia.so
#12 pc 000f2e29 /system/lib/libskia.so (SkCanvas::onDrawBitmap(SkBitmap const&, float, float, SkPaint const*)+184)
#13 pc 00051edf /system/lib/libhwui.so
#14 pc 0008a617 /system/lib/libandroid_runtime.so
#15 pc 02a64181 /system/framework/arm/boot.oat (offset 0x1fde000)

The new multi-threaded renderer does not play well with labels/icons across tile borders.

For the original discussion see: https://groups.google.com/forum/?utm_medium=email&utm_source=footer#!msg/mapsforge-dev/x19w0iPealM/K3SgbhwdcowJ

From [email protected] on June 01, 2012 19:10:24

Related: Issue 127 ( https://code.google.com/p/mapsforge/issues/detail?id=127 )

There are still version 0.3.0 map files for some European countries missing on the ftp server. On first glance I found Denmark and Belgium missing. There might be more. I guess this is not high priority, but as developers are starting to transition away from 0.2.4 it would be nice to have them all.

Original issue: http://code.google.com/p/mapsforge/issues/detail?id=320

As agreed with @devemux86 in https://groups.google.com/g/mapsforge-dev/c/4LcJL93sa14:

This is a PR to introduce scoped storage support also for resource provisioning into mapsforge.

MapsForgeViewer is adapted as well to give usage examples.

The language matcher in OSMUtils.java only handles the alpha-2 code of ISO 639-1:

private static final Pattern NAME_LANGUAGE_PATTERN = Pattern.compile("(name)(:)([a-z]{2})");

However, I've found language specifiers in OSM data which contain more than two characters... e.g.

    <tag k="name:zh-py" v="Gāoxióng Shì"/>

In the OpenStreetMaps wiki, there is also an example

name:ko_rm=Mweonga (the name in Romanised Korean)

which is later corrected to

name:ko_Latn=Mweonga

The pattern matcher should just allow arbitrary characters. I would rewrite it myself, but I am not very good with regular expressions.

The new label layer shows a peculiar behavior ...

That's the result with the label layer (only a few house numbers):

And this is the result without the label layer (nearly all (but not all) house numbers are visible):

And this is the situation in OSM: http://www.openstreetmap.org/#map=19/51.96395/7.63848

The problem occurs with Cruiser (1.4.0 - 20160130) and with Atlas (1.2.0-20160130).

Klaus

In the attached bitmap, which is in Berlin, Germany, a tunnel is missing. The upper rendering is with Atlas Beta, using the latest Berlin map downloaded from the mapsforge server. The bottom rendering is from openstreetmap.org. Notice in the bottom rendering, there is a tunnel labeled "Tunnel Ortsteil Britz." It is missing from the Mapsforge rendering. I have not yet investigated whether it is an issue with missing data or with the built-in OSMARENDER theme, pending finding out if this is a known issue or not.

Regarding DatabaseRenderer:

• the purpose is to render tiles
• in the context of a visible map
• being called by an instance of MapWorkerPool

But that doesn't match a slightly different way of seeing things: a simple "give me that tile". Because DatabaseRenderer:

• interacts with MapWorkerPool so that it forces a display refresh (MapWorkerPool.this.layer.requestRedraw();), that we don't want here
• includes some optimizations, like not writing twice the same label (cf. Set<MapElementContainer> undrawableElements), that provokes side-effects (cf. https://github.com/osmdroid/osmdroid/issues/1145)
• in this last case, potentially because of a bug - as elements are never removed from tileDependencies except in MapWorkerPool, that we don't want to use because of the display refresh

My suggestion is to create a dedicated class that extends StandardRenderer. The purpose is to have the same level of quality as DatabaseRenderer, but in a simpler context where we will avoid side-effects. The name will be something like DirectRenderer.

To enable it, all the mapsforge account owner needs to do it log in on https://travis-ci.org and flip the enable switch for the mapsforge repository.

In a future update, we could add other forms of notifications. Currently, it notifies via GitHub (very convenient!) and I think email.

A preview can be seen on my account: https://travis-ci.org/schildbach/mapsforge If you want to try out how pull requests work, just open a PR against my GitHub repo and you'll see the Travis integration.

It is a common occurrence to get a warning message from this block in MapFile.java:

        if (numberOfWayNodes < 2 || numberOfWayNodes > Short.MAX_VALUE) {
            LOGGER.warning("invalid number of way nodes: " + numberOfWayNodes);
            // returning null here will actually leave the tile blank as the
            // position on the ReadBuffer will not be advanced correctly. However,
            // it will not crash the app.
            return null;
        }

with numberOfWayNodes == 0. I'm guessing it's a bug in the map writer. An example is in japan.map, in the block where z=4,x=13,y=6

Includes improvements discussed with Emux and Ludwig:

• Read entire cache dir when initializing a persistent cache
• Reliably enforce cache size for persistent cache (data from previous instances is now included in the count)
• Fixed NPE which occasionally occurred in FileSystemTileCache#containsKey() when persistence was enabled
• Added test case for persistent tile cache
• Added missing compatibility constructors and helper methods for apps migrating from 0.5.0
• Use file timestamp to determine age of map file
• Changed TTL to TimeToLive in identifiers
• Comment for default TTL (86400000 millis = 1 day)
• Changed default Mapnik TTL to 8279s (current OSM setting) and added comment

As mentioned before, in order to enforce cache size (and also to fix the NPE Ludwig found) I now examine the entire cache dir when the cache is initialized and enter anything I find there in the lruCache. This might affect startup performance if the cache dir holds a large number of files.