OTA 更新引擎（update_engine）在往 Slot B 写入新系统时，发现当前 Slot A 启用了 overlayfs，为了防止动态分区的 Snapshot（快照）损坏，会直接拒绝并终止 OTA 升级！
overlayfs overrides are active and can interfere with our resources.
run adb enable-verity to deactivate if required and try again.
ErrorCode::kOverlayfsenabledError (64)
adb logcat -s update_engine
恢复 Verity 并禁用 overlayfs：
adb enable-verity
用一个最通俗的**“透明塑胶页”**比喻，你就能秒懂什么是 OverlayFS，以及为什么它会导致 OTA 更新失败。
一、 什么是 OverlayFS？（透明塑胶页）
OverlayFS（重叠文件系统）是 Linux 内核自带的一种技术。它的作用是：把一个只读的文件夹，和一个可写的文件夹“叠”在一起，变成一个新的文件夹。
在 Android 10 以后（动态分区）：
- 底层（Lowerdir）：原来的
/system分区（只读的，就像一本印刷好的书）。 - 顶层（Upperdir）：一个叫
scratch的隐藏分区（可写的，就像一张覆在书上的透明塑胶页）。 - 你看到的界面（Merged）：你透过塑胶页看书。
当你执行adb remount然后往/system里修改或添加文件时：
- 原始的
/system（书本）一点都没变（因为改不动）。 - 你修改的内容，全部被写到了那个隐藏的
scratch分区（写在了透明塑胶页上）。 - 系统运行时把两者叠在一起，让你“感觉”好像把
/system给改成功了。
二、 为什么开启 OverlayFS 后，OTA 更新就会报错？
既然原始分区没变，为什么 OTA 更新（update_engine）会报错kOverlayfsenabledError呢？
有3 个致命原因：
1. 占用了底层分区锁（Device Mapper 被锁定）
Android 的 A/B 升级需要使用Virtual A/B（快照机制）。
当update_engine准备把新系统写入 Slot B 时，它需要在底层的super.img（动态分区大本营）里重新申请空间、划分区块。
但是，OverlayFS 此时正强行占用着super.img的底层映射。就好像工人要拆楼重新造（OTA 写入），但房客（OverlayFS）还在房子里锁着门不出来。
2. 文件视图与真实物理磁盘不一致
- OTA 更新引擎需要操作的是真实的物理磁盘区块。
- 而 OverlayFS 呈现给系统的是**“原始磁盘 + 塑胶页”叠加后的虚假视图**。
如果此时直接强行写入新系统，极有可能导致内存与物理磁盘数据错乱，升级完直接开不了机（变成砖头）。
3. Google 的硬性安全拦截（防刷砖）
Google 考虑到上述风险，在 Android 的update_engine源码里写死了一行防御逻辑：
“在开始下载和写入 OTA 包之前，先检查 OverlayFS 是不是开着的。只要开着，为了防止把手机刷成砖，立刻停止更新，并报错
ErrorCode::kOverlayfsenabledError(64)！”
总结
- 开启 OverlayFS是为了方便开发者做
adb remount修改系统文件； - 关闭 OverlayFS（通过
adb enable-verity）是为了让系统恢复干净的只读状态，这样 OTA 升级引擎才能安全地对磁盘进行分区擦写。
