一台Kobo电子书阅读器,原本一辈子只干一件事:翻页。现在有人让它装上了应用商店——通过Wi-Fi装应用、卸应用、更新应用,像手机一样。前提是,你的Kobo必须精确长成一个样子:Clara BW,型号N365,固件4.45.23697。差一个型号,系统直接拒绝运行,不是尝试适配失败,是压根不让你装。

这个项目叫Cobalt,不是Rakuten Kobo官方出品,是一个开源社区项目,协议AGPL-3.0,不提供任何担保。它的野心不小:启动器、签名商店、Rust SDK、运行时,一整套东西对着智能手机的应用生态抄了作业。它的谨慎程度,和它现在的适用范围完全不成比例。

一台阅读器长出应用商店

用法很简单:USB接电脑装一次Cobalt平台,以后所有应用的安装、更新、卸载全走Wi-Fi,重启恢复出厂系统。目前已经跑起来的应用不算少——读arXiv论文的阅读器、数独、用前置灯发摩斯电码、接入OPDS图书馆的Gutenbird、Hacker News客户端、RSS订阅、每日新闻简报、审批编程代理请求的Sidekick,还有一个终端。

版本节奏也交代得清楚:App Store功能随v0.2.0上线,几天后v0.2.6接上,项目页面被曝光时,距离商店功能上线还不到两周。换句话说,这是一个刚满月不到的年轻项目,连"稳定版"这个概念都还没立起来——官方安全策略目前只保证主分支最新提交是可信的,不保证某个长期发行版系列。

签名链条,认真到不像野生项目

真正让人多看一眼的,是它的信任架构。每个应用都是静态ARM二进制,清单文件用Ed25519签名,把可执行文件的长度和SHA-256摘要都绑死;签名在隔离的构建环境里完成,私钥从不接触Pull Request;运行时里每个应用是独立的无特权进程,想碰网络、存储、音频、Wi-Fi都得显式申请权限,被拒绝也拿到一个能处理的返回值,而不是直接崩溃闪退。

签名信任链:四层验证 运行时能力门控 应用独立无特权进程,网络/存储/音频需显式申请 Store目录验证 信任固定的GitHub Release,启动前校验目录签名 清单Ed25519签名 隔离构建环境签发,私钥不接触PR ARM二进制 + SHA-256摘要 每次校验的最底层,绑定长度与哈希

这套东西要是出自某个大厂应用商店的内部文档,我不会意外。它现在只服务一款设备。

只认一款机型,是谨慎还是规模不足

硬件写入操作要求设备身份、帧缓冲、固件、内核参数精确匹配,目前只有Clara BW一款机型经过硬件测试。Libra、Sage、Clara 2E、Clara Colour四款主流型号被直接拒绝运行,不是适配没做完,是运行时压根没有多设备profile选择机制。

三个数字看清楚Cobalt现在的位置 1 硬件测试通过 的机型(Clara BW) 4 明确被拒绝的机型 Libra/Sage/2E/Colour 0 官方付费通道 Store托管在GitHub
  • 风险.首次安装会修改用户存储分区,厂商保修大概率作废,项目本身也明说不提供任何担保。

没有收费入口,靠什么撑下去

GitHub托管的公开Store,天然没法做付费拦截。整套流程现在完全靠PR驱动:开发者写完应用,在真机上跑通,附截图或视频提交,合并后自动签名发布,不需要等平台整体升级。流程干净利落,唯一的问题是——驱动力目前只有热情和署名,没有任何经济激励。

签名做到位,门却只为一把钥匙开。

这种"重装甲护着一间小屋"的局面,在硬件越狱社区并不罕见。自定义ROM、路由器刷机固件走过同样的路:开局热闹,能撑下去的项目,后来都跨过了两道坎——设备覆盖面铺开,某种可持续的贡献闭环立住。Cobalt现在两道坎都还没迈过去。


Rakuten Kobo官方到现在没有表态,项目页面也主动写明"独立项目,与Rakuten Kobo无关联"。接下来最值得盯的变量,其实不是技术,是官方态度——是放任、观望,还是像很多厂商对待越狱社区那样发条款警告,历史上这类选择往往直接决定一个社区项目是长成生态还是被一纸条款掐死。

标题说"你的Kobo现在能装应用了",更准确的说法应该是:一批开发者用一款精确到固件号的设备,证明了电子墨水屏能撑起一套像样的应用运行时。离"你的Kobo"三个字,还差着设备覆盖、官方态度和商业模式三重门槛。