事情是这样的手头一个项目是二次开发包名沿用的是之前的签名是我在 Android Studio 里通过Create new新建的一个 keystore打包方式是Generate Signed App Bundle or APK走的 release 流程。打完包装到手机上安装界面直接弹出警告这个措辞比平时见到的未知来源谨慎安装严重得多直接说含有木马病毒让人没法不当回事。排查思路先搞清楚这个提示是谁判定的国产手机厂商的自带安全中心大多接入了腾讯手机管家的云端病毒库报警其实是云端那边的判定结果而不是手机本地单独分析出来的。接下来对照了一下自己项目的情况权限代码没有动过跟原作者原来的配置一模一样。这个项目用到的权限里有相机、短信默认拒绝、发送彩信默认拒绝以及读写剪贴板等。原作者打包的版本没有报病毒。这两点放在一起看权限、代码这些嫌疑基本被排除了——如果是权限或代码的问题原作者那份应该也会报但事实是原作者的包完全正常只有我重新打的这份报毒。唯一的区别就剩下包名沿用的是原来的但签名证书是我这次新建的跟原作者的证书不是同一个。找到病根签名和包名对不上查了一下才知道这种情况正好踩中了安全引擎里专门针对重打包木马的检测逻辑很多 Android 木马的套路就是拿一个已有的正常 APP注入恶意代码后保留原来的包名换一个新证书重新签名再分发这样用户表面上看不出区别。所以安全引擎会给已收录的应用记录一份包名 签名证书的绑定关系一旦扫描到包名对得上但签名对不上就会直接判定为疑似被篡改的应用风险等级拉满不需要再具体分析代码内容。这也对上了我的情况包名是老的签名是我新建的两者对不上触发的就是这条规则。解决办法最终选择了换一个全新的包名applicationId。逻辑是换了包名之后这个应用在安全引擎眼里就是一个全新的、跟原来完全没有关联的应用不会再拿它跟原来的签名记录做比对。结果换了包名之后问题解决了不再报毒。复盘整个问题的核心其实很简单同一个包名配上不一样的签名证书会被判定为疑似重打包的恶意应用跟代码里实际写了什么完全无关。这个坑比较隐蔽的地方在于权限没改、代码没动光看项目本身完全找不出问题因为矛盾根本不在代码里而在打包这一环——包名和签名的组合关系上。以后再遇到代码没动过却突然报毒的情况会先去对比签名和包名这一层而不是一头扎进代码和权限里找问题。