App currently not available on Google Play

[westnordost]

StreetComplete has been removed from Google Play

The message:

---

I couldn't find anything in the linked articles

• Permissions
• Location Permissions
• Help Center

...that would explain in what way the app is not compliant with the Developer Program Policies. Apparently it is about background location permissions. And so, the link to "Developer Permission Declaration" leads to a page that looks like that... ...which makes sense, because the app does not use any background location permissions.

What doesn't make sense is that the app got removed from Google Play.

[westnordost]

I already wrote a message to the policy support team. Content:

It is claimed that the app does not comply with the Location Permissions policy and it has been removed from Google Play. I believe this is a mistake:

The app DOES NOT request location in the background or foreground service The app DOES NOT display any ads or track its users in any way, i.e. transmit their location anywhere The app DOES request location when the app is in foreground. The location is used to

1. download data in the vicinity of the user. This data is indispensable for the core functionality of the app
2. display the user's position for orientation on the map, like any map-based app does

The purpose of the location permission is clearly communicated to the user.

PLEASE NOTE: In the Google Play Console -> App content -> Sensitive app permissions I am UNABLE to make any statement because there is only the text "Your app doesn't request sensitive permissions, so you don't need to do anything here" and nothing else. A bug in the Play Console?

[westnordost]

It is possible that even if the app does not have the ACCESS_BACKGROUND_LOCATION permission in its manifest, a dependency has it so that in the merged manifest, the app will request that permission.

Android Studio has this handy feature where one can directly view the merged manifest:

Result: Nope, contrary to the claim, no background permission is requested.

So, I am out of ideas. I am now almost 100% sure this is a bug in their policy-checker-bot.

[matkoniecz]

If someone wants to install it in meantime:

https://github.com/streetcomplete/StreetComplete/releases/tag/v32.0 has an apk file (you will need to enable installing apk files in settings, note that you should install only trusted apk files and some are actually malicious)

https://f-droid.org/en/packages/de.westnordost.streetcomplete/ has not yet made v32 available but has older versions

---

So, I am out of ideas. I am now almost 100% sure this is a bug in their policy-checker-bot.

Or in display and actual complaint is something else?

Though now I remember that MAPS.ME fork also got removed with claim that map app does not need location permission...

I will check have they also got "doesn't comply with location permission policy".

---

Argh. Do you think that it is worth posting "buggy automatic review by Google randomly bans app" in places like https://news.ycombinator.com/ ?

With goal of being noticed by human in Google who actually will not be ignored?

Or is it better to wait a bit and hope that this email will be actually processed?

[matkoniecz]

Not sure exact ban reason for Organic Maps.

They are back but with a different app id, so maybe they uploaded it from a different account? See https://github.com/organicmaps/organicmaps/commit/83ee96607ded948c2041f66e89ee1dabbad4c4a1

Info from https://t.me/originalmapsmegroup/1782

[peternewman]

Looks like it was probably a name clash not a ban, unless you saw an actual ban: https://github.com/organicmaps/organicmaps/issues/97

[dbf256]

In organicmaps chat they mentioned that there was an issue with location permission, so their app was removed. @westnordost I think you can check with their team how they solved it (see contacts at https://organicmaps.app/) or check in their repo are there any related commits.

[matkoniecz]

@dbf256 I just asked on one of their Telegram channels (about three hours ago).

[simonpoole]

You could all just stop widely speculating and ask somebody that knows what is going on? See https://twitter.com/vespucci_editor/status/1330997796745457665

google has two different definitions of background access of location data that contradict each other, but the important bit is that -any- potential access of location data while the app is not visible, for example changing something in the settings or quickly using a different app, including access in a "foreground service", is what is relevant. As this is clearly the case with SC, you simply need to fulfill googles criteria (notices, video, privacy policy) and all will be fine and dandy.

Don't bother trying to reason, you are only communicating with bots.

PS: the policy has been in place for over half a year and the warnings were essentially impossible to miss when updating apps. So it isn't as if this should come as a surprise

[westnordost]

Good to know that this is a wider phenomen and does not only affect SC. Looks like Google bots will have to read through quite a few appeals then.

Anyway, SC does not even use the users' location in a foreground service (unlike Vespucci, SC does not have the feature to record a GPX track) and the privacy policy is very clear on for what the location is used, always has been.

So, I think your assesment/assumption may be wrong. But you are right, no sense in speculating, let's wait on what is their response. I'll post it here as soon as I get it.

Am 26. Mai 2021 14:00:42 MESZ schrieb Simon Poole @.***>:

You could all just stop widely speculating and ask somebody that knows what is going on? See https://twitter.com/vespucci_editor/status/1330997796745457665

google has two different definitions of background access of location data that contradict each other, but the important bit that -any- potential access of location data while the app is not visible (for example changing something in the settings or quickly using a different app), including access in a "foreground service", is what is relevant. As this is clearly the case with SC, you simply need to fulfill googles criteria (notices, video, privacy policy) and all will be fine and dandy.

Don't bother trying to reason, you are only communicating with bots.

-- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: https://github.com/streetcomplete/StreetComplete/issues/2909#issuecomment-848709833

-- Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.

[simonpoole]

Good to know that this is a wider phenomen and does not only affect SC. Looks like Google bots will have to read through quite a few appeals then. Anyway, SC does not even use the users' location in a foreground service (unlike Vespucci, SC does not have the feature to record a GPX track) and the privacy policy is very clear on for what the location is used, always has been. So, I think your assesment/assumption may be wrong. But you are right, no sense in speculating, let's wait on what is their response. I'll post it here as soon as I get it.

I just made the point wrt the foreground service as google explicitly states in their documentation that accessing location in a foreground service is not background access (and using it doesn't require any other permission than foreground location access), to illustrate that it has literally nothing to do with any of their other policies and definitions. I suspect that the -only- use that could be compliant without the declaration is "single use on user interaction" location access (but I would hope that nobody has the time to explore the bounds of what actually goes by uploading test apps). Their privacy policy requirements require mentioning specific words so you should review the policy too.

[westnordost]

Ah, ok

Am 26. Mai 2021 14:30:13 MESZ schrieb Simon Poole @.***>:

Good to know that this is a wider phenomen and does not only affect SC. Looks like Google bots will have to read through quite a few appeals then. Anyway, SC does not even use the users' location in a foreground service (unlike Vespucci, SC does not have the feature to record a GPX track) and the privacy policy is very clear on for what the location is used, always has been. So, I think your assesment/assumption may be wrong. But you are right, no sense in speculating, let's wait on what is their response. I'll post it here as soon as I get it.

I just made the point wrt the foreground service as google explicitly states in their documentation that accessing location in a foreground service is not background access, to illustrate that it has literally nothing to do with any of their other policies and definitions. I suspect that the -only- use that could be compliant without the declaration is "single use on user interaction" location access. Their privacy policy requirements require mentioning specific words so you should review the policy too.

-- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: https://github.com/streetcomplete/StreetComplete/issues/2909#issuecomment-848728356

-- Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.

[westnordost]

Do you have a link to the doc that mentions the specific words that must be mentioned? (I didn't consider bot-optimising the privacy statement yet, LOL)

Am 26. Mai 2021 14:30:13 MESZ schrieb Simon Poole @.***>:

Good to know that this is a wider phenomen and does not only affect SC. Looks like Google bots will have to read through quite a few appeals then. Anyway, SC does not even use the users' location in a foreground service (unlike Vespucci, SC does not have the feature to record a GPX track) and the privacy policy is very clear on for what the location is used, always has been. So, I think your assesment/assumption may be wrong. But you are right, no sense in speculating, let's wait on what is their response. I'll post it here as soon as I get it.

I just made the point wrt the foreground service as google explicitly states in their documentation that accessing location in a foreground service is not background access, to illustrate that it has literally nothing to do with any of their other policies and definitions. I suspect that the -only- use that could be compliant without the declaration is "single use on user interaction" location access. Their privacy policy requirements require mentioning specific words so you should review the policy too.

-- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: https://github.com/streetcomplete/StreetComplete/issues/2909#issuecomment-848728356

-- Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.

[simonpoole]

Just checked seems that I misremembered: the required text is for the notice that you have to display the first time location data is used, I simply used a variant of the same for the privacy statement to be on the safe side (as they will literally be checking with a bot).

The requirements, not only wrt the text, are listed here:

https://support.google.com/googleplay/android-developer/answer/9799150#prominent_disclosure&zippy=%2Cstep-provide-prominent-in-app-disclosure

The requirements wrt privacy policy contents are just below, but they, as said, don't require specific words.

Edit:

Fine point to note: the text wrt the notice display has changed to take the permission systems change for Android 30 in to account, if you are not targeting 30, the user has already granted permission at the point the message is displayed.

[matkoniecz]

@westnordost Is there some useful way how can I help here or should I rather finish satellite view PR?

[westnordost]

No, I'll wait on their answer.

[smichel17]

Tangential social context: FWIW, I've noticed an uptick in capricious Play Store takedowns based on increasingly asinine requirements -- a FLO (free/libre/open) app which has been a good actor for years shouldn't be subject to the same anti-abuse scrutiny as some newly-uploaded proprietary adware. Simpletask finally decided to stop fighting them and distribute exclusively through F-Droid. https://github.com/mpcjanssen/simpletask-android/issues/1102

[westnordost]

How is this relevant?

[smichel17]

Sorry, I pasted the link and then switched apps, planning to come back and compose the reply later; didn't realize I'd posted. Edited now.

[westnordost]

I still did not get a reply from Google yet, so I looked into what policies the app would have to fulfill if the app used the background location permission. In that case, it does not fulfill:

You must provide an in-app disclosure of your data access, collection, use and sharing. The in-app disclosure:

• Must be within the app itself, not only in the app description or on a website;
• Must be displayed in the normal usage of the app and not require the user to navigate into a menu or settings;
• Must describe the data being accessed or collected;
• Must explain how the data will be used and/or shared;
• Cannot only be placed in a privacy policy or Terms of Service; and
• Cannot be included with other disclosures unrelated to personal or sensitive data collection.

The language in the disclosure MUST include the following elements:

1. The term 'location'
2. A list of all the features that use location in the background

So, currently the information how the location permission is used is displayed in the in-app privacy statement and also in case the user denies the permission, in a separate dialog / toast but not before the location permission is requested.

[westnordost]

So I changed the behavior to be like this

1. The location permission is now (unnecessarily) mentioned in the 2nd step of the tutorial. Unnecessarily because basically in the first step of the tutorial, it is already mentioned that "quests are downloaded in your vicinity". But Google wants the keyword "location" and "a list of features" which would include the trivial "showing the users position on the map". If Google recognizes their mistake, I'd maybe shorten that sentence.
2. The location permission is now asked after the tutorial, not basically at first app start (during step 1 of the tutorial). The downside of this is that the app will not zoom to the users location and have possibly downloaded the quests already when the user exists the tutorial. On the other hand, it's clearer to the user this way. So personally, I think it is better this way. When the map view is visible in the background, it is also clearer from the context why location permission is necessary.
3. Once after the user denied the location permission after the tutorial, a dialog with an explanation is shown, this is pretty similar to the way it was before, only that the text is a little longer now (i.e. "lists all features") and has a title.

Finally, I modernized the code in that class a bit. The code there however is very complex and there are many different cases to cover. I'd be grateful if some of you would check out the current master and report any issues.

[matkoniecz]

The downside of this is that the app will not zoom to the users location

I think that it is not better at all.

I made a clean install.

I got placed somewhere in Asia and needed to manually locate me (press location arrow on a screen border). This seems to not be obvious to someone new.

[matkoniecz]

Not sure is it implementable and Google-bot-safe but I would ask for permission between second and third tutorial step.

[westnordost]

What do you mean, you got placed in Asia? By default (with no location), the world map will be shown. Once location is known, the view should zoom in to your location.

I would ask for permission between second and third tutorial step.

Yeah, I tested that as well. But this had a few problems:

1. the "Deny" button is at the same place as the "Next" button. If one clicks through the tutorial without reading (I expect quite a few people do this), then the location is denied . This is much less likely to happen if the view changes and the map is visible in the background
2. probably solveable, but the way I implemented it, the permission was asked during transition to step 3, so the animation was not visible

[matkoniecz]

What do you mean, you got placed in Asia?

It zoomed me to some random location in Asia. I am now trying to reproduce it (on a physical device, no emulator only bug this time).

It seems that tapping a lot on tutorial screens can cause initial map view to show a random(?) location worldwide - usually ocean.

But second part, zooming to the current user location seems to work fine even then - but sometimes it also fails. Not sure how to trigger this one, I though I can achieve it by switching to a different app works - it also kills temporarily mpa.

Overall I suspect upstream Tangram bug. And requires doing weird things to trigger, solely for little confusion. So fortunately not important.

BTW, is it happening, again, only on my phone?

Full bug:

https://user-images.githubusercontent.com/899988/120184922-d47b1200-c211-11eb-9d0c-002165a7a316.mp4

Asia waves hello (just to demonstrate that yes, you can be placed in Asia - while your GPS points to Poland):

https://user-images.githubusercontent.com/899988/120184699-8f56e000-c211-11eb-825d-11c7370727ac.mp4

Yeah, I tested that as well. But this had a few problems:

Good points, and in this case asking was better than testing on my own :)

[westnordost]

I think if you move the map (move, pinch, zoom, ...) in any way before the GPS location is discovered and the zoom initiated, then the app won't automatically zoom to your location. Because then you are not in the "follow my gps location" mode.

[westnordost]

Good points, and in this case asking was better than testing on my own :)

What?

[westnordost]

• Fixed that the map can be moved by reaching through the tutorial background (upper half did not capture touch input)
• Made it so that any panning before a location is known does not disable the "follow my gps location" mode.

[peternewman]

Out of interest, if you keep hitting deny, can you actually use SC without the location permission? Does it add an extra tag/note into commits when you do so? I guess it's a similar scenario to if you override the I'm nearby warning, although you could be further away?

[smichel17]

You can. And it's not "keep" hitting deny; SC will only ask for location permission once at the start, and when you press the location button, if not previously granted. When solving quests, it will show you a dialog reminding you that SC is intended for on-site surveying. If you select the option to the effect of "proceed anyway", the same dialog will appear for the next quest, but this one will have a checkbox to not show it any more this session (as will subsequent ones, if you don't select the checkbox). So in summary, there's a few extra taps each session, you'll need to manually download quests, and you won't have the dot to orient yourself, but otherwise it works the same.

[matkoniecz]

Good points, and in this case asking was better than testing on my own :)

What?

I thought about implementing it - and in such case I would duplicate what you tried already.

Out of interest, if you keep hitting deny, can you actually use SC without the location permission?

Yes, but you need to pan map and fetch quests on your own.

[westnordost]

So but you remain on your standpoint that it would be better to have the dialog pop up between step 2 and step 3?

[matkoniecz]

So but you remain on your standpoint that it would be better to have the dialog pop up between step 2 and step 3?

No, I was convinced by what you discovered in your testing.

[westnordost]

Ok, I guess what is missing now is that Streetcomple should request background location because now it fulfills the policy for that 🙄, haha.

I'll wait for a reply from google until tomorrow, if there is nothing from them, I'll just release v32.1

[matkoniecz]

Ok, I guess what is missing now is that Streetcomple should request background location because now it fulfills the policy for that roll_eyes, haha.

if(requestsBackgroundLocation(appId) XOR fullfillsRequirementsForBackroundLocation(appId)) banApp(appId);

[westnordost]

Jesus christ!

This helpful message comes up every time I try to upload the new release!

[westnordost]

Alright, with Chrome it worked. I hope I don't have to use Chrome now always for that.

After submitting the new update for review, I got the message that review can take up to a week. For the appeal, they wrote that it may take up to two days to answer and I didn't get a reply yet.

[HolgerJeromin]

Alright, with Chrome it worked. I hope I don't have to use Chrome now always for that.

Try Vivaldi. Is the same browser engine but without most/all google stuff

[simakuutio]

Got upgrade from Play Store so app is back. This ticket can be closed, I guess.

[matkoniecz]

Confirmed by someone who has it not installed :)

[westnordost]

Huh, I didn't get any email about it or any other feedback in the Google Play console.

Well okay then...

[westnordost]

After 3 weeks, got this template reply:

Hi Tobias,

Thank you for your patience.

Due to adjusted work schedules at this time, we are currently experiencing longer than usual process times and we appreciate your understanding.

I see that your app, StreetComplete (de.westnordost.streetcomplete), is published on Google Play, but it still violates Google Play Policy. I’ve included details below about the specific issue with your app and what you can do to keep your app compliant 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.

If you have determined that your app does not require location in the background, complete the following steps to remove background usage and reach compliance:

• For any APK targeting Android 10 or newer (SDK level 29 or higher):
  • Remove the ACCESS_BACKGROUND_LOCATION permission from your app APK or app bundle
  • [If minimum SDK level is 28 or lower] If you’re using ACCESS_COARSE_LOCATION or ACCESS_FINE_LOCATION, examine your code paths and restrict usage to foreground purposes only (learn more)
    • You should no longer see the Location declaration listed under App Content
  • For any APK targeting Android 9 or older (SDK level 28 or lower):
  • If you’re already using ACCESS_COARSE_LOCATION or ACCESS_FINE_LOCATION, examine your code paths and restrict usage to foreground purposes only (learn more)
  • In your console declaration, select “No” to the question “Does your app access location in the background in APKs or app bundles targeting Android 9 or older?”

Note: If your app targets SDK level 29 or higher but minimum SDK level is 28 or lower, for apps that use either ACCESS_COARSE_LOCATION or ACCESS_FINE_LOCATION, you must also check your code paths and restrict usage to foreground purposes only (even if you have removed ACCESS_BACKGROUND_LOCATION).

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.

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 the 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 your Play Console and submit the update to your app.

Please let me know if you have any other questions. We thank you again for your patience while we reviewed your issue. Regards, Billie The Google Play Team

Please visit the Google Play Developer Policy Center and Google Play's Academy for App Success to learn more about building policy compliant and high quality apps. You can also visit the Android Developers Blog for the latest Android and Google Play news for app and game developers.

[westnordost]

My reply:

Hello Billie

I am sorry to say that, but your reply is not helpful: It comes almost 3 weeks late and ignores everything I wrote in the appeal. It really looks very much like a automatic template reply.

Still, for your convenience, I will summarize in bullet points:

• The app DOES NOT use the background location permission for SDK level 29 and higher

  • The app DOES NOT use background location on SDK level 28 and lower. There are no code paths in the apps or any dependencies that use location in the background: Not in a background service or anywhere else

  • The app DOES actually fulfill all the policies to use background location, even though it does not use it

To continue using location in the background, submit or update your Developer Permission Declaration along with a compliant version of your app in the Play Console for approval.

• I am CAN NOT submit or update a Developer Permission Declaration because the link leads to a page that simply says "Your app doesn't request sensitive permissions, so you don't need to do anything here". See attached screenshot, this is what I see.

- Tobias Zwick

Attachment:

[westnordost]

@simonpoole let me guess, the above reply is exactly the same reply you got?

[simonpoole]

@simonpoole let me guess, the above reply is exactly the same reply you got?

Not going to do a word for word comparison, but it looks like the canned reply we got on our 1st appeal when we were still arguing that we don't access location in the background.

[westnordost]

Communication is faster now. Maybe they had technical problems and/or I am communicating with a real person now. Their reply:

Hi Tobias, Thanks again for contacting the Google Play team.

Kindly understand that I'm not able to provide further details as much as I'd like to help.

As informed in our previous email, if you haven't already addressed in the latest app update, please check your code paths and restrict usage to foreground purposes only even if you have removed ACCESS_BACKGROUND_LOCATION, if your app uses either ACCESS_COARSE_LOCATION or ACCESS_FINE_LOCATION and target SDK level is 29 or higher but minimum SDK level is 28 or lower. Also as a reminder, please note that any third party SDKs used in the app that may be accessing location in the background.

We appreciate your understanding.

Thanks for your continued support of Google Play. Regards, Billie The Google Play Team

Please visit the Google Play Developer Policy Center and Google Play's Academy for App Success to learn more about building policy compliant and high quality apps. You can also visit the Android Developers Blog for the latest Android and Google Play news for app and game developers.

So, they again did not read my email and this is another canned reply.

[westnordost]

My reply:

Hello Billie

Even though I find it curious, to say the least, that apparently the exact details for the decisions made are not documented,

I am not asking for help and I am not asking for further details.

I am refuting both the claims made by the Google Play Team that the app

• does use background location at all (yes, also below SDK level 28 and also by some dependency), and...
• that it does not fulfill the policies for using background location

In other words, your decision has been made in error (twice).

Please refer to my last email for details. Let me know if you have any questions.

- Tobias Zwick

[westnordost]

And their reply

Hi Tobias, Thanks again for contacting the Google Play team.

As mentioned in our previous conversation, please note that even if an app does not have ACCESS_BACKGROUND_LOCATION permission, it's still possible that the app accesses location in background caused by any third party SDKs used in the app, if the app's target SDK level is 29 or higher but minimum SDK level is 28 or lower and uses either ACCESS_COARSE_LOCATION or ACCESS_FINE_LOCATION.

In case you need further information, you can always refer back to the below pages.

• 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

We again appreciate your understanding.

Thanks for your continued support of Google Play. Regards, Billie The Google Play Team

Please visit the Google Play Developer Policy Center and Google Play's Academy for App Success to learn more about building policy compliant and high quality apps. You can also visit the Android Developers Blog for the latest Android and Google Play news for app and game developers.

Only now I noticed that parts of it is a carbon copy of the previous email but the first paragraph is not, it is just the same but written in different words. So am I conversing with a bot, or not? Does the bot have different phrasings at hand to appear human? If it is a human, why can he not tell me how they reached that conclusion, not documented at all? Policy-checker-bot just outputs "violation" with no explanation? So many questions.

[westnordost]

So, my answer... I am dedicated to get to the bottom of this. They can not forever palm us of with canned replies.

Hello Billie

You already mentioned this part in the three preceding emails. And I already answered you twice that I did check this: No dependencies declare any location permission and on all code paths, the app unsubscribes from location access when the app goes into background.

Again, I believe the decision was made in error. If you remain on your position, please kindly provide how you came to that conclusion and we may start the conversation from there.

Honestly, I am not even sure if I have been conversing with a real person so far. If you are not a bot, please write something to indicate that, f.e. your hobby (my hobby is OpenStreetMap), thank you.

- Tobias Zwick

I only have the patience to go through this because the update has already been approved and is live (so apparently satisfies their policy), something that the person/bot I am communicating with is apparently not aware of. So I am in no hurry.

[Cj-Malone]

Is this less or more of a headache than the F-Droid update stuff that happened a while ago? :p

[matkoniecz]

If it is a human, why can he not tell me how they reached that conclusion

Maybe it is a poorly paid human with rigid script or bunch of a canned answers, supposed to answer 60 mails every hour, all day long?