Android应用版本升级时如何覆盖原有预置SQLite数据库

未触发库替换的核心成因 #

出现升级后仍然使用旧10M库的问题，基本都是踩了三个通用实现漏洞：

• 大部分预置库逻辑仅在数据库文件首次不存在时，才会从assets目录拷贝预置文件，升级时旧的10M库文件已经存在，就直接跳过了拷贝流程
• SQLiteOpenHelper设置的数据库版本号没有和每次发版的预置库更新同步，导致版本变化时onUpgrade回调根本不触发
• 就算onUpgrade触发了，也没有写实际删除旧库、拷贝新库的逻辑，只保留了空的回调实现

适配业务需求的实现步骤 #

结合你方每次发版都要全量覆盖预置库、无需保留旧库业务数据的要求，按以下步骤实现即可：

• 强绑定数据库版本和应用版本
  不要给SQLiteOpenHelper设置和应用版本脱钩的自定义版本号，直接将DATABASE_VERSION配置为BuildConfig.VERSION_CODE，只要应用发生升级、versionCode变化，onUpgrade回调一定会正常触发，避免出现版本号错配导致回调失效的问题。
• 在onUpgrade回调中实现旧库全量清理
  因为业务不需要做旧库数据的增量迁移，不需要写ALTER TABLE、字段适配这类逻辑，直接在回调里关闭数据库连接，删除所有和旧库关联的文件即可，避免残留文件导致新库加载异常：

  @Override
  public void onUpgrade(SQLiteDatabase db, int oldVersion, int newVersion) {
      // 先断开当前数据库的所有连接
      db.close();
      // 获取数据库实际存储路径
      File dbFile = context.getDatabasePath(DATABASE_NAME);
      if (dbFile.exists()) {
          // 删除主库文件，以及WAL模式下关联的日志文件，否则删不干净
          dbFile.delete();
          new File(dbFile.getAbsolutePath() + "-wal").delete();
          new File(dbFile.getAbsolutePath() + "-shm").delete();
          new File(dbFile.getAbsolutePath() + "-journal").delete();
      }
  }
  

• 修正预置库的拷贝判断逻辑
  不要只靠“文件是否存在”决定要不要拷贝新库，搭配SharedPreferences做版本校验：每次完成预置库拷贝后，把当前应用的versionCode写入SP作为标记；下次打开应用初始化数据库前，对比SP里记录的版本和当前应用版本，只要不一致，不管旧文件是否存在，都重新从assets目录拷贝新的100M预置库。
  注意100M大库拷贝的两个关键细节：
  • 大库拷贝不要放主线程执行，避免触发应用ANR，同时拷贝过程要做完整性校验，对比本地拷贝完成的文件和assets中文件的MD5，确保没有拷贝残缺
  • 在项目的build.gradle中配置aapt规则，将预置的数据库文件设置为不压缩，避免assets压缩导致的拷贝时间过长、文件损坏问题，配置示例：

    android {
      aaptOptions {
          noCompress "db" // 按实际的预置库后缀配置
      }
    }
    

• 增加兜底检测逻辑
  要考虑特殊场景：比如渠道增量包安装、用户跳过版本回调、数据库文件被异常重建的情况，在Application初始化、数据库实例被首次创建前，再加一轮版本校验：如果检测到当前版本和SP记录的上次初始化版本不一致，直接走全量清库、拷贝新库的流程，不要完全依赖onUpgrade的回调逻辑，避免出现漏判。

按照这套逻辑实现，从4.20版本升级到4.21版本时，会自动触发旧10M库的全量清理，再把assets里的100M新预置库完整拷贝到私有目录，不会出现老库残留的问题。

避坑提示 #

• 不要把数据库放到公共存储目录，用系统提供的私有目录路径即可，既不需要申请额外的存储权限，也能避免库文件被其他应用篡改
• 因为每次发版都要全量替换库，完全不需要保留旧库的历史数据，不要叠加增量迁移逻辑，否则会平白增加问题排查的复杂度

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