之前在瞬联Google 3PL项目组（Google官方授权的第三方实验室（3PL）服务团队）做应用合规审查工作的时候，我主要工作之一就是复核机器审核的判定结果，每天经手几十个被机器标红的包。看久了会发现一些规律，分享几点观察，供参考。
一、特征库本质上是哈希+规则的组合
很多人以为Google的特征库是AI在跑，其实准确说应该是：大量人工标注的样本 + 固定的提取规则 + 少量的机器学习辅助。
特征库里存的不是完整的代码，而是：
特定类名+方法名的组合哈希
特定字符串拼接模式的规则表达式
特定调用链路的指纹（比如 A→B→C 三个方法按特定顺序调用）
这意味着：你改一个变量名没用，改一个方法名也没用。 因为系统抓的是调用链路和组合模式，不是单个名字。
我们那时候做过测试：把同一个违规包做10个版本，每个版本只改表面变量名，结果10个全部被机器标红。改动量低于30%的混淆，在系统眼里和原包几乎没有区别。
二、动态检测的几个具体维度
Google的动态检测是在沙箱里跑应用，但沙箱的运行时间是有限的。我们当时看到的内部数据是：每个包在沙箱里的运行时长大概在3-5分钟。
系统在这几分钟里主要抓几个东西：
第一个网络请求的URL
包启动后第一个网络请求打到哪里，是系统重点记录的。如果这个URL的域名和已知违规包的域名在同一个C段、或者注册信息有重合，会触发标记。
一定时间窗口内的行为序列
比如：启动→申请权限→静默→拉取远程配置→展示内容。这个行为序列的顺序和时间间隔，会被记录成一个行为向量。如果向量和已知违规包的行为模式相似度超过阈值，会被标黄。
系统API的调用频率
比如在短时间内多次调用PackageManager的getInstalledPackages方法、或者多次调用Runtime.exec()，这些异常的API调用频率会被记录。
三、权重系统的几个细节
Google Play的开发者账号权重系统不是单一的分数，而是由多个维度构成的：
账号年龄： 注册超过1年的号，基础权重高于新号
发布历史： 有稳定发布记录的号，系统信任度更高
付款记录： 有过正常付费行为的号（比如付过注册费、买过推广），权重会提升
关联账号： 一个IP、一个设备下注册的多个号之间会有关联关系，一个号出问题，关联号会被连带降权
账号活跃度： 定期登录、有正常的操作行为（不只是提交包），系统会判定为“真人操作”
我们当时在3PL团队内部讨论过一个案例：同一套代码、同一个混淆方案，用新号提交被机器秒拒，换了一个有两年历史的号重新提交，过了。除了账号权重，其他变量完全一致。
四、机器过审后的存活逻辑
很多人以为“过了机器审核就等于安全了”，其实不是。
机器审核过了，包进入可下载状态，但Google的系统会持续监控：
第一周： 行为检测持续运行，如果包在线上表现出异常行为（比如审核期间展示A面、过审后切B面），系统会捕获并触发二次审核
第二周起： 定期抽样复检，频率大概在每7-15天一次，具体频率取决于账号权重——权重越低的账号，复检频率越高
所以“存活30天”本质上不是一次性过关，而是每一次复检都要过。
这也是为什么很多包第一周跑得好好的，第二周突然死了——不是Google突然严了，而是到了固定的复检节点，被扫到了。
以上都是我们在瞬联做合规审查那几年积累下来的一些观察，都是基于真实case总结的，希望能帮到正在踩坑的同行。
