Google Play 恶意软件封号如何破局？
前言
本想接上篇 GooglePlay账号关联审查机制详解 继续写防账号关联的一些具体措施，但貌似今年因恶意软件导致的App暂停及封号已稳居上风。应多位读者要求，本文就7月我协助朋友解决的一次恶意软件警告违规事件进行总结，剖析解决思路及方案，希望可以对今年遇到此问题的同行一些启发，也希望借此和大家共同讨论恶意软件问题的解决方案，降低大家业务的封号暂停风险。
恶意软件警告如下图：
如果不按时解决无疑会对当前业务是致命的。
兵来将挡，水来土掩。警告来了，只能去奋力解决了。
万变不离其宗，解决Google Play违规警告，必须深研Google Play政策。
大家遇到的我想大部分都是恶意软件中的间谍软件，也就政策中的这一部分，这里只贴图，网址想必大家都能找到。
我们一定要深刻理解间谍软件的含义及画圈的几个政策地址，结合自己的项目分析可能的具体原因，然后尝试去解决。我分析一些我们觉得的重点给大家，在此，小编更希望大家也去细细的每行每句的研究一下，让我们来公共探讨恶意软件的解决方案，也让大家的业务更加稳定，公司和大家共同赚大钱
恶意软件问题剖析
类似录制音频或录制拨打电话这种明面上的或者大部分企业都不会遇到的原因不必多说，大家一目了然，下面只针对一些较为模糊的政策进行一些个人看法的愚见，也希望大家可以在留言区不吝赐教。
本解读只针对合规App来进行剖析解读，AB包，冒充他人App的灰色包不在本文考虑之内。
1
窃取应用数据
窃即为偷， 窃取应用数据应指的是通过非法（非合规）手段来破坏用户设备的完整性或获得用户设备的控制权来达到获取用户手机应用数据的目的。作为一个正常的应用，我们的App不会具备这种能力。但往细了想，早期Google禁止了个人贷款应用通过Query_all_packages获取手机Applist列表，我想大部分朋友都是统一使用QUERY_ALL_PACKAGES权限不给了！！！我们如何获取用户应用安装列表？intent 过滤器在继续抓取，那这种方式算不算窃取应用数据呢？类似的小开发技巧有很多，大家可以结合项目仔细斟酌。这是我觉得最有可能导致恶意软件的原因之一。
2
恶意代码在未向用户充分告知和同意的情况下将数据传输出设备
具体要求：带有恶意第三方代码（例如 SDK）（我一直认为我们自己写的代码也是第三方代码，组件化以后，我们的组件和三方SDK其实没多大差别）的应用程序以用户意想不到的方式和/或在未向用户充分通知或同意的情况下将数据传输到设备之外。
这是我觉得最有可能导致恶意软件的原因之二。
先给大家看一个案例，一个收集了通话记录的App的隐私协议如果是这样披露的？
如果您是审核人员，你会觉得这个App符合政策吗？不管是用户数据政策还是恶意软件政策！
见微知著，我想关于用户收集的披露问题，不管是在隐私协议，还是权限声明，亦或是其他任何地方，我们都要以用户享有绝对知情权（也就是充分披露）为根本，方能符合Google在数据收集披露和恶意软件方面的政策。
3
移动垃圾软件
移动垃圾软件违规分为四部分：移动垃圾软件，行为透明信息披露清晰，保护用户数据和隐私，不要损害移动体验。
我相信，99%的App都不会有其他三方面的问题。所以这里只看保护用户数据和隐私，政策中写明了数据收集和限制权限滥用两个违规案例。我们将移步第4点用户数据政策和第5点访问敏感信息的权限和 API中去分析，在这暂不不说。
4
用户数据
此政策对App在数据收集方向进行了全方位指导，文章很长，小编在这里给大家总结几点：
必须透明地处理用户数据，也就是在隐私协议中我们要将所有的收集数据均要披露清晰。可以以收集了什么数据 -- 收集此数据的目的 -- 数据如何上传并存储 -- 是否会分享 为模版进行披露 。
数据的使用应限制在符合政策的用途范围内，一我们要符合Google政策，二我们要符合当地金融机构或其他机构的法律法规。
个人和敏感用户数据满足突出披露和同意要求，要给予用户选择权，在用户不同意的情况下坚决不要一意孤行收集用户信息或者阻止用户使用App。
数据安全声明要和隐私协议披露一致，实事求是填写。
总而言之，我们在处理用户数据方面要给予用户绝对知情权和选择权，这也是Google在审核阶段非常注重的点。
5
访问敏感信息的权限和 API
我们来看下图，这是我觉得最有可能导致恶意软件的原因之三。
在这里，我不针对任何一个单独的权限做具体分析，在这个政策中Google对每一个敏感权限是否可以获取都有很严格的定义，大家可以自行查阅，在获取时一定是往你觉得最合适的Google示例去靠拢。但如果您遇到恶意软件问题，短信和通话记录是最需要注意的，Google政策也声明了这一点。
所以大家一定要仔细审查自己的敏感权限申请是否合理合规。
6
SDK要求
要求很多，大家可以自行查阅。下面我们只看SDK要求中恶意软件政策。如图：
很熟悉是吧，在SDK要求中，如果您集成的SDK和数据收集相关，也要符合用户数据政策，也要声明并详细披露，我们不再多说，老铁们可以看上面第2点和第4点。
总而言之，Google Play对SDK的要求和对应用的所有要求是一样的，不只是恶意软件。这就要求我们在选用SDK时一定要谨慎，尤其是和数据收集相关的SDK。建议大家尽量选择 Google Play SDK 索引 https://play.google.com/sdks 网址中的SDK。
这是我觉得最有可能导致恶意软件的原因之四。
解决措施
首先和大家说的是，在遇到这种7天内警告，尤其是后果比较严重（暂停或封号）的情况。 作为研究Google政策的你，态度一定要坚决，就是我要保号，保号，保号，不要其他部门的言语，说这个数据重要，那个什么重要。如果您妥协了，号没了，最终受牵连的一定是您，切记。
号保住了，后续就有无限的可能，Google Play严查是有周期性的，会受一些大事件的影响，号在！我们后续都可以去尝试重新去获取这些去掉的数据。
言归正传，在恶意软件剖析中，我简单总结了我认为最有可能的四点，具体措施也是针对那四点而来，下面我们来看一下：
1
去掉Applist信息收集
说实话，我不能确定本次恶意软件是不是和这个有关系，像我上面说的一样，我现在的目的是要保号，所以暂时去掉了用户安装列表的数据收集， 如果后面包稳定后，并且行业内大部分其他竞品还在收集，会再次尝试抓取此类信息。
2
重新梳理数据收集披露文案
我们整理了App所有收集的数据类别，按照收集了什么数据 -- 收集此数据的目的 --数据如何上传并存储 -- 是否会分享 模版重新对数据进行了更加细化的披露文案，修改了隐私协议，权限声明等所有涉及数据收集的地方。并在适合的地方增加了同意和拒绝选项，给予用户选择权，在用户不同意的情况下，绝不偷偷抓取任何数据。
3
去除通话记录权限，停止对用户通话记录的收集
在朋友的App的推广地区，很少有对通话记录权限进行申请的竞品。虽然Google政策和当地法律法规都没有明确禁止此品类App收集用户通话记录，但这依然是我们遭受恶意软件一个不得不考虑的点。为了保包，我们在此次调整中依然去掉了通话记录权限。
4
删除三方数据收集SDK
关于三方收集SDK，采取了一刀切的方案，我们无法确定它是否在偷偷的收集什么。这次调整我们直接全都删掉了。当然，我们有自己的收集SDK，如果您的App只有三方收集SDK，您就要慎重考虑了，可以确认三方SDK是否遵守了Google SDK要求，确保其是合规的。
在这里多说一句，我们把友盟（类似友盟的大家也要慎重对待）也去掉了，因为它也会收集一些手机信息。
还有其他一些代码的修改，就不多谈了，重点就是上面4点，这篇文章只给大家提供一些思路，每个项目都要单独的分析，不管是数据披露，SDK，还是代码，遇到类似这种警告问题，一定要把所有觉得有问题的点都要修改掉。
最后再提醒一句，我们的数据收集项有变化的话，一定记得修改数据安全，保持数据安全和隐私协议披露的一致！
朋友的app在7.23号新版本全量审核通过了，后续在有恶意软件相关信息和变动会置顶在评论区，也欢迎大家留言讨论，让更多人不再遇到恶意软件封号问题。
还有一些欺骗行为导致的封号或者应用暂停，我想和恶意软件是类似的。我们要根据欺骗行为政策和项目的具体情况来分析，尝试寻求解决方案。
深度思考
还是那句话，我们一定要保号，保号，保号。突然想起本山大叔小品里的一句话：人生最痛苦的是，人活着钱没了。而我们搞Google政策最痛苦的是：公司还在，Google账号和App包没了。我们可以再开发一个，但这个成本有点太高了。
另外，我想恶意软件问题最重要的点是恶意软件的防护，而不是解决，问题出了，对我们的业务不可避免的会产生较大影响。我们思考下，同行业那么多App，为什么Google会单单选中了你（大家都是类似的），是不是你的账号信誉被某些事件影响了（受到了严查），是不是你的App违规较多？
所以，我们一定要合规运营，尽量减少违规次数，避免我们的App收到Google的各种各样的违规警告（暂停应用）或者直接封号，好好的让App包在GooglePlay活着。
推荐阅读
End