为什么Droidspaces的容器在Android上"杀不死"？深度解析init.rc与用户态双Daemon模式架构
【免费下载链接】Droidspaces-OSSA lightweight, LXC-like container runtime for Android and Linux. Run full Linux distributions natively with zero performance penalty项目地址: https://gitcode.com/gh_mirrors/dr/Droidspaces-OSS
Droidspaces是一款轻量级的 Linux 容器运行时（container runtime），让你直接在 Android 手机上运行完整的 Linux 发行版（支持 systemd、OpenRC 等 init 系统），零性能损耗。很多用户都有过这样的困扰：容器跑得好好的，被系统"顺手"杀掉就再也没起来。Droidspaces 的"杀不死"魔法，来自它的init.rc 原生集成 + 用户态 Magisk 模块双 Daemon 守护模式架构。本文带你读懂这套机制的工作原理。
为什么Android上的容器容易被"杀死"？🤔
Android 的内存管理非常激进，系统 OOM Killer 会随时清理"后台"进程；App 被划掉、低电量回收、系统升级，都可能导致容器进程消失。普通的容器工具只是"启动一个进程"，进程死了就死了。
Droidspaces 的思路是：把守护容器这件事，交给 Android 系统最底层的"管家"——init 进程，或者一个由开机脚本拉起、随时可复活的常驻 Daemon。这就是所谓的"双 Daemon 模式"：
| 模式 | 守护者 | 是否需要刷分区 | 特点 |
|---|---|---|---|
| 用户态 Daemon（Magisk 模块） | 开机脚本启动的droidspaces daemon | 否，装模块即可 | 部署简单，可热更新 |
| init.rc 原生集成 | Android 系统的 init 进程 | 是，需修改vendor.img | 最深集成，被杀后由 init 自动拉起 |
模式一：用户态 Daemon —— Magisk 模块双脚本接力
Droidspaces 附带一个 Magisk 模块，核心是两个脚本接力完成守护：
post-fs-data.sh：在开机最早期拉起 Daemon
数据分区挂载完成后，post-fs-data.sh 就会检查标记文件/data/local/Droidspaces/.daemon_mode，若值为1则启动droidspaces daemon。它还会先用chcon把二进制打上droidspacesd_exec的 SELinux 标签，确保 Daemon 能顺利切换到自己的 SELinux 域。
💡 这个标记文件由 App 通过 DaemonModeRepository.kt 以 root 权限写入，你在设置页里开开关，背后就是往磁盘上写一个
1。
service.sh：开机自启容器 + 状态自检
启动完成后，service.sh 接管：等待网络和sys.boot_completed=1，然后扫描所有run_at_boot=1的容器配置，按run_at_boot_priority从小到大逐个拉起，还内置了"网关容器优先"逻辑——路由器没起来，就不会去起依赖它的客户端容器。最后把运行状态写进 module.prop，你在模块管理器里看到的 🟢🔴 状态灯就来自这里。
模式二：init.rc 原生集成 —— 让 init 亲自守护
这是"杀不死"的终极形态。Droidspaces 把服务注册进 Android 的 init.droidspaces.rc：
on post-fs-data阶段自动start droidspacesd，让 daemon.c 以--foreground前台模式运行；- 关键是
onrestart指令：只要 Daemon 被 OOM Killer 杀掉或崩溃，init 会立刻重启它，并顺带触发droidspaces_autoboot重新拉起所有自启容器； on property:sys.boot_completed=1触发开机自启脚本，完成"开机即启动容器"的闭环。
集成方式支持两种（详见 init/README.md）：
- 符号链接法（推荐）：在
/vendor/bin/droidspaces建软链指向 App 目录，以后升级二进制不用重新刷分区； - 二进制直置法：把静态编译的二进制直接放进
/vendor分区，更自包含但升级需重刷。
配套的 SELinux 策略见 droidspaces_symlink.cil 和 droidspaces_binary.cil，保证droidspacesd域能通过内核的 namespace 系统调用检查（这正是普通 root 环境下常被 seccomp 拦截的地方）。
如何验证 Daemon 是否在工作？✅
- init 模式：执行
getprop init.svc.droidspacesd，返回running即成功； - 模块模式：查看模块管理器中
module.prop的描述行，显示🟢 Running (PID xxx)表示 Daemon 存活； - 通用：
cat /data/local/Droidspaces/.daemon_mode值为1表示守护模式已启用；日志位于/data/local/Droidspaces/Logs/boot-module.log。
⚠️ 小提示：若刷入 vendor 后启动循环（bootloop），官方文档指出 90% 的概率是 SELinux CIL 策略文件中的某个域在你的系统里不存在，按
dmesg中secilc报的行号删掉对应规则即可。
小结
Droidspaces 的"杀不死"本质是把看门狗做进了 Android 的启动链路：init.rc 模式下由系统 init 提供onrestart级自动复活，Magisk 模块模式下由 post-fs-data/service 双脚本在开机最早期接管 Daemon 与自启容器。两者叠加 systemd/OpenRC 容器内 init，构成从内核启动到用户态的完整守护链——这也是 Features.md 中它区别于普通终端模拟器的核心能力。想动手实践，可以从 App 内的 Daemon 模式开关入手，进阶再折腾 vendor 集成。🚀
【免费下载链接】Droidspaces-OSSA lightweight, LXC-like container runtime for Android and Linux. Run full Linux distributions natively with zero performance penalty项目地址: https://gitcode.com/gh_mirrors/dr/Droidspaces-OSS
创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
