3分钟快速实现Android recovery恢复出厂设置保存自定义文件在Android AOSP开发过程中，我们可能会

前言

由于最近在折腾Android Framework相关内容，弥补自己的一些空白领域，所以有一段时间没有更新内容了，现在告一段落了，赶紧给大家分享一下自己的一些心得内容吧，也欢迎大家多多交流经验~

在Android AOSP开发过程中，我们可能会遇到当系统被格式化时，还需要保留一些特定的数据文件的需求，遇到这种需求我们能实现吗？如果能实现是你会选择怎样的方式进行呢？

其实这个实现方案也有不少，这里简单介绍几种个人想到的吧：

将数据保存在TF卡这种外部存储中，Android系统在恢复出厂设置格式化数据时，不会对TF进行格式化，所以你的数据依旧会保留下来。

优势： 无需改动代码，直接可实现保存数据的目的。

劣势： 不同系统/应用在针对TF进行操作的时候，可能会因为挂载时序问题，导致TF在需要使用时处于不可用状态。

这个方案主要是将系统调用格式化的方法注释掉，然后自己读取对应分区，在排除目标文件的情况下，递归删除其他文件。

优势： 自定义灵活、可控。

劣势： 由于不是直接格式化分区，所以在时效性上相对较差，同时也存在一定的代码逻辑风险。

这个方案在我看来是目前最佳的方案，也是AOSP中存在类似实现的方案，主要流程就是在执行格式化分区前，针对目标文件进行读取到内存，然后执行格式化后，重新从内存中读取写入分区原始路径中。 优势： 改动最小，对系统代码影响最小，实现效果也是最佳的。

劣势： 一些特定目录受SELinux权限策略的影响，不具备读写权限，需要额外调整SELinux权限策略。

我这边采取的是方案三进行实现，所以后续也仅仅针对方案三进行介绍，对其他方案有兴趣的，欢迎交流！

在Android系统进行恢复出厂设置时，将目标目录的文件先读取到内存中，然后等待对应分区格式化完成后，重新复制到原始路径下，这样就可以在保证格式化效率的前提下快速实现保存目标。

注：这也是目前Android AOSP源码中针对recovery模式下相关日志的官方保存方案。

Android系统最终的格式化数据时在wipe_data.cpp的EraseVolume方法中实现的，所以我们可以直接在这个方法里面去改或者修改调用的地方做改动即可。

// 格式化执行类
bootable/recovery/install/wipe_data.cpp

// 读取文件，恢复文件类
bootable/recovery/otautil/logging.cpp

// 头文件
bootable/recovery/otautil/logging.h

以下是系统读取日志文件到内容的方法，我们完全可以复制重写一份读取我们目标文件的方法。

修改点：

序号	修改点	修改方式
1	ensure_path_mounted("/cache");	/cache改为你的目标分区，确保目标分区已挂载
2	CACHE_LOG_DIR	改为你的目标文件目录

以下是系统将读取到内存中的日志文件恢复到系统中的方法，同样我们只需要仿写一个就行了。

修改点：

序号	修改点	修改方式
1	ensure_path_mounted(CACHE_LOG_DIR)	/CACHE_LOG_DIR改为你的目标目录，确保目标已挂载
2	CACHE_LOG_DIR	改为你的目标文件目录
3	reset_tmplog_offset	这个可以不用了
4	copy_logs	这个可以不用了

别忘了将方法名添加到头文件loggin.h中，这样便于格式化方法调用。当然如果你不是写在logging.cpp类中的，就根据自己实际的代码去调整即可。

这一步主要涉及到wipe_data.cpp类的EraseVolume方法，当然也可以在调用栈的合适地方去增加。如下代码我是在cache中新增了一个自定义目录，在格式化前后进行读取和备份。

由于个人之前对Framework没有过多的研究，所以在这个过程中踩过非常多的坑，比如保存时机的选择错误、SELinux权限限制无法读写文件、SELinux权限调整失败等等...

最大的限制其实就是SELinux权限限制，不允许我们针对/data目录去做处理，但是我们可以去调整权限策略，或者在/cache或者其他目录去做处理，都是可以的，具体的调整方式当前就不做过多介绍了，后续会有专门的SELinux策略调整介绍。

本文首发于个人微信公众号【一念杂记】，欢迎关注，第一有时间了解更多分享内容3分钟快速实现Android recovery恢复出厂设置保存自定义文件

如果大家还有其他更好更高效的方案，也欢迎评论、留言、私信分享交流~