上篇聊了FB投放的坑，这篇聊点技术层面的。
很多做包的团队，包上去没两天就被下架了，然后跟甲方说“谷歌又严了”。甲方也不知道真假，只能认。
其实“谷歌又严了”这句话没有错，但严在哪里，大多数做包的自己都没搞明白。
我们2-3人，之前自己投过两年多BC，后来转做技术。这两年一直在测包、拆包、看谷歌到底在扫什么。说几个我们摸到的规律：
第一轮扫的是签名和证书 🎯
包提交上去，谷歌最先看的是签名方式和证书体系。市面上大多数包用的是公开方案或者网上扒下来的签名，这类特征谷歌早就建模了。只要特征匹配，连人工审核都到不了，系统直接拒。
我们拆了几十个被拒的包，发现签名这一步就被卡住的占了大半。
第二轮扫的是代码特征 🔍
过了签名这关，谷歌会跑自动化扫描。它不是把你的代码全部读完，而是抓特征片段——特定的函数调用、特定的网络请求写法、特定的类名组合。
比如某些第三方SDK的调用方式，谷歌已经录入了特征库。只要你的包里出现了这些特征组合，哪怕你把界面伪装得再像正常应用，照样被揪出来。
之前我们拆过一个包，界面完全伪装成天气应用，代码里该做的混淆也都做了，结果还是没扛过第二轮。后来一条条删代码去试，才发现是某个网络请求的写法被标记了。
第三轮是行为检测 👀
包上架之后，谷歌会定期拉活检测。不是光看你代码长什么样，而是看你跑起来之后的行为。
比如：
启动后有没有向特定服务器拉取配置
有没有动态加载远程代码
有没有在特定时间点切换界面内容
这些行为模式，谷歌全都有自动化脚本在跑。一旦触发了异常行为，轻则下架，重则连号一起封。
所以“存活30天”这件事，本质上是在和谷歌的三道关卡周旋。签名要做得干净、代码特征要避开已知指纹、运行时行为要足够自然。
我们能做到82%存活30天+，核心就是在这三层上反复测、反复调，测过的包多了，自然就知道边界在哪里。
以上是我们在测包过程中总结的一些经验，不一定全对，但都是真金白银烧出来的，希望能帮同行少走弯路。
有问题欢迎帖子里交流 🙏
纯手打，同行轻喷
