OpenStreetMap does not display on Androids 5 and higher

[mmarciniak90]

Software and hardware versions

Collect - current master
Android v5.1 and higher

Problem description

Problem with OpenStreetMap returned
OpenStreetMap does not display when using Geo widgets.
#3248

Steps to reproduce the problem

1. Choose in General Settings Maps/OpenStreetMap
2. Open Geopoint/GeoTrace/GeoShape widget
3. Click on the Start button

Expected behavior

OpenStreetMap should load.

[grzesiek2010]

The problem is caused by this change 1a7cbe7

TestCollect class is in debug so it doesn't setUserAgentValue because it overrides the method from Collect class.

@seadowg what was the problem with tests that you implemented those changes?

I'm not sure what we should do in this case we need to setUserAgentValue for testing so we can:

• revert those changes if the problem with tests wasn't serious
• add a separate build variant just for tests and override setupOSMDroid() there
• try to implement a check that would detect whether the code is used by tests and do nothing then

what do you think? @seadowg @lognaturel

[seadowg]

Calling setUserAgentString would give us a pretty nasty exception at the top of any test's output (if running with Robolectric). I went back and ran it again:

SLF4J: No SLF4J providers were found.
SLF4J: Defaulting to no-operation (NOP) logger implementation
SLF4J: See http://www.slf4j.org/codes.html#noProviders for further details.
SLF4J: Class path contains SLF4J bindings targeting slf4j-api versions prior to 1.8.
SLF4J: Ignoring binding found at [jar:file:/Users/seadowg/.gradle/caches/transforms-2/files-2.1/de8b5579323c1b33c12b7909cd249a7c/jars/classes.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: See http://www.slf4j.org/codes.html#ignoredBindings for an explanation.
java.io.FileNotFoundException: /proc/mounts (No such file or directory)
	at java.io.FileInputStream.open0(Native Method)
	at java.io.FileInputStream.open(FileInputStream.java:195)
	at java.io.FileInputStream.<init>(FileInputStream.java:138)
	at java.io.FileInputStream.<init>(FileInputStream.java:93)
	at java.io.FileReader.<init>(FileReader.java:58)
	at org.osmdroid.tileprovider.util.StorageUtils.getStorageList(StorageUtils.java:148)
	at org.osmdroid.tileprovider.util.StorageUtils.getStorage(StorageUtils.java:232)
	at org.osmdroid.config.DefaultConfigurationProvider.<init>(DefaultConfigurationProvider.java:69)
	at org.osmdroid.config.Configuration.getInstance(Configuration.java:23)
	at org.odk.collect.android.application.Collect.setupOSMDroid(Collect.java:291)
	at org.odk.collect.android.application.Collect.onCreate(Collect.java:287)
	at org.robolectric.android.internal.AndroidTestEnvironment.lambda$installAndCreateApplication$0(AndroidTestEnvironment.java:276)
	at org.robolectric.util.PerfStatsCollector.measure(PerfStatsCollector.java:75)
	at org.robolectric.android.internal.AndroidTestEnvironment.installAndCreateApplication(AndroidTestEnvironment.java:276)
	at org.robolectric.android.internal.AndroidTestEnvironment.setUpApplicationState(AndroidTestEnvironment.java:169)
	at org.robolectric.RobolectricTestRunner.beforeTest(RobolectricTestRunner.java:301)
	at org.robolectric.internal.SandboxTestRunner$2.lambda$evaluate$0(SandboxTestRunner.java:243)
	at org.robolectric.internal.bytecode.Sandbox.lambda$runOnMainThread$0(Sandbox.java:89)
	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
	at java.lang.Thread.run(Thread.java:748)

My understanding is that calling into OSM outside of a real device/emulator would a no no due to it loading native frameworks.

What I didn't realize when I made this change is that we use TestCollect in the debug build of our app - I had wrongly assumed we were just using Robolectric's automagic Test prefix to have it loaded in tests but as you point out we actually reference the class in our debug build's AndroidManifest.xml as well. Is there a reason we want this class to be used in debug builds and not just our normal Collect application? If not we can just remove that reference from the manifest and continue to use TestCollect but just for Robolectric.

EDIT: In fact it looks like we're disabling leak canary in that test application? Surely we want this in debug buiilds if we want it at all?

[grzesiek2010]

Ok I created a pr #3370 which removes TestCollect class from manifest file in debug. According to the comment the class will be automatically used for tests.

in fact it looks like we're disabling leak canary in that test application? Surely we want this in debug buiilds if we want it at all?

I don't know but looks as if it should be enabled for debug build.