改系统字体之前，先把恢复路径设计出来

我开始做系统字体模块时，它看起来只是替换几个字体文件。真正实现后，我发现它会穿过 Android 字体回退、ROM 定制、WebView、启动阶段、Root 模块挂载和应用兼容等多层边界。错误不一定表现为“字体不好看”，也可能是 SystemUI 崩溃、浏览器文字异常或设备无法正常进入桌面。

我在 HybridFont 里最值得记录的，不是 Inter 与 Noto Sans SC 的组合，而是我在两天内改变了风险模型：从尝试更强的全局重定向，转向更保守的 systemless 资源覆盖与默认禁用测试包。

项目时间线

我先补上自动构建与发布，让模块能够生成可刷入包，并通过版本标签发布产物。

我一度加入 Zygisk 字体重定向包，随后在同一天将它标记为废弃并移除文档中的 Xposed 表述。原因很关键：全局文件访问 Hook 可能破坏 WebView 或嵌入式网页内容。

这不是“方案没写好”，而是方案的风险半径过大。继续修补 Hook 可能让单个设备工作，却很难证明跨 ROM、跨应用的稳定性。

我随后增加字体映射打包，并明确避免覆盖系统字体 XML。最终我发布了两种包：完整兼容包，以及默认禁用、跳过更激进 fallback 文件的 safe-disabled 包。

短时间内连续撤回高风险方案，是这个项目最有价值的工程动作。

Android 并不是简单地从 /system/fonts 找一个同名字体。系统存在字体家族、权重、脚本和 fallback 链，不同 Android 版本与厂商 ROM 还会调整 XML 配置。

Android 官方字体文档显示，Android 15 起可变字体配置进一步转移到 font_fallback.xml，而字体更新本身也需要签名与完整性验证。字体文件被官方视为需要谨慎校验的资源，而不是任意静态素材。

这意味着“把所有 font*.xml 一起覆盖”虽然直接，却会把 ROM 原有映射整个替换掉。它可能修复一个家族，同时破坏厂商新增的 emoji、区域字体或应用兼容路径。

KernelSU 模块机制与 Magisk 模块机制都允许在不直接写入真实系统分区的情况下覆盖文件。KernelSU 当前还通过 metamodule 提供 /system 挂载能力。

Systemless 带来两个重要优势：

但它没有自动保证兼容。覆盖层仍会在启动和应用运行时改变系统看到的资源；错误映射仍可能导致启动循环或界面崩溃。可逆不等于无风险，只是让恢复成为可能。

safe-disabled 包安装后不立即生效，用户先重启确认模块可识别，再手动启用并第二次重启。同时，它避免替换差异更大的 DroidSansFallback* 路径。

这套流程把一次高风险变更拆成两次可观察状态：

安装但不启用 → 确认模块存在 → 手动启用 → 检查关键应用

它牺牲了一点“一键完成”，换来更清楚的故障定位。如果第一次重启就异常，问题偏向安装或模块框架；如果启用后异常，问题偏向字体覆盖。

HybridFont 文档在安装章节直接给出恢复方式：通过 KernelSU 安全模式或 Recovery 创建模块的 disable 文件，也可以移除对应模块目录。

恢复说明应该满足四个条件：

任何会影响启动、网络、存储、权限或系统界面的工具，都应该在功能文档之前写恢复路径。

字体模块至少要跨越这些维度：Android 版本、ROM、Root 方案、挂载实现、WebView、语言脚本、可变字体、emoji 与厂商字体映射。

因此，“支持 Android 12+”并不是完整兼容声明。更有用的测试记录应该包含设备/ROM 版本、Root 与 metamodule 版本、启用的包类型、关键应用结果和恢复是否有效。

模块还应该避免与多个同时覆盖 font*.xml 的方案叠加。两个单独可用的模块，组合后可能互相覆盖。

HybridFont 的经验可以迁移到更多系统工具：

优秀的系统修改不是永不失败，而是把失败限制在可识别、可禁用、可恢复的范围内。