任何对隐私操作系统有所了解的人，看到短信工具大更新大概都会愣一下。9 月 11 日，GrapheneOS 开发者 thestinger（Daniel Micay）通过 Commit 22cd55e 签发了默认短信组件 Messaging v13。在即时通讯全面转向云端和端到端加密的今天，为一个连开发团队自己都承认明文传输且毫无保密性的载波短信应用大动干戈，看起来像是在逆行。
这并不是为了把短信包装成下一个 Signal。打开新版的新手引导，界面开门见山提醒：SMS 本质未经加密，敏感通讯请换用端到端加密软件。这次重写的真正意图，是用现代软件工程将 Android 开源项目遗留多年的代码废墟彻底推倒，为系统底层收缩被忽视的攻击面。
修其藩篱，以御暴客。古人修篱笆防盗贼，并非因为篱笆能挡住千军万马，而是为了不让自家院落门户洞开。v13 所做的事情，正是在老旧协议无法更改的物理局限下，给系统装上一道牢固的物理隔离栓。
架构跃迁：推倒 AOSP 遗留数十年的代码废墟
原生的 Android 开源项目短信组件，代码架构长期停留在 Android 4.x 时代的旧泥潭中。现代 Android 生态里，Google Messages 凭借 RCS 规范、云端连续互通和人工智能牢牢统治了主流视野，却需要深度捆绑 Google 专有框架；而曾经活跃的第三方开源客户端，例如自 2021 年 2 月 24 日起便停止更新的 QKSMS，或是步履维艰的 Simple SMS Messenger，早已难以跟进现代系统规范。
GrapheneOS 没有选择在旧骨架上修修补补，而是直接用 Kotlin 和 Jetpack Compose 完成了全盘重构。
在工程层面，v13 将项目构建基线推高到了 minSdk 36、targetSdk 37 与 compileSdk 37，并深度集成了 Android Gradle Plugin 9.3.2、Gradle 9.7.1 和 Kotlin 2.4.10。与之同步落地的，是 Compose BOM 2026.08.00、Material 3 Adaptive 规范、Navigation 3、Coil 3 和 CameraX。
这套重构在界面交互上带来了直观的变化：大屏设备终于获得了原生的双栏布局，所有屏幕会话控制、滑动归档、固定对话、未读标记、按小时静音通知等基础功能全部得到现代化补齐。但更关键的转变不在视觉，而在防御边界的全面收紧。
刀刃向内：收缩针对运营商多媒体协议的攻击面
短信和彩信（MMS）从诞生起就是电信黑客与溢出攻击的高发地带。Stagefright 的历史教训早已证明，只要操作系统允许不受控的媒体解析器在后台自动解构载波内容，用户就等于直接将设备暴露在无形跳板之下。
v13 在解析层施加了极其刻薄的防御机制。开发团队针对 EXIF APP1 元数据、MMS PDU（协议数据单元）以及彩信内容类型解析增加了严格的内存分配上限，防止畸形数据包触发内存超载；同时修复了 GIF 格式中存在的空指针解引用隐患，补齐本地转码前的媒体尺寸校验，并合并了 AOSP 上游的 vCard 联系人解析漏洞补丁。
在对外暴露的组件接口上，管控同样严密：应用内分享流程不再信任外部传入的 file: URI，一旦涉及私有应用文件或未授权的 content: URI 会被当场拒绝；桌面小组件（Widget）的接收器不再对外部系统导出，意图全面附加 FLAG_IMMUTABLE 标记以防篡改；此前会自动发起的 YouTube 链接预览被设为默认关闭，防止设备因一条普通短信被动向外部服务器发起网络请求。
- 结论.这一套防御组合拳的目标非常明确：既然电信载波协议本身漏洞百出，那就把系统解析该协议的沙盒口径收缩到极致。
攻克多用户暗礁：主号代拉与通知崩溃的底层治理
在多用户和工作资料（Work Profile）场景下，Android 的载波短信机制长期处于半瘫痪状态。这是 Android 系统的底层架构顽疾：SIM 卡硬件与移动网络基带只认系统主用户（Owner），副用户（Secondary users）无法独立操纵基带拉取多媒体数据。
在旧版 v12 时代，这种冲突经常演化成灾难：大量的 TransactionTooLargeException 导致系统通知服务崩溃，彩信常年死锁在点击下载状态，副用户的短信通知不仅经常无故推迟，还经常连内容也丢得一干二净。
副用户通知到达 → 系统检测到 MMS 数据包 → 触发主用户（Owner）静默拉取 → 解码入库并广播全局v13 重构了这套跨用户协调逻辑。副用户的短信通知现在具备独立的通知 ID，并能正常渲染文本内容；当未决彩信抵达时，系统不再放任副用户死锁等待，而是明确告知需要由主用户代为拉取。一旦主用户在基带层完成数据下载，解码后的多媒体内容就会同步广播给全局用户。与此同时，工作资料内的对话打上了明确的专属标签，彻底终结了跨空间会话混杂的历史问题。
现实边界：没有 RCS 的隐私孤岛该往何处去
即便 v13 把本地防御做到了极致，一个现实问题依然避不开：原生 RCS（富通讯解决方案）的缺席。在 GitHub 仓库中，关于原生 RCS 支持的 Issue #44 依然处于挂起状态。
这是定制隐私系统面临的共同困局。Google 已经把 RCS 事实性垄断在其专有私有云服务上。如果 GrapheneOS 用户想要在日常交流中享受类似现代 IM 的打字指示器、高清多媒体传输和端到端加密群聊，目前唯一的路径是借由沙盒化 Google Play 服务运行 Google Messages。
- 风险.使用 Google Messages 意味着必须将底层特殊的电信载波权限、硬件 IMEI 标识符以及全部通讯元数据完整交由 Google 专有组件接管，这与 GrapheneOS 最初立足的防御哲学背道而驰。
外部生态同样反映出这种断代割裂：尽管 thestinger 已经在 GitHub 签发并发布了 v13 的代码与 Release 标签，但在部分下游镜像和讨论区中，关于双栏适配与崩溃反馈的信息依然停留在 v12 阶段。重写一个系统级系统组件的落地成本，远比外界预想的漫长。
面对不可逆的电信协议，GrapheneOS 既没有盲目引入臃肿的私有云服务，也没有自欺欺人地宣称短信已经安全。它用 Compose 写了一套坚固的防护壳，然后老老实实地告诉用户：底层的明文协议不可信任，请用 Signal。这种不讲花哨故事、只在刀刃上求精度的工程克制，或许才是现代安全系统最稀缺的品质。