特定联想/小米机型SQLite数据库文件莫名丢失问题求助

这种品牌定制ROM的「隐形」清理逻辑真的挺头疼的，我之前也碰到过类似厂商优化导致文件丢失的情况，给你几个具体的排查方向试试：

• 检查文件存储路径是否安全
  如果你把SQLite文件存在了外部存储的公共目录（比如Environment.getExternalStorageDirectory()），很多厂商的垃圾清理工具会扫描这些目录，把长时间未访问的文件判定为「无用缓存」自动删除。建议切换到应用专属的私有存储目录：

  • 内部私有存储：context.getFilesDir()，这个目录完全属于应用，系统和第三方工具不会随意清理
  • 外部私有存储：context.getExternalFilesDir(null)，同样属于应用私有，卸载时会被删除，但不会被系统垃圾清理误删

• 排查厂商的系统级清理策略
  联想、小米的系统都自带智能清理工具（比如小米手机管家、联想乐安全），这些工具可能把你的SQLite文件误识别为缓存。可以尝试：

  • 修改数据库文件名，避开「cache」「temp」这类容易被判定为缓存的关键词，比如改成app_core_data_v1.db
  • 在应用内添加引导，让用户将你的应用加入清理白名单（比如小米的「垃圾清理-设置-白名单」）
  • 找一台出现问题的真机，手动触发系统垃圾清理，尝试复现删除场景

• 监听文件变化并埋点日志
  既然你无法在测试环境复现，最好在用户设备上添加日志监控：

  • 每次应用启动时检查数据库文件是否存在，不存在则记录设备型号、系统版本、当前时间、最近应用后台状态
  • 使用FileObserver监听数据库文件的删除事件，当文件被删除时，记录删除触发的时机（比如是否在系统清理后、应用被后台杀死后）
    这些日志能帮你定位删除行为的触发条件

• 检查后台权限与系统限制
  部分厂商对后台应用的限制非常严格，当应用被强制杀死或进入深度休眠时，系统可能会激进清理应用相关文件：

  • 确保应用申请了「忽略电池优化」权限，避免被系统强制后台杀死
  • 引导用户开启应用的「允许后台运行」权限，减少系统对应用资源的清理力度

• 复查数据库操作的异常逻辑
  虽然你说代码中没有主动删除逻辑，但可以再仔细检查数据库相关代码：

  • 查看SQLiteOpenHelper的onUpgrade、onDowngrade方法，是否存在异常情况下的文件删除逻辑
  • 检查数据库打开失败时的错误处理代码，有没有误删文件的情况
  • 确认是否有第三方SDK（比如统计、缓存SDK）存在意外删除文件的可能

希望这些方向能帮你找到问题根源，要是有新的排查进展也可以补充信息~

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