Integration graphhopper in android with mapforge

devemux86 · September 3, 2021, 7:50am

GraphHopper cannot work with Android scoped storage,
which requires file streams and not file paths.

GraphHopper focus now seems to be the online routing:

github.com/graphhopper/graphhopper

Future of 'Offline' Routing

opened 05:16PM - 28 Feb 20 UTC

closed 12:26PM - 10 Jul 20 UTC

karussell

android ios

The current state of routing on mobile devices (iOS & Android) without internet …access (aka "offline routing") is suboptimal: * The Android support is "okayish", but for a meaningful usage we could need [graph merging](https://github.com/graphhopper/graphhopper/issues/293) or a tiled approach to allow cross-graph routes and a fix for [a strange, per-process virtual memory limit](https://discuss.graphhopper.com/t/spatial-limitation-in-android-offline-on-device/298/13?u=karussell) to allow loading big graphs too e.g. a native DataAccess or file cache approach. There is also still no CI integration for Android, see #803. * Since several releases there is no update of our [iOS port](https://github.com/graphhopper/graphhopper-ios/). Here all the limitations of the [j2objc library](https://github.com/google/j2objc) apply, but it worked surprisingly well and even supports several Java 11 features and without any artificial virtual memory limitation. **Update**: see this new issue: https://github.com/graphhopper/graphhopper-ios/issues/46 * For both platforms we do not have the public transit module as only the core is limited to Java 7. I am really happy that despite these limitations I know there are apps in the app stores that use GraphHopper for offline routing (Android and iOS). And still, we are struggling to continue supporting this as we have to limit ourselves and avoid updating dependencies (see e.g. #1803), stick to Java 7 in the core and also many dependency issues when it comes to Jackson and its annotations and many more design decisions that would be less complicates without "Android Java" in mind. Also there will be [inline types in Java](http://openjdk.java.net/jeps/169), which are already available as experimental feature in JDK 14, which it will be hard to avoid in the core. Previously we have accepted this and I've done lots of testing for Android myself and invested time or provided the map data and apks, but this does not make much sense as I have no real Android- or "app store"-experience. Additionally it is effort that I'm no longer willing to invest. I see the following options: 1. we abandon offline routing and embrace the latest server side Java version in GraphHopper 2. we make it worth to limit ourselves in the core (i.e. implement the missing "production" features and update the iOS port and have real community involvement for this like we already have for other things) 3. make [native GraphHopper](https://github.com/karussell/graphhopper-native-image) working for mobile devices too ([GraalVM native image](https://www.graalvm.org/docs/reference-manual/native-image/) likely combined with [Gluon tools](https://github.com/gluonhq/client-samples/)). For iOS see also https://github.com/oracle/graal/issues/373. This is currently not usable: even a simple HelloWorld is hard to compile. (could work together with option 1). See update. 4. a special Android fork of GraphHopper (suggested from @develar; could also work together with option 1) If no one steps up for contribution in this area in the next months (see for concrete tasks in option 2), then I'm afraid that we'll have to go for option 1 and drop support for Android offline routing. So, if you use GraphHopper for offline routing, now it is the right time to contribute :) ! (@devemux86, @develar, @menion, @johnpercy, @Starcommander)

An Android GraphHopper sample with Mapsforge / VTM exists here: