Android12 解决应用使用Settings异常断电数据丢失的问题

已于 2023-11-08 09:40:54 修改
阅读量1.6k 收藏 2
点赞数
分类专栏： Framework适配分享 文章标签： android
于 2023-11-08 09:40:08 首次发布
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/guanmingyuangmy/article/details/134281270
版权
本文探讨了Android应用在大屏设备异常断电时，使用Settings进行持久化存储可能导致数据丢失的问题。在Android12中，尽管AtomicFile能确保文件写入的原子性，但无法防止数据丢失。为解决此问题，文章提出了两种方法：在文件系统挂载时启用MS_DIRSYNC参数，或通过ioctl命令设置DIRSYNC模式。这两种方法分别具有性能损失和文件系统兼容性的权衡。

摘要生成于 C知道 ，由 DeepSeek-R1 满血版支持， 前往体验 >

在应用开发过程中，经常会做持久化保存，持久化一般分为SharedPreferences和Settings。但是遇到大屏等产品异常断电时，往往存储的数据会丢失甚至损坏。手机或平板没有这个问题是因为该类产品一般都有电池，不会出现异常断电的情况。

修改在最下面，主要修改底层文件系统。

对于SharedPreferences而言，只需要执行sync()操作就能强制把内容写到真是的屋里内存。但是Settings这种方式就不行，往往需要修改驱动才能解决。

在Android12中，Settings写操作在以下路径下，它是采用了AtomicFile的方式，这种方式可以避免断电文件损坏，但是避免不了刚写入的数据丢失。

路径：frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsState.java

    private void doWriteState() {
        boolean wroteState = false;
        final int version;
        final ArrayMap<String, Setting> settings;
        final
了解本专栏 订阅专栏 解锁全文 超级会员免费看
android app断电强制保存数据到磁盘(解决断电数据丢失的问题)
安卓兼职framework和app工程师的博客
09-14 3220
在应用开发中，保存数据一般会用到SharedPreferences和Settings.system来保存数据，而有的时候，保存的数据在断电关机的时候会丢失 所以就尝试用文本读写的方式保存数据 FileOutputStream流保存数据的时候 在关机前可以将缓存数据及时写入磁盘 1.写入数据 public void saveMusicPath(String musicpath){ /* Java 示例代码 */ FileOutputStream fostream = null; try { fos
Android 12 利用ext4格式改善Android数据分区f2fs断电丢失数据的问题
448313096@qq.com
12-04 2365
利用ext4格式改善Android数据分区f2fs断电丢失数据的问题
Android使用DataStore保存数据之后断电重启设备数据丢失临时解决办法
Felix的博客
12-26 971
这种解决办法呢，确实存在一些缺点。先说缺点的方面吧，它会导致双倍的存储时间，毕竟要同时往DataStore和里存储数据呀，这无疑增加了数据存储所耗费的时长。不过好在它不会阻塞UI，无论是读取数据还是写入数据，都是在协程中完成的，所以在操作过程中，用户界面不会出现卡顿之类的糟糕体验，这一点还是比较让人欣慰的。而说到优点嘛，暂时还真没怎么发现呢，也不确定它到底有没有其他突出的优势，目前来看，它最大的作用就是解决了在立即断电重启的场景下数据无法存储的问题，从这个角度讲，也算是达到了我想要的最基本的效果了。
Android App 设置系统时间，语言和时区、系统重启
记录移动开发相关的知识
11-01 5593
文章目录说明1. 修改系统时间1. 设置系统时间(仅设置xx:xx)2. 设置系统日期(仅设置到xxxx年xx月xx日)3.设置系统是否自动获取时间4.判断系统是否自动获取时间2. 修改系统时区1. 设置系统时区2. 设置系统是否自动获取时区3. 判断系统是否自动获取时区3. 修改系统语言4. 系统重启5. 源码6. 参考 说明 以下功能的实现是在有系统签名和设置了 android:sharedUserId=“android.uid.system” 的情况下实现的。如果你的应用没有系统签名，可能无法实现以下
AOSP Android framework中保存用户设置的值（SharedPreferences和Settings.Global方法对比）
weixin_52465385的博客
03-12 2328
SharedPreferences和Settings.Global的运用和方法对比。
android设备断电丢失数据（设备断电重启后WIFI不能自动重连）
qq_22985533的博客
03-07 8395
分析原因：经排查分析，这跟Linux的文件系统储存机制有关。用户层对文件进行写操作时，系统是先将文件存储在内存中，待CPU空闲后再将数据写入flash中，这是一种缓存机制，目的是提高文件的读写效率。 但对于特殊设备，例如：没有安装电池的设备，在突然断电的情况下就有丢失数据的风险。 第一种改法，直接在framework层直接修改： –a frameworks/opt/net/wifi/service/java/com/android/server/wifi/WifiNative.java ++b fram
android突然断电丢失数据,拔电数据没保存问题
weixin_43120264的博客
04-28 3147
android突然断电丢失数据,拔电数据没保存问题。 如果你也有碰到这个问题,可以先用sync命令一下就可以了 public static void syncDataCmd() { try { /* 對應斷電數據保存丟失問題 */ Runtime.getRuntime().exec("sync"); } catch (IOException e) { e.printStackTrace(); } } 希望帮到你! ...
ANDROID 设备写入文件，立即断电重启后，文件丢失，数据没有保存问题
qijingwang的博客
06-20 3181
android开发的过程中碰到写入文件后，立即断电重启，发现写入的文件丢失了
Android 11.0 Settings.System保存数据时在突然断电的时候数据丢失处理
最新发布
安卓兼职framework和app工程师的博客
04-25 137
在11.0的系统rom定制化开发中，在系统中保存数据的方法中，用Settings来保存数据的情况也是常用的功能， 但是在开发板开发中，在某些时候会发现突然断电保存的数据会丢掉，接下来分析下相关保存数据的流程， 实现相关功能
Android实现关机后数据不会丢失问题
08-25
Android 实现关机后数据不会丢失问题是指在 Android 应用程序中，如何在关机或异常情况下保存数据，以免数据丢失。本文将详细介绍如何使用 AndroidViewModel、SavedStateHandle 和 SharedPreferences 实现关机后...
android突然断电丢失程序,android 设备写入文件，立即断电重启后，文件丢失
weixin_39785081的博客
05-26 954
在android开发的过程中碰到写入文件后，立即断电重启，发现写入的文件丢失了写入时检查了，写入是没有失败的，经过查找资料可能是如下问题引起：Linux/Unix系统中，在文件或数据处理过程中一般先放到内存缓冲区中，等到适当的时候再写入磁盘，以提高系统的运行效率。可能是因为断电时，文件没有写入的物理介质中导致，解决办法如下：在write/fwrite写入后，添加fsync(), 这样可以将缓存中的...
Android设备断电开机后系统设置的选项状态不保存问题
hedalei的博客
06-24 728
跟踪状态值保存的文件，data/system/users/0目录下的文件settings_global.xml，settings_secure.xml，settings_system.xml这些文件里面的值都是有更改到的。查看了当前data分区的格式为f2fs，这种格式的文件系统写入后不会立马同步，这可能是导致断电设置状态不保存的原因。不带电池的Android设备，设置系统选项以后，断电开机，关机前设置的状态不会保存，又变成了设置前的状态。如果不断电关机，而是软重启，则重启前设置的状态是可以保存的。
Android11.0 立即断电重启，数据没保存
Framework-coder的博客
03-29 1468
应用升级后，断电重启版本恢复
Sqlite 断电数据丢失问题排查
qunimaode的博客
12-13 2217
sqlite SynchronousMode 模式影响
Android14 Settings属性断电上电不记忆问题分析解决
wenzhi的博客
08-18 1704
Android 系统如果修改了Settings属性后等几秒再断电上电会有属性未保存的情况。比如，开关wifi和时间同步等开关，修改开关状态后，进行断电上电关开机 会发现有状态不保存的问题。wifi开关或者同步时间开关这些数据都是Settings.Global属性保存在data目录下的文件数据。一般手机和平板断电不换马上关机，是有大屏设备或者机顶盒等设备会出现这个问题。之前Android9不记得是否会有这个问题了，但是Android13 和 Android14 是必现的。
Android12 framework部分第三方APP断电后再次打开闪退的问题
guanmingyuangmy的博客
12-18 714
有一些第三方app如鲜时光，腾讯视频等会有这么一个场景，打开这些APP之后突然断电，再次上电，这些APP打开之后就闪退无法再次打开了。一般情况下，对于我们自研的APP来说，在write()方法后close()数据流之前sync()一下就行了，比如系统默认设置在设置12/24小时制或者是设置静态IP动态IP后就会出现这种情况，也可以用这种方式解决。但是这种第三方的，我们无法控制，而且这两个APP还比较特殊，它们都是用了FilterOutputStream写数据的，所以需要在这个类里进行修改。
android 10突然断电拔掉电源 保存图片数据的问题
Android framework
03-22 396
android 10突然断电拔掉电源 保存图片数据的问题
Android12 命令安装app后，马上断电重启，APP消失
ewin2012的专栏
07-24 1194
Android12 命令adb install ... 安装app后，马上断电重启，APP消失问题。
关机流程中先进行Settings.System.putInt写入数据，然后再执行关机操作，为什么有时候会出现数据还未写入设备就关机的情况？Settings.System.putInt不是同步的吗？
03-08
<think>嗯，用户问的问题是关于Android关机流程中，使用Settings.System.putInt写入数据后执行关机，有时候数据没保存的问题。首先，我需要回忆一下Settings.System.putInt的工作机制。用户之前已经了解过这个方法是同步的，所以理论上调用后数据应该已经写入数据库了。但现在出现数据未保存的情况，可能存在其他原因。 首先，我应该考虑Android系统的关机流程是怎样的。关机时系统会终止各个进程，可能包括系统服务，比如负责处理设置写入的ContentProvider或者SystemServer中的相关部分。如果关机流程在putInt调用之后很快开始，可能导致ContentProvider还没完成写入就被终止了，尽管putInt是同步的，但可能系统层面的处理有延迟或者异步步骤。 另外，ContentResolver的apply和commit的区别也可能相关。虽然putInt内部可能使用的是commit，但需要确认其具体实现。如果是apply的话，虽然是异步的，但根据文档，putInt应该是同步的。所以这里可能需要查看源码确认。 另外，系统服务可能在关机时被快速终止，导致即使putInt返回成功，但数据还没持久化到磁盘。因为数据库写入可能先到内存，再异步刷盘。这时候如果系统突然断电，数据就会丢失。这种情况即使在同步方法中也可能发生，因为同步只保证数据提交到数据库事务，但事务的持久化可能需要时间。 用户可能没有意识到，即使同步方法返回成功，数据可能还在内核的页面缓存中，没有真正写入磁盘存储。因此，在关机时，如果系统立即断电，这部分数据可能丢失。需要解释数据库写入的机制和持久化的保证。 此外，Android的Settings Provider可能有自己的缓存机制，或者某些设置需要额外的步骤才能生效，比如广播或者重启服务。如果在写入后没有正确触发这些步骤，即使数据保存了，可能在下一次启动时没有正确加载。 可能的解决方案包括在写入后调用ContentResolver的update或者确保数据库立即刷盘，或者使用更底层的API，或者在关机流程中增加延迟等待数据持久化完成。但需要指出这些方法在普通应用中的可行性，因为普通应用可能没有权限修改关机流程或者访问底层API。 需要验证putInt是否确实同步写入磁盘，或者是否依赖系统服务的响应。可能SystemServer在关机时处理请求的队列被中断，导致尽管putInt返回成功，但实际上系统服务未能处理该请求。 总结，可能的原因包括：1. 系统服务在关机时被终止，导致写入未完成；2. 数据库写入到内存缓存但未刷盘；3. 设置需要额外步骤生效。需要逐一分析，并给出相应的解释和建议。</think>`Settings.System.putInt()` 确实是同步方法，理论上调用后数据会立即写入系统数据库 (`settings.db`)，但在**关机流程中仍可能出现数据未保存**的情况。以下是可能原因及技术细节分析： --- ### 一、同步方法的局限性 #### 1. 数据库事务的持久化延迟 - **同步 ≠ 立即刷盘** `putInt()` 的同步性仅表示调用线程会等待数据库事务提交完成，但数据库底层可能仍存在**内核页面缓存（Page Cache）**未真正写入物理存储。Android 的 SQLite 默认使用 `PRAGMA synchronous = FULL`，但事务提交后仍需依赖系统调度将缓存数据写入磁盘。 - **关机断电导致缓存丢失** 若在数据从缓存刷入磁盘前断电，写入会丢失。这是所有文件系统面临的共性问题，并非 Android 特有。 #### 2. 系统服务的生命周期 - **Settings Provider 进程被提前终止** `Settings.System.putInt()` 的底层实现通过 Binder 调用系统服务 `SettingsProvider`（运行在 `system_server` 进程）。在关机流程中，`system_server` 可能优先被终止，导致尚未完成的数据库操作被中断。 --- ### 二、关机流程的特殊性 #### 1. 关机时序问题 Android 关机流程会触发以下关键步骤： 1. 广播 `ACTION_SHUTDOWN`，通知应用和服务保存数据； 2. 终止非关键系统服务（可能包括 `SettingsProvider`）； 3. 卸载文件系统，同步缓存到磁盘； 4. 内核关闭硬件。 若 `putInt()` 调用发生在步骤 2 之后，`SettingsProvider` 已终止，写入操作将直接失败。 #### 2. 文件系统卸载的不可逆性 - **卸载文件系统后无法写入** 在关机后期，文件系统会进入只读模式或直接卸载。此时即使 `putInt()` 成功返回，底层文件操作也会因存储不可写而静默失败。 --- ### 三、验证与解决方案 #### 1. 验证数据是否真正持久化 可通过以下命令检查 `settings.db` 的修改时间： ```bash adb shell su root ls -l /data/system/users/0/settings_system.xml ``` 若关机后时间戳未更新，说明数据未写入。 #### 2. 解决方案 1. **强制同步文件系统** 在 `putInt()` 后调用 `sync` 命令强制刷盘： ```java Runtime.getRuntime().exec("sync"); ``` *注意：需要 `root` 权限，普通应用无法使用。* 2. **提前触发关机前的数据保存** 在接收到 `ACTION_SHUTDOWN` 广播时尽早执行关键数据写入： ```java BroadcastReceiver shutdownReceiver = new BroadcastReceiver() { @Override public void onReceive(Context context, Intent intent) { Settings.System.putInt(resolver, "KEY", value); } }; context.registerReceiver(shutdownReceiver, new IntentFilter(Intent.ACTION_SHUTDOWN)); ``` 3. **使用更底层的 API（需系统权限）** 系统应用可通过直接修改 `settings_system.xml` 或调用 `Settings.Global.putString()` 的 `makeDefault` 方法，强制生成默认配置文件。 --- ### 四、总结表 | 现象 | 根本原因 | 解决方案 | |--------------------|----------------------------|-----------------------------------| | 数据写入后丢失 | 内核缓存未刷盘 | 调用 `sync`（需 root） | | `putInt()` 返回失败 | SettingsProvider 进程已终止 | 提前在 `ACTION_SHUTDOWN` 阶段保存 | | 设置未生效 | 依赖服务的重启逻辑未触发 | 发送广播通知系统（如 `AIRPLANE_MODE_CHANGED`）| --- ### 示例：改进后的关机数据保存逻辑 ```java public void safeShutdownWrite(Context context) { ContentResolver resolver = context.getContentResolver(); // 1. 同步写入设置 Settings.System.putInt(resolver, "SENSITIVE_KEY", 1); // 2. 强制刷盘（需要系统权限） if (hasRootPermission()) { Runtime.getRuntime().exec("sync"); } // 3. 延迟关机确保操作完成 new Handler(Looper.getMainLooper()).postDelayed(() -> { PowerManager pm = context.getSystemService(PowerManager.class); pm.shutdown(false, "user request", false); }, 1000); // 延迟 1 秒 } ``` *注意：此代码需要系统签名或 root 权限，普通应用无法实现完整流程。* 若您需要进一步分析具体场景（如系统定制开发），可提供更多日志细节。
评论 3
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

Frame Not Work

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付：¥1
获取中
扫码支付

您的余额不足，请更换扫码支付或充值

打赏作者

实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值