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.

[misaochan]

I believe in order to actually publish the new link, Google might have to approve our submission first, but I could be wrong.

[misaochan]

These are the results of my appeal to Google:

Step 1: Review the policy violation with your app

We found that your app is not compliant with the Location Permissions policy, or we were unable to review and verify your in-app experience for compliance with this policy.

Specifically, Prominent disclosure not found.

Your app must display a prominent disclosure through a pop-up alert before your app’s location runtime permission. Based on our review, a prominent disclosure did not appear before the runtime permission.

Please add a prominent disclosure before the runtime permission.

To meet the policy requirements, it is 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.”

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) Remember, your prominent disclosure must:

Appear before your app’s location runtime permission Include an example format listed above 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 If portions of your app are restricted, please share a link to a video of your app that demonstrates the in-app feature’s functionality requesting location in the background and how a user would trigger the prominent disclosure and runtime permission (with user consent) Include buttons that are clear to the user if they are approving or denying access. If a user denies access and that would limit the app experience, then make sure to inform them on how to change preferences in the future Please ensure your prominent disclosure is included in the video required in the Developer console.

Learn more about prominent disclosure requirements in the Developer Policy Center or in this video.

If you have determined that your app does not require location in the background or if you believe your app no longer accesses location in the background, complete the following steps to ensure compliance:

Ensure that the ACCESS_BACKGROUND_LOCATION permission has been removed from your app APK or app bundle. If you are using ACCESS_COARSE_LOCATION or ACCESS_FINE_LOCATION, examine your code paths and ensure usage is restricted to foreground purposes only (learn more) If you previously had any non-compliant APKs accessing background location, make sure the non-compliant versions are not in any of your current releases, even if you do not use certain tracks. Go to Release > App bundle explorer page to check whether a certain version is active When submitting a new APK to supersede the previous, non-compliant APK, please make sure the non-compliant app bundles or APKs are under the Not included section before rolling out the new release. For further guidance, please see the "Not included (app bundles and APKs)" section in this Play Console Help article. Please ensure that any new, compliant release is rolled out to 100% and completely deactivates non-compliant APKs. If you are still facing issues after examining your code paths and restricting usage to foreground purposes only, please review any third party SDKs used in the app that may be accessing location in the background.

For additional help, you can review the following resources:

Location permissions - Developer Policy Center Requesting access to background location - Play Console Help Evaluate background location access & Background location access checklist - Documentation for app developers Google Play PolicyBytes on YouTube Please update your app to fix this issue. You may also want to double check that your app complies with all other Developer Program Policies.

[madhurgupta10]

@misaochan one thing I understand is that we should add a dialog before the permission dialog which tells the user why we need this permission.

Apart from that, I don't really understand what's causing the background location :(

[misaochan]

@madhurgupta10 Yes, as I mentioned on Zulip, the email sounds like the prominent disclosure is their primary issue, and resolving that may allow our release to go through. We can leave this issue open for further investigation, should anyone wish to take it up in the future.

How about we add a dialog before the location permission that says: “The Commons app collects location data in the background to display nearby places that need photos"? This seems like it would satisfy their format.

[madhurgupta10]

This should be acceptable I guess. Also I think Google's definition for background location not necessarily mean that only apps that use location when they are closed are considered in this category but also like our app which uses location when app is not in foreground (like nearby walk) will also falls under this category so a more clear prompt message should be acceptable to Google.

[misaochan]

Ah yeah, makes sense. Do you think you could implement this dialog please?

[misaochan]

Still rejected. I appealed again...

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.

[misaochan]

The appeal has been declined. Oddly, v4.0.3 still remains up on beta, but v4.0.4 cannot be pushed to either beta or production.

Status: Latest app update not available on Google Play

I’ve reviewed your appeal request and found that your app, Wikimedia Commons, (fr.free.nrw.commons), still violates Google Play Policy. If you submitted an update to an existing app, the version published prior to the update is still available on Google Play. I’ve included details below about the specific issue with your app and what you can do to get your app back on Google Play.

Step 1: Review the policy violation with your app

We found that your app is not compliant with the Location Permissions policy, or we were unable to review and verify your in-app experience for compliance with this policy.

Specifically, Feature does not meet requirements for background location access

We have re-reviewed your app, but your declared feature still does not meet the requirements to access location in the background because of the following reason:

It is possible to deliver a similar experience without access to location in the background Please note that we use multiple factors for evaluation, which results in a high bar for access to location in the background. You can refer to this Help Center article for information on the requirements for accessing location in the background.

Because of the restrictions on this policy, it is unlikely that your app will be approved for access to location in the background. Therefore, please remove the request to access location in the background and submit the update to your app.

If you are using ACCESS_COARSE_LOCATION or ACCESS_FINE_LOCATION, examine your code paths and restrict usage to foreground purposes only. Kindly check if you are using a 3rd party SDK that is using BG Location as well. (Learn more: https://developer.android.com/training/location/background)

Lastly, you should declare that you aren’t using background location by selecting “No” to the question “Does your app access location in the background in APKs or app bundles targeting Android 9 or older?"

For additional help, you can review the following resources:

Location permissions - Developer Policy Center Requesting access to background location - Play Console Help Evaluate background location access & Background location access checklist - Documentation for app developers Google Play PolicyBytes on YouTube Please update your app to fix this issue. You may also want to double check that your app complies with all other Developer Program Policies.

Step 2: Submit a compliant update or remove permissions

Make the necessary updates to address the issue(s) identified above. To continue using location in the background, submit or update your Developer Permission Declaration along with a compliant version of your app in Play Console for approval. If your app is not eligible to access location in the background or does not meet requirements for accessing location in the background, please remove the permission from your manifest and in-app functionality. Double check that your app is compliant with all other Developer Program Policies. Sign in to Play Console and submit the update to your app. Please make sure to deactivate any non-compliant APKs. To do this, you can create a new release and upload a compliant APK to each track containing the non-compliant APKs. Be sure to increment the APK version code and set the release to 100% rollout.

[nicolas-raoul]

Apparently, because we define minSdkVersion 19 (which is less than 29), ACCESS_FINE_LOCATION implicitly implies background location permission, so we must follow all the Google Play rules for that.

So it seems that we can either:

• In all places where location service is used, tell the user that we use background location.
• Or bump minSdkVersion to 29. That's Android 10 (released September 2019). That would mean 10541-2936-2886-2372=2347 of our users not being able to update (that's 2347/10541=22% of our users). Here "users" means people who have used the app in the last 30 days. Screenshot from the Google Play Console:

I have always been reluctant to increase minSdkVersion because our most valuable users (those in underrepresented countries/communities) are less likely to have recent phones. But if it is temporary in order to get important updates out to most users while adding the necessary permission popups, I am all for it :-)

[misaochan]

In all places where location service is used, tell the user that we use background location.

Unfortunately I don't think this would solve the problem, as the reviewer explicitly said that we aren't eligible for background location at all because "It is possible to deliver a similar experience without access to location in the background".

Or bump minSdkVersion to 29

Hmm, thanks, I was actually unaware that this might solve the issue. I agree, it would be extremely rough to drop 22% of our users, but this probably beats not being able to release updates at all. In a future grant, the team might consider requesting funds to look for solutions that allow min SDK to be reduced again.

I am willing to try one last update that includes bumping min SDK. @madhurgupta10 @neslihanturan ?

@nicolas-raoul Out of curiosity, if someone's phone is <Android 10, can they not access the app at all, or can they still access the old version?

[madhurgupta10]

I suspect bumping up the SDK version will result in unexpected crashes whenever location service tries to get location in background.

[misaochan]

We don't actually access location in background, though? According to the SOF thread, it is just implied by our min SDK.

[nicolas-raoul]

reviewer explicitly said [...]

Sorry I had missed that :-( Thanks for the hint!

if someone's phone is <Android 10, can they not access the app at all, or can they still access the old version?

Existing users with an old Android will keep the out-of-date app. But new users with an old Android will not be able to find the app in Google Play.

[madhurgupta10]

We don't actually access location in background, though? According to the SOF thread, it is just implied by our min SDK.

Google's definition of background location is quite confusing but we can try with this change

[misaochan]

I tested it and no additional crashes that I can see so far. Will try releasing with this.

[madhurgupta10]

@misaochan Also I think we should remove "in the background" from the permission prompt