Rootless Store

Appearance

Rootless 生态集群 ​

生态环境的起点：基于 Android SAF 的运行模型 ​

Rootless Store 目前的想法，本质上是一个基于 Android SAF 框架的手机运行器模型。

选择 SAF，不只是为了技术实现方便，更是为了降低用户心智负担，并尽可能贴合今天安卓应用的开发规范。用户不应该被迫理解复杂目录结构，也不应该为了装一个插件，就先学会去哪个路径找文件、删哪个缓存、清哪个残留。

Rootless Store 想提供的是一种更贴近日常用户习惯的体验：

  • 安装插件非常简单，尽量做到点一点就能完成。
  • 删除插件也非常简单，不要求用户手动回到文件系统清理残留。
  • 文件的后续处理、关联和回收，尽可能由软件自己完成。

换句话说，Rootless Store 想把“插件生态”从传统脚本分发的思路里拉出来，变成真正符合安卓使用习惯的 GUI 运行环境。

GUI，而不是 TUI ​

这也是 Rootless Store 和很多传统安卓工具路线不一样的地方。

它采用的是 GUI 的设计逻辑，而不是 Termux 那种偏传统 TUI 的感觉。Termux 当然很强，但如果用户没有一点 Linux 基础，纯命令行环境的门槛仍然很高。很多人不是没有需求，而是被交互方式挡住了。

Rootless Store 更接近 Zebra、Cydia 或 Sileo 这种以图形界面为中心的模型：

  • 用户可以更轻松地浏览、安装和删除插件。
  • 用户可以直接看到状态、来源和执行结果，而不是自己拼命令。
  • 用户可以在手机上以更低门槛接触 Linux 能力，而不是先被终端劝退。

执行器模型 ​

Rootless Store 不准备把所有能力都塞进一条执行链路里，而是明确拆成不同执行器，让插件在不同 require 条件下获得不同能力。

目前可以理解为以下几类：

  1. ADB 执行器
    适合通过 ADB 辅助链路获得执行能力的场景。

  2. SH 执行器
    委派给 ProcessBuilder，用于比较基础、比较本地化的 Shell 执行场景。

  3. Shizuku 执行器
    可通过 Shizuku 的 User Service 这一路径进行委派，用来承接一部分不必直接 Root、但又需要额外系统交互能力的场景。

  4. Root 执行器
    委派给 Root 通道，只在设备本身已经具备 Root 条件时作为增强能力使用。

这种设计的关键不在于“执行器越多越好”，而在于插件作者和用户都能知道：当前究竟运行在什么 require 条件上，用的是哪条链路，能力边界到底在哪。

它和 AxManager 的不同 ​

Rootless Store 和 AxManager 一个很大的区别在于运行方式。

AxManager 更接近一次性执行模型。任务跑完，流程也就结束了。

Rootless Store 则希望自己可以作为一个更稳定的常驻运行器存在：

  • 它可以作为守护进程持续执行，而不是只做一次性动作。
  • 它可以稳定驻留在手机上，长期承担插件运行与状态维持。
  • 用户可以随时回到数据流看板，继续查看当前运行状态，而不是每次都从头开始。

这会让它更像一个真正的生态容器，而不是只会启动一次的工具按钮。

短板模型，也就是 Require 模型 ​

Rootless Store 的设计会非常强调短板模型。

原因很简单：它必须先支持在最低的 require 条件下也能正常运行。如果连最低的 require 都没办法成立，那更高的 require 自然也无法成为稳定能力。

这意味着项目不会一开始就假设用户拥有最理想的环境，而是反过来从最保守的现实条件出发：

  • 最低 require 能不能安装。
  • 最低 require 能不能执行。
  • 最低 require 能不能维持运行。
  • 最低 require 能不能给出可理解的反馈。

在这个前提上，更高权限、更高能力的执行器只是增益层，而不是兜底层。

将来会怎么收紧 ​

这个项目如果想长期存在，生态一定会逐步收紧，而不是越来越放任。

未来更合理的方向包括：

  • 收紧包格式：让包必须声明版本、架构、入口、执行器、依赖和能力边界。
  • 收紧来源信任：Sources 需要最基本的校验、签名或完整性机制。
  • 收紧执行权限：不同插件应声明不同级别的执行能力，而不是默认拿到同等通道。
  • 收紧兼容宣告：设备、系统版本、SELinux 状态、Root/ADB/Shizuku 条件需要前置说明。
  • 收紧 require 匹配：后续会逐渐收敛成只运行符合当前手机条件的 require 模型。

“收紧”不是为了变得封闭，而是为了让开放生态不至于因为缺少规则而崩掉。

自定义能力与当前边界 ​

Rootless Store 还有一个优点是自定义空间足够大。

我们并不打算一开始就把整个界面做成夸张的全量个性化系统，但会保留最基础、最稳定的一层，比如当前 App icon 这类视觉样式入口。它代表的是一种方向：在保证运行稳定的前提下，给用户留下可定制空间。

只是由于目前个人精力有限，这部分默认还没有完全打开。它不是被否定了，而是被有意识地放到了后续版本里逐步完善。

Rootless 的真正价值 ​

当 SAF、包定义、执行器、看板、来源和文档被串起来之后，Rootless Store 才会形成真正的生态集群：

  • 用户可以自己添加源，而不是被动等待平台投喂。
  • 插件可以围绕统一约定被发现、下载、执行和维护。
  • 项目可以在保留开放性的同时，逐步建立能力边界。
  • 文档可以和代码、包格式、Sources 协议一起演进。

这才是 Rootless Store 想做的事：不是做一堆功能入口，而是做一套能持续扩张、可以常驻运行、并且不会失控的 Rootless 生态基础设施。