先给你明确结论：给主Activity添加<category android:name="android.intent.category.DEFAULT"/>完全无法解决图标混淆问题。这个Category的作用是让Activity支持隐式Intent启动，和桌面Launcher生成应用图标的逻辑没有半毛钱关系——桌面图标是靠MAIN+LAUNCHER的Intent Filter来识别生成的，和DEFAULT Category无关。

为什么更新后会出现图标混淆？ #

大概率是这几个原因：

• 第三方Launcher缓存bug：部分Launcher在应用更新后没有正确刷新两个入口的图标资源，直接复用了旧缓存，导致两个入口显示同一个图标
• Task Affinity潜在冲突：虽然你给两个Activity设置了不同的taskAffinity，但如果其中某个值和应用包名重叠，或者部分Launcher对taskAffinity的识别逻辑有差异，可能会把两个入口归为同一类
• 图标资源打包问题：检查@mipmap/icon、@mipmap/icon2等资源是否在打包时被意外覆盖，比如不同分辨率目录下的资源重名，导致打包工具优先级替换

正确的解决思路 #

1. 强化两个入口的唯一性配置 #

确保两个Launcher Activity的核心标识完全独立：

• 确认android:label、android:icon、android:roundIcon各自指向不同的资源，且资源文件命名无重复
• 检查taskAffinity是完全唯一的字符串，避免和应用包名一致（你的配置里用com.test.testpackacge.activity和com.test.testpackacge.activity2是没问题的，但要核对拼写无错误）
• 可以给每个Activity额外添加android:persistableMode="persistAcrossReboots"，帮助系统更稳定地识别独立入口

2. 处理Launcher缓存问题 #

• 应用更新时，可以发送广播通知Launcher刷新快捷方式：

  Intent intent = new Intent(Intent.ACTION_PACKAGE_CHANGED);
  intent.setData(Uri.parse("package:" + getPackageName()));
  sendBroadcast(intent);
  

• 引导出现问题的用户手动清除对应Launcher的缓存（不同手机路径略有差异，一般是设置→应用→找到对应Launcher→存储→清除缓存）

3. 排查构建打包环节 #

检查你的构建脚本（比如build.gradle）是否有资源合并规则，导致图标资源被意外替换；确认不同渠道包的资源是否一致，避免渠道打包时覆盖图标。

是否需要用Flavor或双Manifest？ #

如果你的两个Launcher入口是同一个应用内的功能入口，完全不需要用Flavor或者双Manifest——当前的单Manifest配置就足够支撑需求。只有当你需要构建两个完全独立的应用变体（比如免费版/付费版、不同渠道专属版本）时，才需要考虑用Flavor拆分构建或者使用多个Manifest文件。

总结一下：别在DEFAULT Category上浪费时间，聚焦资源唯一性、Task Affinity检查和Launcher缓存处理，Flavor不是当前场景的必要方案。

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