First a note, it seems as if I never blogged about the 10.1 update, information on those changes can be found in the release notes on the Vespucci website.

The beta release of 10.2 that is now available in the beta channel on the google play store, or from the releases on github does not change an awful lot that is end user visible outside of a new upload UI, however there are two core changes that I want to touch on quickly.

Support for “network” location providers

Historically Vespucci has only supported using the on-device GPS location provider, or nothing at all. That meant that you were unable to get a rough location approximation on devices that didn’t have onboard GPS, or that had GPS disabled for example to reduce power requirements. The main reason for this is that on the one hand we wanted to avoid location information potentially tainted by your devices Android provider and avoid our users position being tracked by them.

We now support using so-called “network” location providers, that is location sources that derive your position from the mobile network, WLAN and other signals your device is receiving. If you’ve enabled such providers on your phone, more on that later, Vespucci will use all available providers for centering the map display on your position and for auto-downloads, tracks will still exclusively be generated from GPS data.

The change in opinion is mainly due to less and less people caring about such matters and at least google tracking in any case (see for example https://www.theverge.com/2017/11/21/16684818/google-location-tracking-cell-tower-data-android-os-firebase-privacy), further allowing such providers enables better indoor positioning which is a clear advantage.

If Vespucci detects that network positions can at least potentially be used, it will display this icon instead of the classic GPS icon on the screen and will alert you to which provider it is currently using via toasts (the short on-screen messages).

Modern devices running a google variant of Android have three location mode setting (besides turning location services completely off):

• Device only - use only the on device GPS location information, does not require sharing your location data with google
• Battery saving - doesn’t use GPS, instead uses mobile network, WLAN and other signals to determine your location, requires sharing of your location data with google
• High accuracy - uses GPS and other signals to determine your location, requires sharing of your location data with google, this is typically only more “accurate” than Device only if receiving GPS signals is seriously impaired

Vespucci does not use the Google play servers “fused” location service and remains usable independent of if you are running it in a Google sanctioned environment or not.

Better https support

Given the push for more and more services on the Internet to be accessible only via encrypted transport (https) Android apps are faced with two challenges:

• the standard Java API for accessing http services does not support protocol level redirects, that is http to https or the other way around this is not difficult to work around but would still require codes changes at every impacted place in the code
• more and more sites are turning off TLS 1.0 support for security reasons, unluckily TLS 1.1 and 1.2 are only supported from Android 4.1 on and are only enabled by default since 4.4, again addressing this requires touching all the same code as above

In the end I decided to address these issues by migrating all the networking code to OkHttp that we’ve already been using for some things, for example for map tile retrieval since 10.1. As OkHttp exposes a different programming model and it didn’t require massive changes, it wasn’t a drop in replacement and we appreciate all feedback on the changes as some aspects of the networking code are difficult to test automatically.

Two notes:

• yes this means that users with devices running Android 4.0 and older are not able to access any services that have turned off TLS 1.0, for example you will not be able to update the imagery configuration on the fly from github.
• modern Android versions actually use OkHttp under the hood wrapped in code that emulates the standard Java API, so we are not doing anything particularly exotic.