Required changes to adhere to Google Location Permissions policy

[WGrobler]

In February, Google announced privacy updates to their Location Permissions policy that will limit which apps are allowed to use background location data. This policy will impact the Traccar client app.

Without the changes the Traccar Client app will have problems on Google Play Store. The new policy change required the following to allow background location permission.

Prominent disclosure needed before location runtime permission Your app must display a prominent disclosure through a pop-up alert before your app’s location runtime permission. Remember, your prominent disclosure must: Appear before your app’s location runtime permission. Include at least the following sentence, adapted to include all the relevant features requesting access to location in the background in the app that are readily visible to the user: “This app collects location data to enable ["feature"], ["feature"], & ["feature"] even when the app is closed or not in use.” Include any other details necessary to make it clear to the user how and why you are using location in the background. While additional content is permitted, it should not cause the required content to not be immediately visible. Include the following sentence, if you extend permitted usage to ads: “This data is also used to provide ads.”

I'm not sure if the feature request is the best place to add this. But I wanted to make sure the community is aware of this

[tananaev]

We are aware of this, thanks. Actually in most cases Traccar Client uses foreground service, so it doesn't apply, as far as I understand. But there is an option to run as a regular service as well, so we need to implement it.

[WGrobler]

I am glad to hear that you are indeed aware. From what I can gather, Google is focusing on apps that require the "access location in the background" permission. According to the play store this is currently required by Traccar Client.

From what I understand Google is not preventing background location access altogether. They only require that the developer be granted an exception. An exception can be filled from within the developer console. I think the only change required is a popup explaining why the location access is required. This popup must run before the location access is requested. Perhaps the app can display a message when the app is started the first time.

[mecoFarid]

@tananaev Please, bear in mind tha there is a limitation that totally destroys business logic of the client app. Quote can be found here Android Docs on Background Location

In an effort to reduce power consumption, Android 8.0 (API level 26) limits how frequently an app can retrieve the user's current location while the app is running in the background. Under these conditions, apps can receive location updates only a few times each hour.

[tananaev]

@mecoFarid that's why we use foreground service and not a background location.

[WGrobler]

The issue of foreground service confused me when @tananaev first commented on my original post. Since the app is running in the background I thought the "background tracking" changes applied; but only after further research I understood that it is something different.

Since the app is using "foreground services", I agree that the current version should not be effected by any of the rule changes as per my original post or the issue raised by @mecoFarid.

The permissions (on the Play store) of the previous versions did include background locations access, it was not used in the app but it was still showing on the Play store page and thus subjected to the rule changes as per my original post. The latest version of Traccar no longer require any background permissions and therefore should adhere to the latest Google Policy Changes. For this reason the ticket can be closed. A new ticket can be opened if further policy updates require app changes.

[tananaev]

Just to provide context on why we had the permission. I think at one point we had (or intended to have) an option to disable foreground service, so we needed it. It no longer makes sense, but the permissions wasn't removed until now.