清泛IT社区

标题: Error 908: Permission RECEIVE_SMS has been denied. [打印本页]

作者: App Inventor 2 时间: 2024-03-22 09:07
标题: Error 908: Permission RECEIVE_SMS has been denied.
(, 下载次数: 66427)
这篇帖子是关于在MIT App Inventor中遇到错误908（权限接收短信）的讨论。一位用户遇到了这个问题，并询问是否有人知道如何解决。其他用户提供了一些可能的解决方案，包括检查应用程序权限设置、确保手机上的权限设置正确、重新编译应用程序等。有人建议检查应用程序是否有读取短信的权限，以及是否需要在AndroidManifest.xml文件中声明这些权限。一些用户还分享了他们遇到类似问题的经历，并提供了解决方法。总的来说，这个帖子是一个关于如何解决MIT App Inventor中错误908的讨论，提供了一些可能有用的建议和解决方案。
（by ChatGPT）
Google Play Store政策要求，声明可以在没有用户干预的情况下直接发送短信和拨打电话，或接收短信和电话的所有应用程序都需要Google员工进行手动审核。MIT App Inventor Companion就是其中之一，尽管我们提出了上诉，但被拒绝了。
为了符合Google Play Store政策，我们决定稍微调整功能。
对于发送短信/拨打电话，我们创建了SendMessageDirect和MakePhoneCallDirect模块，执行旧的需要额外权限的行为。我们选择让现有的SendMessage和MakePhoneCall模块通过Intents启动默认应用程序，这是Google政策推荐的做法，对大多数人应该有效。
对于接收，我们使应用程序只有在满足特定条件时才会获得谷歌Play商店标记为红旗的权限：
对于短信，条件是ReceivingEnabled属性必须设置为除了Off（默认）之外的其他值，或者在代码中存在设置该属性的模块。
对于电话呼叫，如果代码中包含任何IncomingCallAnswered、PhoneCallEnded或PhoneCallStarted事件，则权限将包含在清单中，并且（如果Android >= 6.0）在运行时请求。
在此更改之前，ReceivingEnabled的默认值是Foreground，而不是Off。因此，旧的教程可能不起作用，因为它们假设了旧的行为。人们需要有意识地启用接收选项才能接收短信。
现在的主要挑战是，人们可能希望为自己使用依赖于谷歌审查功能的应用程序进行开发。这就是“u”伴侣的用处所在。它是伴侣，如果Google没有改变Play商店的政策的话，就是它的样子。它是通用的，未经修改的版本，其他所有版本的Companion都是从它派生而来的。然而，我们无法通过Play商店分发它（正如我所提到的，我们申请了豁免权，但被拒绝了），所以我们只通过网站分发它。“u”版本的伴侣允许对使用谷歌认为可疑的功能的应用程序进行实时测试。在Google Play发布的版本中，此功能将根本无法工作或引发权限错误。
该伴侣仅用于实时测试，您使用的版本与构建应用程序时将发生的事情无关。当您构建应用程序时，构建服务器会分析代码，并查看是否满足添加权限的先决条件，如果满足这些条件，就会包含权限。在此时，如果您提交应用程序到Play商店，Google会标记它，并可能拒绝它。如果您通过其他方式分发它（或仅供个人使用），那就完全没问题。
启用功能与禁用“谷歌安全措施”不等同。这只意味着如果您将应用程序提交到Play商店，将需要进行额外的审核。如果您不打算这样做，就没有伤害，也没有过失。
如果有人想要制作一个使用谷歌认为需要进一步审查的功能的应用程序，那么他们就要自己说服Google给予豁免权。

英文原文：

Google Play Store policy requires that all apps declaring the ability to send text and make phone calls directly without user intervention, or to receive texts and phone calls, require a manual review by Google staff. The MIT App Inventor Companion was one such app, and in spite of an appeal it was rejected.
To comply with Google Play Store Policy, we decided to move the functionality around a bit.

For initiating texts/calls, we created the SendMessageDirect and MakePhoneCallDirect blocks that do the old behavior that needs extra permissions. We chose to have the existing SendMessage and MakePhoneCall blocks launch the default apps via Intents , as recommended by Google policy, which should work for most people.
For receiving, we made it so that apps would only get the Google Play Store red-flag-triggering permissions if and only if certain conditions were met:

For Texting, the condition is that the ReceivingEnabled property must be either set to something other than Off (the default), or a block setting the property must exist in the code.
For PhoneCall, if any of the events IncomingCallAnswered, PhoneCallEnded, or PhoneCallStarted are included in the code, the permissions are included in the manifest and, if Android >= 6.0, requested at runtime.

Prior to this change, ReceivingEnabled was default Foreground, not Off. Therefore, older tutorials may not work since they assume the old behavior. People will need to consciously enable the receiving option to receive texts.

The big challenge now was that people might want to develop apps for their own use that relied on the Google-censored functionality. This is where the “u” companion comes in. It is the companion as it would have been if Google hadn’t changed the Play Store policies. It’s the universal, unadulterated version, from which all other versions of the Companion derive. However, we can’t distribute it via the Play Store (as I mentioned, we applied for an exemption and were denied), so we only distribute it via the website. The “u” version of the companion allows live testing of apps that use the aforementioned functionality that Google has deemed questionable. In the Google Play published version, this functionality simply won’t work or will raise a permission error.
The companion is only for live testing, the version you use has no implication for what will happen when you build an app. When you build an app, the buildserver analyzes the code and looks to see if it meets any of the preconditions for addition the permissions, and if those conditions are met, includes the permissions. At this point, if you were to submit your app to the Play Store, Google will flag it and may reject it. If you’re distributing it through some other means (or just using it for yourself), then it’s perfectly fine.
Enabling the functionality is not equivalent to disabling “Google security measures.” All it means is that one will be required to go through additional review if one submits the app to the Play Store . If one doesn’t intend to do that, no harm, no foul.

If someone wants to make an app using the features that Google has deemed need further review, it is up to them to convince Google to grant an exemption.

原文：https://community.appinventor.mi ... -receive-sms/7426/5

相关问题可以参考这个帖子：https://bbs.tsingfun.com/thread-1833-1-1.html
必须真机，模拟器不支持，在手机设置中开启短信相关权限。

欢迎光临清泛IT社区 (https://bbs.tsingfun.com/)