Android应用升级时数据库莫名重建致数据丢失，求排查原因

看起来你遇到了升级时旧数据丢失的棘手问题，结合你描述的情况（版本号未变、签名一致、开发版本清正式版数据），我整理了几个常见但容易忽略的原因，你可以逐一排查：

• 数据库文件路径不一致
  当你升级target API到更高版本时（比如从25升到30+），Android的存储机制有不少变化。如果旧版本用的是外部存储路径（比如getExternalFilesDir()），而新版本因为权限限制切换到了内部存储（getDatabasePath()），或者代码中获取数据库路径的方式发生了细微变化（比如硬编码路径时写错了包名），系统会找不到旧的数据库文件，从而触发onCreate重建。
  建议在新旧版本中分别打印数据库的绝对路径（用context.getDatabasePath(DB_NAME).getAbsolutePath()），对比是否完全一致。

• 数据库文件名拼写/大小写错误
  有些Android设备的文件系统是区分大小写的，如果旧版本用的是MyAppDB.db，新版本不小心写成MyappDb.db（大小写差异），系统会认为这是两个不同的文件，自然找不到旧数据库，直接新建。
  仔细核对SQLiteOpenHelper构造函数里传入的数据库名称，确保新旧版本完全一致，包括后缀和大小写。

• 代码中存在意外删除数据库的逻辑
  检查新版本的代码，有没有在启动、升级流程中加入删除旧数据库的逻辑（比如测试时留下的调试代码），或者因为权限变更，导致应用无法读取旧数据库文件，系统自动将其标记为不存在并重建。
  你可以通过adb shell手动查看旧版本安装后的数据库文件是否存在：

  adb shell ls /data/data/你的包名/databases/
  

  然后升级新版本后再查看，确认文件是否被删除或无法访问。

• SQLiteOpenHelper的构造参数或打开flags变化
  虽然你说数据库管理类没变更，但有没有可能在调用getWritableDatabase()或getReadableDatabase()时传入了不同的flags？比如旧版本用的是默认参数，新版本加了SQLiteDatabase.NO_LOCALIZED_COLLATORS这类可能影响数据库打开的flag，导致旧数据库无法正常打开，触发重建。
  另外，检查onConfigure方法里的设置，有没有新增可能导致数据库兼容性问题的配置（比如开启WAL模式但旧版本没开启？不过WAL模式一般不会导致重建，但可能影响读取）。

• 多进程访问导致的问题
  如果新版本引入了多进程架构，而旧版本是单进程，当多个进程同时访问数据库时，可能出现锁或无法读取的情况，系统会尝试重建数据库。这种情况下，需要确保数据库的多进程访问配置正确（比如使用enableWriteAheadLogging()）。

排查时建议先从路径和文件名入手，这两个是最常见的“隐形”问题。如果找到问题，比如路径不一致，可以在新版本中先将旧路径的数据库文件迁移到新路径，再进行正常操作，避免数据丢失。

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