我之前也碰到过一模一样的情况，在Android 7.1（API25）和8.0（API26）的模拟器甚至部分真机上，明明已经关掉自动时间和时区，改完时间后System.currentTimeMillis()也返回正确值，结果一重启就回滚到旧时间，这其实是这个版本区间系统时间持久化机制的常见坑，结合我的排查和解决经验，给你几个可行的方案：

一、模拟器专属修复方案 #

API25/26的模拟器虚拟硬件时钟（RTC）经常会出现修改后不持久化的问题，你可以通过adb命令强制写入修改后的时间：

1. 打开终端，连接到模拟器：adb shell
2. 手动设置系统时间（替换成你需要的时间格式，比如20240520 11:20:00）：date -s "20240520 11:20:00"
3. 将系统时间同步到硬件时钟，确保重启后不会丢失：hwclock -w

执行完这几步后重启模拟器，时间就不会再回滚了，System.currentTimeMillis()也会返回正确的修改后时间。

二、真机场景排查方向 #

如果是真机出现这个问题，大概率是系统后台的时间同步服务在偷偷工作，即使你关闭了系统设置里的自动时间：

• 首先检查厂商定制ROM的隐藏设置：有些厂商会在「开发者选项」里保留时间同步的开关，或者在「应用管理」里找到和时间相关的系统服务（比如Google Play服务的「时间同步」组件、厂商自带的「时钟服务」），强制停止并禁用其后台运行权限。
• 另外，部分机型需要你在修改时间后，手动重启一次系统服务（可以通过adb shell am restart命令，或者直接重启设备），确保修改的时间被正确写入硬件时钟。

三、应用代码层面的规避方案 #

如果你的应用依赖准确的时间，不想受系统时间回滚影响，可以做个简单的持久化处理：

1. 当用户手动修改时间后，将当前的System.currentTimeMillis()值保存到SharedPreferences或者本地文件中。
2. 应用启动时，读取这个持久化的时间，和当前系统的System.currentTimeMillis()对比：
   • 如果系统时间比持久化时间早很多（比如差了1小时以上），说明系统时间被回滚了，此时可以用持久化的时间作为应用内的时间基准。
   • 当然，这个方案需要用户确认之前修改的时间是正确的，避免出现时间偏差。

补充说明：Android 7.1到8.0这个版本段确实存在时间持久化的已知bug，主要是关闭自动时间后，系统没有正确将修改的时间写入硬件RTC模块，导致重启后恢复到之前的时间状态。

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