当然可以实现！问题的本质是Android系统通过「包名+签名证书」来唯一识别应用——你修改包名后，系统会把新构建的版本判定为完全独立的新应用，所以才会出现两个并行安装的情况。要实现像常规更新那样覆盖旧应用并保留数据，分两种场景处理：

场景一：可以改回旧包名（最推荐） #

这是最简单直接的方案，完全符合Android的更新逻辑：

• 把项目中所有涉及包名的配置改回原来的旧包名（包括Java/Kotlin文件的包路径、AndroidManifest.xml里的package属性、build.gradle里的applicationId等）
• 用和旧应用相同的签名证书构建安装包（debug包默认用同一个debug签名，release包要确保用之前的release密钥）
• 正常安装到设备上，系统会自动覆盖旧应用，所有本地数据（SharedPreferences、数据库、文件等）都会完整保留，和常规更新完全一致。

场景二：必须使用新包名（无法改回） #

如果因为业务需求必须保留新包名，就需要做数据迁移，步骤如下：

方法1：通过adb备份迁移（适合开发调试场景） #

• 确认旧应用开启了备份功能：检查旧应用的AndroidManifest.xml，确保android:allowBackup="true"（默认开启，若被手动关闭需打开）
• 导出旧应用数据：在电脑终端执行命令

  adb backup -noapk com.old.package.name
  

  设备会弹出确认备份的弹窗，直接确认即可（不要设置备份密码，避免后续恢复麻烦），备份文件会保存在电脑的用户目录下，名为backup.ab
• 修改备份文件的包名：
  1. 把ab格式转成tar格式：

     dd if=backup.ab bs=1 skip=24 | openssl zlib -d > backup.tar
     

  2. 解压backup.tar，找到apps/com.old.package.name目录，重命名为apps/com.new.package.name，同时修改解压后manifest.xml里的包名字段为新包名
  3. 重新打包成tar，再转成ab格式：

     openssl zlib -in backup.tar | cat <(printf "\x41\x42\x30\x31") - > new_backup.ab
     

• 安装新包名的应用到设备，然后执行恢复命令：

  adb restore new_backup.ab
  

  设备确认恢复后，旧应用的数据就会迁移到新应用中，之后可以卸载旧应用。

方法2：发布过渡版本（适合面向用户的正式版本） #

如果你的应用已经发布给用户，不能让用户用adb命令操作，可以：

• 先发布一个基于旧包名的过渡版本，在版本中添加数据导出功能（比如把SharedPreferences、SQLite数据库导出到设备的外部存储目录）
• 让用户更新到这个过渡版本，执行数据导出操作
• 再发布新包名的正式版本，添加数据导入功能，让用户把之前导出的数据导入到新应用中
• 用户完成导入后，就可以卸载旧包名的应用，使用新应用。

关键注意事项 #

• 无论哪种方案，签名证书必须和旧应用完全一致！如果签名变更，哪怕包名相同，系统也会拒绝覆盖安装，提示安装失败。
• 调试阶段使用debug签名时，确保所有构建都用同一个debug密钥（Android Studio默认会用同一个debug密钥，除非你手动修改过）。

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