Data Safety & Privacy Declaration
Why Privacy Declaration at GooglePlay is what it is


I take the protection of your personal data very seriously and treat personal data with the utmost care, confidentiality and in accordance with the legal data protection regulations and this data protection declaration.

Processing operations

GPSLogger II processes personal data only if they are necessary for the app functions. The data will be saved on your mobile device only.

How credible is this statement?

On the one side I claim as developer that I take your privacy as my highest priority and that all data will be stored only on your device. On the other hand the Data Safety declaration at GooglePlay lists that location information (and more) will be collected and processed.

I totally understand that this raises concerns, and I would like to explain in detail the reasons why I have selected, what I have selected in Google’s Data Safty declaration form.

Just as a reference - here is the current GooglePlay Data safety declaration of GPSLogger II:


GPSLogger Data safety Declaration at Google Play explained

How does this declaration match with the statement, that GPSLogger will only record the location on the device?

taking a deep breath

None of the points that are listed in the Data Safety Declaration at GooglePlay are relevant for the core use case of GPSLogger.

The problem is, we are dealing with Google here. They are analysing the code of your app for potential issues and once it’s flagged by a machine as suspicious the app will be removed from the store. Once thats happened, the Developer gets informed that your app is not compliant with something and that you should fix it and submit your app again.

Here is the key problem, you’re either dealing with bots/machines and/or low paid (and as a consequence low trained & skilled) support staff. It’s impossible to get qualified information about what part of the app code has been identified as suspicious.

In such a case you as developer has to guess, if there should be additional information provided to the users, if there is anything in the application description that has to be adjusted or if it’s really a functionality (code) that needs to be adjusted.

I have a long history of trying to communicate with the Google Developer support, and I don’t want to waste my life any further with them. GooglePlay Store has a de facto monopoly for Android app distribution and, that there is no neutral control instance (that you can call in the case of a dispute) is IMHO a serious issue for us all. In the end Google is going to decide what apps will be available and which will not.

So the approach of the Data Safety Declaration of GPSLogger is, to be as open as possible. As soon as there is a tiny little section in the app that might be detected as data will be transferred from the app to a server to be processed - it is better to declare it, instead of hoping to be lucky with the monkey army. Since once you get caught, it’s impossible to get out of Google’s claw.

As a quick example - when you use the TurnByTurn Navigation and you are leaving for what ever reason the initial planned route the app is able to find a detour for you. Therefore, the app is using your current (precise) location and sends a request to in order to be able to guide you back to your initially planed route. Will openrouteservice store your current location - NO - will it process your location data - well - YES it does. So it has to be declared.

For me, it’s almost impossible to judge what processing means in the legal context for Google. For sure, your location information has to be used in order to find a possible way from A to B. Your location will not be stored, processed or analyzed any further! (there is no server side statistic for locations where people are missing turns most often).

So at the end of the day I decided, it would be better for my mental health to declare every piece of possible external data processing to Google and try to explain here in the manual the reasons (functionalities) where and how this data will be processed.

If you have any concerns - please let me know!

So let’s go through the list step by step

perm_device_information Collected data - Device or other identifiers

GPSLogger itself does not have, store or use any internal (or external) ID at any point1. GPSLogger does not collect any usage data by itself - nor I as Developer (within the best of my knowledge) have integrated any code, that does collect any kind of data.

Having said all that, the app is running under the Android OS. So what ever the OS does (collect, transfer and/or process) is beyond the control of GPSLogger. And before Google has removed the app, because of the OS transfer in the name of my app data, and I did not declare it, I feel much more comfortable declaring it - just in case.

place Collected data - Approximate & Precise location

Let’s start with the fact that I don’t understand, why an app that is processing Precise location data can declare additionally, that Approximate location data will be processed. My understanding is, that when I process Precise location data this implies that I process also Approximate location information. So at the end of the day I have selected both - simply because I don’t have a single clue what’s going on in Google’s lawyers minds.

So the bottom line here is, GPSLogger is processing always Precise location data.

In general - the location information recorded by GPSLogger will remain on the device ONLY. Nevertheless, when you use of the following functions, your location (does not have to be your current location) will leave your device and can be processed by a 3rd party. In some cases it is impossible to say if the data will be processed or not - in some cases you can be sure it will (e.g. when uploading to Strava).

Live Location Sharing (including custom URL & TASKER)

When using the Live Location Sharing function, your current location will be transferred either as eMail via the internet to the selected eMail recipient or will be sent via the internet to the server URL you have specified.

It’s recommended to use encrypted eMail transfer and/or make use of HTTPS in the custom URL.

See also: Live Location Sharing manual section

Emergency Alert

When using the Emergency Alert function, your current last known location (and path) will be transferred as eMail via the internet to the selected eMail recipient. It’s recommended to use encrypted eMail transfer.

See also: Emergency Alert manual section

Exports (as eMail)

When using the export options (KML, FIT, GPX or CSV), the location (and additional sensor) data will be stored in the selected format on your local device only. Once the data is stored in the file system it’s beyond the control of the app what will happen with this data - Please use these export files wisely.

When you make use of the eMail Export options the data will be directly sent over the internet to your configured eMail account. It’s recommended to use encrypted eMail transfer.

See also: Export & eMail manual section

Routing Request / Online Navigation

When using the On the fly navigation/detour functionality, your current & target location will be transferred via the internet to the server. When using the Openrouteservice, the privacy policy applies.

See also: Turn-by-Turn Navigation manual section

Import from Routing Server, planned @

When using the Import from Routing Server functionality, your current location will be transferred via the internet to ther server in order to search for routes that have been created in the last 5min in your area. The location data that will be sent, will not be stored on server and be only used for processing the request. When using the Push-Route functionality from the website, the privacy policy applies.

See also: Plan a Route manual section

Share Path via

When using the Share Path functionality, the complete path (date, location) will be transferred via the internet to the server and will be made available to the PUBLIC. Everyone who knows the provided shared URL can see this location data over the internet. When you share a path, there will be no connection between you (the user) or the device used for the upload - so the upload does not contain any additional personalized data. When using this functionality, the privacy policy applies.

See also: Share your Path with the public manual section

Upload Activity to Strava

When using the Upload to Strava function, the recorded location (and additional sensor) data is transferred via the internet to the Strava servers. When using Strava, the Strava privacy policy applies.

See also: Strava Integration manual section

Map Tile Data

When using the OpenMapData functionality (basically the Map View), the corresponding privacy policies of the selected map data providers applies. GPSLogger II will request map tiles from the selected providers and this implies that this requests contain area information (BoundingBox) which might be (but doesn’t have to be) in relation to your location.

See also: Open Map Data (OMD) manual section

https Data is encrypted in transit

For all communication that are under the control of GPSLogger HTTPS is always used (this implies the communication to,, or Google’s O-Auth service).

Nevertheless, there are some areas in the application that allow you to specify custom/own URLs and links. It’s the users’ responsibility to take appropriate actions to protect their data. Specifically: If you make use of the live share location functionality via your own backend/URL it’s STRONGLY recommended to use HTTPS URLs ONLY!

delete Security practices - Data can be deleted by request

There is only a single functionality where data will be stored at a different place that is not under the control of the user by themselves. This is the _Share via feature, where the user can upload a path to the server in order to share this path with the public. It’s important to understand, that the data that is stored at does not contain any device or user identifier, the only reference is a UUID that will be stored together with the path locally on the device of the user. It’s impossible to backtrace the origin of a path with just the UUID.

When you want to delete a previously shared path - simply use the built in Remove Share from that is accessible for every path within the PathManager.

For more details about how to remove your data please see: Share your Path with the public manual section

Right of revocation

By revoking the privacy policy of GPSLogger II, the app is not functional and therefore cannot be used. Deletion of your personal data, GPSLogger II stores your data exclusively on the mobile device and this data can be deleted by uninstalling GPSLogger II. You must delete any created backups or export files. This backup data can be found on the device in the GPSLogger II folder of your Downloads.

  1. In the past the app has used a random internal UUID - this ID has been removed with the update to v2.0.0.206 (any existing UUID data has been deleted from the device during the update). 

Version: 2023/03/19