Google Play action required - background location access

[misaochan]

@nicolas-raoul and I received, over the weekend, more emails from the Play Store regarding non-compliance. Snippet below:

Issue found: Feature does not meet requirements for background location access
Based on our review, your declared feature does not meet the requirements for background location access.

Please remove the background location permission requested and submit an update to your app. When declaring a feature for background location access, please note the following:

Your selected feature should deliver clear value to the user and be important to the core functionality, or main purpose of the app. Without this core feature, the app is "broken" or rendered unusable.
You should also consider if users would expect the app to access their location in the background, and if you can deliver the same experience without accessing location in the background.

Oddly, both of us also looked at the manifest and could not find any mention of ACCESS_BACKGROUND_LOCATION in the manifest. Does anyone have any ideas for what the cause could be? @neslihanturan @madhurgupta10 @whym

[madhurgupta10]

@misaochan I think the permission is added automatically by Mapbox SDK

[misaochan]

Hmm, okay. By the way, there is actually another part of the email:

Issue found: Missing information in prominent disclosure
Your prominent disclosure must appear before your app’s location runtime permission, and should tell the user which feature(s) will use location in the background. Based on our review, your app’s prominent disclosure did not meet this criteria.

Based on our review, your prominent disclosure doesn’t comply with our policy requirements.The language in the disclosure MUST include the following elements:

The term “location”
Indication that the nature of usage is in the background by using one of the following phrases “background” / “when the app is closed” / “always in use” / “when the app is not in use”
A list of all the features that use location in the background
If you extend permitted usage to ads, you must include the following: “used to provide ads / support advertising / support ads.” (Choose the most accurate phrasing)
To meet the policy requirements, it’s recommended that you reference one of the following example formats, the second example includes the use of location for ads (choose the most relevant phrasing):

“[This app] collects location data to enable [“feature“], [“feature“], & [“feature“] even when the app is closed or not in use.”
“[This app] collects location data to enable [“feature“], [“feature“], & [“feature“] even when the app is closed or not in use and it is also used to support advertising.”
Example: “Fitness Funds collects location data to enable fitness tracking even when the app is closed or not in use.”

However, the way I read it, that was superseded by the "Feature does not meet requirements for background location access" issue - i.e. even if we fix the disclosure, we are still considered to not be eligible for background location access.

I guess a few different things that we can try are:

• Fixing the disclosure anyway, and explaining that Mapbox requires it? This should be fairly simple, however I'm not sure that it will solve the issue
• Creating an issue on Mapbox's GitHub to see if anyone knows a way around it - takes longer
• Appealing to Google Play and explaining that our Nearby feature in fact "deliver[s] clear value to the user and be important to the core functionality, or main purpose of the app" - might not be approved

At least it does seem like v4.0.3 managed to go out to beta regardless, as I see people using it. However, I suspect promotion to production will not be possible until we fix this.

[nicolas-raoul]

Maybe use <uses-permission android:name="android.permission.ACCESS_BACKGROUND_LOCATION" tools:node="remove" /> ? Note the remove part.
Use case from the documentation: "necessary when you discover an element in your merged manifest that you don't need, and it was provided by a lower-priority manifest file that's out of your control (such as an imported library)."

Also, maybe we should do this every time we use location?
https://developer.android.com/about/versions/oreo/background-location-limits#tuning-behavior

[nicolas-raoul]

By any chance, does LocationServiceManager or any similar class somehow survives (and maybe even run) when the app is not visible on screen?

[misaochan]

I don't think it's possible for us to implement background location checking without it being declared in the manifest, right? I wonder if perhaps the best next step is to try <uses-permission android:name="android.permission.ACCESS_BACKGROUND_LOCATION" tools:node="remove" /> , as that would presumably solve the issue with Mapbox. If it doesn't work, then we have to investigate further? @madhurgupta10

[madhurgupta10]

ACCESS_BACKGROUND_LOCATION

I checked the merged manifest file and there is indeed no ACCESS_BACKGROUND_LOCATION permission requested. Not sure why we are getting this error

[nicolas-raoul]

This developer had a similar problem, no ACCESS_BACKGROUND_LOCATION anywhere, and apparently this got their app approved:

[misaochan]

@nicolas-raoul Do you think we could appeal, talk to Google and say that we checked our manifest and merged manifest, and there is no ACCESS_BACKGROUND_LOCATION in either? At the very least, they might be able to give us more details on what exactly makes them think we are accessing location data in the background. Otherwise it feels a bit like shooting in the dark, there are a lot of things we can try but it would be a long process to slowly go through them.

[madhurgupta10]

@misaochan Even in the permissions I don't see "Allow all time" request as stated in docs

[misaochan]

Yes, indeed. :( I actually just tried promoting the beta to production anyway yesterday. It is still in review (more than 12h now), but we'll see what happens.

[whym]

Playstore page has a link (under Developer contract) to https://github.com/commons-app/apps-android-commons/wiki/Privacy-policy which doesn't exist. I confirmed this with a real phone's Play Store app and desktop Firefox.

Is it supposed to be https://github.com/commons-app/commons-app-documentation/blob/master/android/Privacy-policy.md#privacy-policy ?

This might or might not be related to the particular rejection, but I think it's a good idea to fix it regardless. A faulty privacy policy link seems like a potential cause of rejection in other privacy related matters, too.

[nicolas-raoul]

@whym Fixed, thanks a lot! :-)

[misaochan]

App was rejected from prod about an hour ago (so after the privacy link was fixed).

[whym]

Is the link really fixed? Here is what I'm seeing. It could be my local cache or something, though.