Thanox 两层架构：Framework 层与 App 层的数据如何分离
架构全貌
Thanox 的整体架构分为两层：
| 层级 | 运行位置 | 权限级别 | 职责 |
|---|---|---|---|
| Framework 层 | system_server 进程 | system 权限 | 所有核心管理逻辑 |
| App 层 | 普通应用进程 | 普通应用权限 | UI 交互、配置写入 |
两层之间通过 IPC（进程间通信）交互——App 层写入配置，Framework 层读取配置并执行对应的拦截或操作。
Framework 层做什么
Framework 层是 Thanox 的大脑，承担以下职责：
- Hook 系统 API：拦截
startActivity、startService、bindService、sendBroadcast等关键系统调用，实现后台启动拦截。 - 强制杀进程：根据后台运行和任务清理的配置，调用 ActivityManagerService 的 forceStopPackage。
- 监听生命周期：通过
ActivityLifecycleCallbacks获取 Activity 的 Created / Resumed / Paused / Destroyed 事件。 - 隐匿敏感数据：Hook
TelephonyManager、Build等类，返回虚拟的设备标识。 - 规则引擎执行：情景模式的 facts 事件发布和 actions 动作执行。
- 智能冻结：通过 PackageManager 的
setApplicationEnabledSetting实现 PM Disable 冻结，或调用 DevicePolicyManager 实现 Suspend 冻结。
App 层做什么
App 层就是用户日常打开的那个 Thanox 应用，它是一个标准的 Android 应用：
- 提供设置界面：所有功能的开关、白名单、黑名单、规则编辑都通过 App 层的 UI 完成。
- 写入配置到 Framework 层：App 层通过 IPC 把用户配置同步给 Framework 层。
- 显示日志和统计：启动记录、冻结状态、情景模式执行历史等。
- 导出 Magisk 补丁：App 层提供一键导出 Magisk 模块补丁的功能。
数据存储分离
因为两层运行在不同进程，数据也分两部分存储：
| 数据位置 | 路径特征 | 存什么 | 清除 App 数据会清掉吗 |
|---|---|---|---|
| Framework 层 | /data/system/thanos${16位随机字母}/ | 所有功能的配置数据（后台启动规则、冻结列表、隐匿模板、情景模式等） | 不会 |
| App 层 | App 的私有数据目录 | UI 相关的轻量配置（首页布局、偏好设置等） | 会 |
这是一个重要的设计优势：如果你不小心清除了 Thanox App 的数据，核心功能的配置不会丢失——Framework 层的数据不受影响。只需要重新打开 App 层的 UI 就能恢复配置。
反之，如果你要彻底重置 Thanox 的所有配置，需要手动清理 Framework 层的数据目录。
架构的权衡
两层架构带来了强大的能力，但也有代价：
- 必须激活：Framework 层的代码需要注入到
system_server，这就是为什么 Thanox 需要 Xposed 或 Magisk 激活——它不是一个普通 app，必须通过 hook 或补丁的方式把代码插入系统进程。 - 更新后需重新激活：每次更新 Thanox APK，Framework 层的代码也变了，所以 Xposed 模式需要重新勾选，Magisk 模式需要重新导出补丁并刷入。
- 不能卸载 App 层：如果卸载了 Thanox App，Framework 层的代码仍然会留在 system_server 中继续运行——这时你只是失去了 UI 入口，核心逻辑还在执行（包括可能对你不想要的 app 进行拦截）。