Rootless Store

Appearance

局限性与预期完成时间 ​

当前局限性 ​

Rootless Store 的目标很大，但现阶段必须先把边界写清楚。这个项目不是“把几个执行器拼起来”就自然成立的，它真正困难的地方，在于要同时兼顾安卓现实环境、Sources 生态、插件执行、常驻运行和文档约束。

1. 目前还没办法进行强制约束 ​

这是当前最现实、也最核心的局限性之一。Rootless Store 现在还停留在“能力已经预留出来，但还没有完全强制收敛”的阶段。

换句话说，很多设计方向已经明确了，但系统还没有足够强的约束能力去保证每一层都按同一套规则运行。只要强制约束没有做好，后面 Sources、插件入口、执行器和权限边界就都还处在“可以描述，但还不能彻底锁死”的阶段。

2. 权限分级还没有完成 ​

目前最大的一个问题，还是权限没有真正完成分级。

这意味着像 Sources、require 和 PluginManifest 里预留的一些字段，现在还没有办法完全发挥出本来该有的功能。它们已经被留出来了，但还没有全部接上真正可执行、可校验、可收敛的能力体系。

既然这些东西已经留在结构里，我们就不打算让它们一直停留在占位状态，而是准备在后续版本里把这套“梦想”一并圆起来。

3. 官方 Sources 后端还没有彻底完成 ​

关于 Sources，目前我的计划是通过 Nuxt API 这一环去创建官方源。

但现在有一个很现实的问题：GitHub 这一侧可能并不适合承载这件事，不管是 SSR 支持，还是整体性能表现，都让这条路径暂时没办法彻底完成构建。

所以现阶段，这一块仍然属于“方向已经明确，但基础设施还没完全落地”的状态。

如果项目贡献者们有能力，也完全可以先尝试用这些后端工具去接这条链路：

  • Kotlin
  • Java
  • Go
  • 以及其他适合承担后端能力的实现方式

4. 设备兼容性不会天然统一 ​

不同厂商 ROM、不同安卓版本、不同 SELinux 策略、不同 CPU 架构，会直接影响插件执行、设备状态采集和常驻运行的一致性。很多问题不是客户端逻辑写完就会消失，而是环境本身就存在分裂。

尤其是当 Rootless Store 同时支持 ADB、SH、Shizuku 和 Root 这些执行器之后，兼容性就不再只是“能不能运行”，而是“当前设备到底允许哪条链路稳定运行”。

5. Rootless 和 ADB 不是提权工具 ​

这一点必须讲清楚。Rootless 和 ADB 的定位，从来都不是一个可靠的权限提升工具。

它们更重要的意义，是在用户还没有掌握 TTY 或 TUI 能力的时候，先通过 GUI 的方式去管理、理解并执行这些插件。这是一个非常好的思维模型：

  • 不会让宿主机立刻进入危险状态。
  • 能明显降低大家接触插件和 Linux 能力的门槛。
  • 可以先把生态入口建立起来，再谈更高层的能力。

6. 必须尊重安卓系统的安全边界 ​

Rootless 无法修改宿主机的系统级功能，这是安卓系统保护机制的必然结果，也是一个有效且必要的安全考量。

大家一定要尊重系统的边界性，不要以为 Rootless 就一定能发挥出非常 powerful 的效果，更不要把它理解成一种“Permission Promotion”式的提权行为。

这类行为是非常危险的，也不推荐大家尝试。

7. 文档工作量不会小于功能工作量 ​

Rootless Store 不是一个只靠界面就能解释清楚的项目。包格式、执行边界、Sources 规则、排障路径、require 模型、权限分级和入口约定，都需要文档同步推进，否则生态规模越大，理解成本越高。

8. 个人精力仍然是现实约束 ​

这一点其实没必要回避。Rootless Store 不是在一个大团队资源池里并行推进的项目，所以开发节奏、文档节奏和协议节奏，都会明显受到个人时间与精力的影响。

这并不意味着项目方向不成立，而是意味着它必须以更务实的方式推进：先缩小范围并圈定所有能力范围，再保证整个 Rootless Store 环境的一致性和可维护性。

当前预期完成时间 ​

下面这组时间，是截至 2026 年 3 月 31 日 的阶段性目标草案。它更接近“当前预期”，而不是对外不可变更的承诺，后续仍然会随着实际开发节奏调整。

下一个版本 ​

目标时间：2026 年 4 月之后的下一个版本

  • 逐渐完善 shell screen 的 TTY 交互功能。
  • 让调试过程更直接，方便大家进行 debug。

2026 年 6 月到 2026 年 8 月 ​

  • 将当前结构里预留出来的关键字段逐渐补完。
  • 把 Sources 后端的核心能力逐渐开放给大家。

更长期的推进方向 ​

  • 继续缩小范围并圈定 Rootless Store 的所有能力范围。
  • 继续保证整个 Rootless Store 环境的一致性和可维护性。
  • 继续把 Sources、执行器和权限边界收敛成可长期维护的结构。

预期之外也要提前写清楚 ​

即便路线按计划推进，Rootless Store 也不应被描述成“短期内覆盖一切安卓场景”的项目。更合理的目标是：

  • 先把核心链路做通。
  • 再把能力边界讲清。
  • 最后把生态慢慢放开。

只有这样，项目才能既保持野心，又不失去现实可交付性。