相信大家在很多交流群都问到高风险封号：《开发者分发协议》第 8.3 或 10.3 条规定的“高风险或滥用模式”，得到的答复大多是因为账号关联引发了8.3 或 10.3 高风险违规，从而导致新号被封。

这的确是原因之一，但不是唯一原因。根据经验和Google产品专家所言，高风险一般可从以下三个原因定位违规点，方便以后杜绝，重新上包：

1) 即大家常提的账号关联：该账号可能与另一个已终止的账号关联，是引发高风险的多数原因之一。Google特意提到了第三方开发团队，如果他们很多开发者的账号被封禁后，又尝试为他人开发代码，最终也有可能遭遇账号被封禁的命运。

2) 大家很容易忽视的用户数据政策：应用程序正在对用户数据执行一些不该执行的操作，也是引发8.3 或 10.3 高风险违规封号的原因之一。这可能是您本身的应用程序代码或已添加的 三方SDK 中的内容。

例如您的App正在执行用户数据的上传，但您没有告诉用户应用程序正在以何种方式使用该数据，或者您本身就是故意欺骗用户，在偷偷上传用户数据。当然，如果代码是由第三方SDK编写，您是否已检查过三方代码以确保其符合政策？我们要知道，三方SDK代码也属于我们App。我们需要检查其代码以确保其安全性。

所以，我们要检查应用描述等以及应用中的文本，以确保用户知晓并正确声明了所使用的任何数据。如果您确定自身代码和披露都没问题，那么很可能是第三方SDK问题（这也是我们最容易忽视的问题，一些数据相关SDK初始化后就会偷偷的收集数据，如果我们忽视了并且没有在隐私协议中披露，就很容易触发8.3 或 10.3 高风险违规封号）。
关于用户数据政策，可看：https://support.google.com/googleplay/android-developer/answer/10144311?hl=zh-Hans

3) 不可忽视的混淆：相信大家都遇到过这个警告，但解决的应该没几个。

每次上传版本到Google都会要求我们上传mapping文件，但基本大多数人并未上传。
专家猜测：加固或者混淆后的AAB，并且未上传mapping文件，更容易被误判为高风险，尤其是没有收集任何敏感权限的高风险，可以考虑这个原因。

混淆后的AAB可能使Google难以判断我们代码Api的真实用途，造成误判，更有甚者，会有一定几率让google认为我们在隐藏部分功能，导致欺骗行为。
所以，做正经业务的老板还是建议上传mapping文件，一个是让我们的App更加合规，一个是更方便我们定位线上问题。