事情是这样的

手头一个项目是二次开发，包名沿用的是之前的，签名是我在 Android Studio 里通过 Create new 新建的一个 keystore，打包方式是 Generate Signed App Bundle or APK 走的 release 流程。打完包装到手机上，安装界面直接弹出警告：

这个措辞比平时见到的“未知来源，谨慎安装”严重得多，直接说“含有木马病毒”，让人没法不当回事。

排查思路

先搞清楚这个提示是谁判定的：国产手机厂商的自带安全中心大多接入了腾讯手机管家的云端病毒库，报警其实是云端那边的判定结果，而不是手机本地单独分析出来的。

接下来对照了一下自己项目的情况：

• 权限代码没有动过，跟原作者原来的配置一模一样。这个项目用到的权限里有相机、短信（默认拒绝）、发送彩信（默认拒绝），以及读写剪贴板等。
• 原作者打包的版本没有报病毒。

这两点放在一起看，权限、代码这些嫌疑基本被排除了——如果是权限或代码的问题，原作者那份应该也会报，但事实是原作者的包完全正常，只有我重新打的这份报毒。

唯一的区别就剩下：包名沿用的是原来的，但签名证书是我这次新建的，跟原作者的证书不是同一个。

找到病根：签名和包名对不上

查了一下才知道，这种情况正好踩中了安全引擎里专门针对“重打包木马”的检测逻辑：很多 Android 木马的套路就是拿一个已有的正常 APP，注入恶意代码后保留原来的包名，换一个新证书重新签名再分发，这样用户表面上看不出区别。所以安全引擎会给已收录的应用记录一份“包名 + 签名证书”的绑定关系，一旦扫描到包名对得上但签名对不上，就会直接判定为“疑似被篡改的应用”，风险等级拉满，不需要再具体分析代码内容。

这也对上了我的情况：包名是老的，签名是我新建的，两者对不上，触发的就是这条规则。

解决办法

最终选择了换一个全新的包名（applicationId）。逻辑是：换了包名之后，这个应用在安全引擎眼里就是一个全新的、跟原来完全没有关联的应用，不会再拿它跟原来的签名记录做比对。

结果：换了包名之后，问题解决了，不再报毒。

复盘

整个问题的核心其实很简单：同一个包名配上不一样的签名证书，会被判定为疑似重打包的恶意应用，跟代码里实际写了什么完全无关。这个坑比较隐蔽的地方在于，权限没改、代码没动，光看项目本身完全找不出问题，因为矛盾根本不在代码里，而在打包这一环——包名和签名的组合关系上。

以后再遇到“代码没动过却突然报毒”的情况，会先去对比签名和包名这一层，而不是一头扎进代码和权限里找问题。