Closed yanokwa closed 5 years ago
I've reached out to some contacts at Google to get a bit more information about our options. I'll update this ticket as I learn more.
You have to fill the form at "Permissions Declaration Form" that's the approach I am taking today in my organisation since we use sms in developing country to make the use of some critical operation possible even if we are offline thanks to SMS->POST operators(Africa's Talking for example.) I think Google will understand.
@devsparkles If you don't mind sharing, what organization is it, how do you use SMS, and which exception category are you applying under? I ask because I'd like to show Google that perhaps they might want to add another category for SMS transport.
I've sent in the declaration form under task automation. We'll see what happens...
Any news on this?
I have not heard back. I do know there are a lot of upset developers and users. It's very frustrating.
Just heard back. We are OK until March 9th, but are still waiting to see if our request is granted.
Hi Developers at Open Data Kit,
Thanks for contacting the Google Play team. We’ve received your Permissions Declaration Form and are writing to confirm your extension until March 9, 2019.
If your Declaration Form included a request to access permissions, we will follow up with you once the review for your submission has been completed. If your app requires changes to become compliant, make the necessary changes and upload the revised APK or App Bundle before March 9, 2019 to avoid your app's removal from Google Play. Make sure that your app is otherwise compliant with other Developer Program Policies to prevent your app from being removed.
For more information, you can visit the Play Console Help Center, which describes intended uses, exceptions, invalid uses, and alternative options for use of Call Log or SMS permissions.
Regards,
The Google Play Team
Hi, I received this email too. We have a Chat app, and it uses SEND_SMS permission to verify the user's number. I filled the declaration form, and in response, they just extended the time until March 9.
Bit of bad news.
We reviewed your request and found that your app, ODK Collect, org.odk.collect.android, does not qualify for use of the requested permissions for the following reasons:
The declared feature {Device Automation} is allowed; however we determined it to be unnecessary for the core functionality of your app.
I've reached out to Google to provide more detail about our use-case.
I have a similar issue, We send the Form at January 8 2019 , we have not received any answer from Google. Yesterday we try to upload a app update and Console did not let us. We are a financial company and we need to verify every user by SMS . Do you have any idea or email to contact them?
Because this one wont work: Google Play Support googleplay-developer-support+no-reply@google.com
@cristofermarin https://support.google.com/googleplay/android-developer/answer/9047303 Under "Alternatives to common uses" "SMS OTP & account verification | With the SMS Retriever API, you can perform SMS-based user verification in your app automatically, without requiring the user to manually type verification codes, and without requiring any extra app permissions.If the SMS Retriever API is not an option for your app, users can also manually enter a verification code."
Will the SMS Retriever API not work for you?
@cristofermarin if you filed an exception you should automatically get an extension until March 9th, and I haven't heard of anyone that has an extension not being able to upload an app update due to this policy.
@cristofermarin https://support.google.com/googleplay/android-developer/answer/9047303 Under "Alternatives to common uses" "SMS OTP & account verification | With the SMS Retriever API, you can perform SMS-based user verification in your app automatically, without requiring the user to manually type verification codes, and without requiring any extra app permissions.If the SMS Retriever API is not an option for your app, users can also manually enter a verification code."
Will the SMS Retriever API not work for you?
I will ask to my leader to delete it, I asked before about SMS Retriever API it does not a option. Because if READ permission is a problem as you said we can remove it and let to the user write it.
Thanks for your comments
@cristofermarin if you filed an exception you should automatically get an extension until March 9th, and I haven't heard of anyone that has an extension not being able to upload an app update due to this policy.
Thanks for this information! I appreciate your time
@grzesiek2010 Feedback from Google has not been positive so far. Can you come up with some ideas for the most minimal change we can make to Collect to responsibly disable the need for the WRITE_SMS permission?
We can hope that the answer you received was automated and you can reach someone from Google and persuade to accept our app. If not... there is not much we can do. Alternatives are well described https://support.google.com/googleplay/android-developer/answer/9047303
and in our case, it would be calling a default SMS app with the SMS Intent but then a user would need to accept each message manually (click on a send button). It won't be a quick fix.
Only an app that has been selected as a user's default app for making calls or text messages, or whose core functionality is approved for one of the exception use cases, will be able to request access to Call Log or SMS permissions.
You should only access Call Log or SMS permissions to enable your app’s core functionality.
That indicates it won't be easy to persuade them but I believe in your abilities :)
Tasker app (which is the most common example in articles about this issue) finally got approved (Google extended their list of exceptions https://support.google.com/googleplay/android-developer/answer/9047303) so if they make exceptions, there is still a little hope for us as well.
I've been making our case with high-level folks at Google since mid-November. We have not yet been granted an exception and I'm not optimistic we'll be able by March 9th.
@grzesiek2010 I'm aware of the alternatives and the tradeoffs (at least as far as user interaction). Can you come up with a plan to quickly and responsibly disable the feature so we aren't removed from the Play Store? The goal here isn't to comment the code, but rather the most minimal change to disable the call to the SMS permission (and thus the feature) so we have time to plan a more extensive change.
Apps must be actively registered as the default SMS, Phone, or Assistant handler before prompting users to accept any of the above permissions and must immediately stop the use of the permission when they no longer are the default handler.
Potential workaround:
I've seen several apps that prompt the user to temporarily set itself as the default SMS provider; the app performs any SMS-related functionality; then the default is reset when you exit the app. Some examples that come to mind are SMS Backup & Restore and SMS Search & Delete.
It's a straightforward process with seemingly native Android dialogs that quickly and easily let you become default and then revert afterward. The user doesn't need to use System Settings, they just press OK on the dialog.
The only issue there is that Collect may still not be approved depending on how strict Google is about "core functionality":
You should only access Call Log or SMS permissions when your app falls within permitted uses and only to enable your app’s core functionality.
Core functionality is defined as the main purpose of the app. It's the feature most prominently documented and promoted in the app’s description; no other feature is more central to the app’s functionality. If this feature isn't provided, the app is “broken” or rendered unusable (i.e., app is deprived of its primary functionality and will not perform as a user would expect).
I would make the case that sending via SMS is the core functionality in certain regions that don't have reliable data access and depend on SMS to submit forms. In these regions SMS form submission would certainly be promoted in the docs and expected by users, and without it the app would be unusable.
Can you come up with a plan to quickly and responsibly disable the feature so we aren't removed from the Play Store?
I'm on it
The only issue there is that Collect may still not be approved depending on how strict Google is about "core functionality"
I doubt they would accept our app with SMS as core functionality.
@cooperka Any idea what would happen if another app tries to send an SMS while we are the default app? Can Collect reject that message somehow?
We'd need to test it out to be sure, but based on the Telephony docs it sounds like we could just do nothing and the other app would still know a new message arrived. The user wouldn't see a notification that they got a new message, but the message would not be lost. Collect could even show a basic notification.
It's not ideal but I don't know what else we could do if we don't get approved for an exception, aside from opening a message draft in a separate app and hoping the user presses "send".
Other apps that are not selected as the default SMS app can only read the SMS Provider, but may also be notified when a new SMS arrives by listening for the Telephony.Sms.Intents.SMS_RECEIVED_ACTION broadcast
We have an app on Play store and have been informed by Google that affected permissions are RECEIVE_SMS, READ_CALL_LOG, WRITE_CALL_LOG.
We submitted a Permissions Declaration Form to request an extension until March 9, 2019.
If our new app is not up on Play by then and it gets taken down, will all those apps already downloaded onto user's devises be affected too? Thanks.
@chakotha it sounds like apps will be removed from the Play Store but will not be affected if already installed on the device. You can continue to install these apps from "alternative" stores such as the Amazon Appstore or GetJar.
@cooperka thanks for this.
Hello @grzesiek2010, you claimed this issue to work on it, but this issue and any referenced pull requests haven't been updated for 10 days. Are you still working on this issue?
If so, please update this issue by leaving a comment on this issue to let me know that you're still working on it. Otherwise, I'll automatically remove you from this issue in 5 days.
If you've decided to work on something else, simply comment @opendatakit-bot unclaim
so that someone else can claim it and continue from where you left off.
Thank you for your valuable contributions to Open Data Kit!
I found the same problem, my application need to use SEND_SMS to help users to send many sms one time, but i havent found the right description for that in the google eligible exception list (one of them called "Physical safety / emergency alerts to send SMS" adequate to my needed permission, but his use case don't so for my app case (broadcasting)). @yanokwa, did you found something that can help us ?
Google did not grant an exception and so the SMS feature as been disabled. For that reason, I'm closing this issue.
If we can't figure out how to re-enable SMS in the next six months, we should remove the code. See https://github.com/opendatakit/collect/issues/2934 for that issue.
our app does not have SMS or Call Log functionality but still they are sending us the same error again and again, I have submitted the appeal multiple times but they are sending us the same message again and again. This is frustrating.
can anyone help me here please.
@novastreams Check your manifest permissions whether it contains Call or Sms permissions
I got a message from the Google Play Store about upcoming changes to the Play Store rules which will affect Collect. I have yet to dig into this, but I wanted to get the text of the message filed in an issue as soon as possible, so we everyone is aware.