这种情况我之前帮同事排查过好几次，核心原因几乎都是系统误判两个应用是同一个App的不同版本——而系统识别App唯一性的关键就那几个点，咱们一步步拆解：

最常见的元凶：Application ID 重复 #

Android系统区分不同App的核心依据是applicationId（Gradle配置项），而不是Manifest里的package字段（这个现在主要用来命名资源类和R文件）。如果两个项目的Module级build.gradle里，defaultConfig下的applicationId设置成了完全相同的值，系统就会直接认为是同一个App，后安装的自然会覆盖前一个。

举个反例，两个项目都写了：

android {
    defaultConfig {
        applicationId "com.example.myapp" // 一模一样就会触发覆盖
        minSdkVersion 21
        targetSdkVersion 33
    }
}

Manifest的package字段间接“搞事”（旧项目兼容坑） #

如果你的项目是比较老的架构，或者没有显式设置applicationId，系统会默认把Manifest根节点的package值当作applicationId用。这时候如果两个Manifest的package字段完全相同，也会导致系统识别为同一个App。

看Manifest的根节点配置：

<manifest xmlns:android="http://schemas.android.com/apk/res/android"
    package="com.example.myapp"> <!-- 没设applicationId时，这个会被当作唯一标识 -->

少见但隐蔽的坑：签名一致 + 共享UserId #

如果两个应用使用了完全相同的签名证书，并且在Manifest里设置了相同的android:sharedUserId，系统会认为它们属于同一个“应用套件”，这时候安装第二个会直接替换第一个。

比如两个App的Manifest都写了：

<manifest xmlns:android="http://schemas.android.com/apk/res/android"
    package="com.app1"
    android:sharedUserId="com.my.shared.id">

再加上用了同一个签名（比如都用默认的debug keystore，或者同一个release证书），就会触发这个问题。

一步步排查思路 #

• 先查Application ID：打开两个项目的app/build.gradle（Module级），找到defaultConfig下的applicationId，确认两者完全不同。如果其中一个没显式设置，就看Manifest的package字段，确保两个值不一样。
• 再查签名与sharedUserId：检查两个项目的签名配置是否一致，同时看Manifest里有没有设置android:sharedUserId，如果有，确认两个项目的这个值是否相同。
• 终端验证包名：安装第一个App后，在终端执行adb shell pm list packages，找到它的包名；然后安装第二个App，再执行一次命令，看第二个App的包名是否和第一个重复——如果重复，就是applicationId的问题；如果不重复但还是被覆盖，那就是sharedUserId+签名的问题。
• 排除打包误操作：确认有没有把两个项目误打包成同一个App Bundle，或者打包时不小心改了applicationId配置。

总结一下，90%以上的情况都是applicationId重复导致的，剩下的大概率是sharedUserId和签名的组合问题。按照上面的步骤排查，应该很快能找到根源。

内容的提问来源于stack exchange，提问作者StanislavOssovsky