cell-based geolocation issue on some Android ≤ 4.1 devices

[IzzySoft]

Thanks again for making it available for 4.1 – but now I found a minor "incident" with that. There's a method referenced not available before Android 4.2 concerning cell-based geolocation (for details, see this issue for the Mozilla backend).

You can find a stack-trace here at pastebin.com for what's happening. Seems not to be that crucial, though, as a location is still found:

I/org.openbmap.unifiedNlp.Geocoder.OnlineProvider(11635): JSON response: {"source":"wifis","accuracy":30,"location":{"lng":11.570856997514667,"lat":48.166475879909996},"measurements":104}

A solution would be an additional option in the module's settings to discable cell-based location. E.g.

[ ] use cell-based location (4.2+) [x] use WiFi based location

and initially disable the first option on lower Android versions, but still give the user the chance to check it on "own risk", as some 4.1 devices indeed seem to support it – if I understood Marvin correctly:

Using gsm cells to geolocate is not possible on Android version 4.1 and below because of missing API support on most devices.

(emphasis mine).

---

I'm still jumping between the different projects here at Github with my issues "mixing things up": Though OBM finds a location, UnifiedNlp doesn't seem to pick it up – but reports the Google location instead (details in the linked issue; and yes, I do have the Xposed UnifiedNlp module installed and loaded – as in all my tests, it reports having found a location, but it's not a UnifiedNlp one) … Or could it be your module doesn't "hand it through" here? The above line is the only proof I have OBM found a location – and after all it only reports "JSON response", not "location found".

Ah, yuck: See a longer excerpt at this pastebin: Looks like after finding the location, it simply crashes :(

java.lang.NoSuchMethodError: android.location.Location.getElapsedRealtimeNanos

DeviceInfo: This time a tablet running stock 4.1.2, so no cell module/SIM (if you need closer info on the device, just let me know).

[wish7code]

Sorry for my late reply.. Been very busy lately.. I'll fix this with the next release..

[IzzySoft]

Great, thanks a lot – looking forward to that! And my full sympathy for the timing, I know exactly what you're talking about (same here most of the time).

[mvglasow]

As for Marvin's comment, I would assume he is talking about a specific solution, not a generic Android constraint:

Cell-based geolocation has two steps: getting IDs of nearby cells and then translating them into a location. The second part is entirely up to the location provider – getting cell IDs is the part which relies on Android support.

Getting cell IDs in Android is indeed tricky:

• There are three different calls to do that, each implemented in different API versions. One of them is indeed API 17 (= Android 4.2), but the other two are available in earlier versions.
• Implementation of these methods varies between vendors, even on multi-vendor distros such as CyanogenMod. Some calls may not be implemented at all (and will never return any results). Those which are implemented will only return a partial set of cells (which may differ between calls), and/or will just return a partial set of data. Some of these are likely constraints of the proprietary drivers or even of the radio firmware.
• Only one of the three calls has (in theory) a reliable way to identify cell technology (GSM, UMTS or LTE, or any of their variations). With the other two, your best guess is to query the current technology and infer from that the technology of all serving cells, though there is a slight delay between a change in the serving cell and a change in cell technology.
• Thus the only somewhat reliable method is to use results from all three calls (depending on platform support) and merge them. Still, you're going to be somewhat limited on some devices. For instance, Samsung-built devices are infamous for not returning the PSC of the cell, or anything beyond the serving cell.

I came across a bunch of those in SatStat, and I'm still having issues detecting technology changes between UMTS and LTE. On the other hand, getting just the ID of the serving cell should be possible on all Android versions (at least as long it is GSM or a successor of it), and would allow geolocation with the accuracy of a cell coverage range.

[mvglasow]

I just extended my fork of the backend to use all three methods. Internally, this has the side effect of querying duplicate cells – this is definitely not an issue in offline mode, not sure about online mode (probably OK as well, but maybe @wish7code can shed some more light on this).

I'm going to add a check for the API level; after that querying cells should work on versions prior to Jelly Bean MR1. Just need to remove the logic that artificially disables it on prior versions.

[IzzySoft]

Sorry for not having responded. I cannot verify this anymore, as my devices meanwhile run newer Android versions. Thanks though!