OEM解锁

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 以后（动态分区）：

1. 底层（Lowerdir）：原来的/system分区（只读的，就像一本印刷好的书）。
2. 顶层（Upperdir）：一个叫scratch的隐藏分区（可写的，就像一张覆在书上的透明塑胶页）。
3. 你看到的界面（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 升级引擎才能安全地对磁盘进行分区擦写。