一条路线先接住 Android 留下的驱动与 BSP，让旧机尽快工作；另一条路线试图把驱动推回 Linux 主线，为设备争取十年后的维护资格。两者表面是发行版之争，底层却是两张完全不同的硬件账本。
我们最近把 Redmi Note 7 跑起了 Droidian：亮屏，进入 Phosh 桌面，拿到一个 Debian 系用户空间。对于一部 2019 年的 Android 手机，这很像获得第二次生命。
可一旦把问题从“能否开机”推进到“能否做成终端”，答案会立刻变复杂：通话是不是可靠？待机是否够一天？相机是不是稳定取流？OTA 能否回滚？运营商换一张卡会不会失效？
Droidian 与 postmarketOS 的差异，不在图标长得像不像手机，而在它们如何取得这些硬件能力、又由谁在未来为它们负责。
Droidian 的问题是：能否尽快把既有 Android 硬件组织成 Linux 终端？
postmarketOS 的问题是：十年后，能否不靠原厂 BSP 继续维护这台终端？
一、先把“移动 Linux”拆开：你到底换掉了什么？
手机不是一块普通 ARM 开发板。屏幕、触控、GPU、ISP、基带、音频 DSP、充电、传感器和低功耗状态，通常由芯片厂、ODM、品牌和运营商共同缝合；其中大量代码与固件只在 Android BSP 里可用。
因此“刷上 Linux”至少有三种完全不同的含义：
| | |
|---|
| Phosh、Plasma Mobile、Sxmo；终端、浏览器、软件包管理器。 | |
| | 需要连接 Android HAL/vendor，或把驱动与协议重新实现为 Linux 原生路径。 |
| 睡眠唤醒、热管理、GPU、调制解调器、ISP 的真实行为。 | |
所以，桌面跑起来是必要条件，却是移动 Linux 产品化的最早一关。
Droidian 的主路线是通过 Halium/libhybris 复用 Android 内核、vendor 与 HAL；其背后运行经过裁剪的 Android 环境以调用硬件服务。postmarketOS 的主路线则是 upstream-first：尽量使用上游 Linux 内核与开放用户空间，并把主线化程度纳入设备分级。两边都可能出现例外，但工程重心确实不同。[1] [2]
二、总览：不是谁“更强”，而是谁把难题放在今天或以后
| | |
|---|
| Debian 系用户空间，常与 Mobian/Phosh 软件栈协同；软件包以 APT/.deb 为主。 | Alpine Linux 用户空间；软件包以 apk 为主，可选择 Phosh、Plasma Mobile、GNOME Mobile、Sxmo 等。 |
| 优先调用 Android BSP 的下游内核、vendor 分区与硬件 HAL。 | 优先上游内核与通用驱动；downstream 端口允许存在，但定位为过渡。 |
| Android 9+、Treble/GSI 与既有 Halium 适配可显著减少前期工作；但原厂 kernel 仍须改造。 | 从内核、设备树、firmware、驱动与用户空间服务逐项建立；主线化后的复用价值更高。 |
| 对“已有可工作的 Android 硬件”更务实，显示、蜂窝、专有多媒体链路有机会更快被复用。 | 系统轻量、可选界面多；上游化成功后，内核与安全修复不必等待原厂回头。 |
| 受 Android vendor、内核版本、HAL、RIL/IMS 与分区组合锁定；升级常是兼容性工程。 | 前期最难的是补齐专有链路：相机 ISP、VoLTE、功耗、DSP/GPU 等常需多年积累。 |
| “某机型 + 某 vendor 基线 + 某 Halium 适配 + 某运营商”。 | “某机型 + 内核类别 + 设备分级 + 功能矩阵 + 维护者”。 |
一句话：Droidian 是“继承现成硬件能力”；postmarketOS 是“争取重新拥有硬件能力”。前者把风险更多留在后续兼容性，后者把风险更多放在早期驱动工程。
三、底层依赖：两条系统各自踩着什么地基？
1. Droidian：Android 不在桌面上，却仍在硬件链路里
Droidian 不是把一套普通 Debian 直接塞进手机。Halium 路径依赖 Android 侧内核、vendor 分区和服务，Linux 用户空间借助 libhybris 等兼容层调用 Android 硬件接口。对于 Treble/GSI 设备，官方文档明确指出：常常只需进行内核改造即可复用通用系统镜像；但“原厂 Android 内核还不够”，仍须符合 Halium 要求。[3]
应用 / Phosh → Wayland 与 Linux 服务 → libhybris / Halium 兼容层 → Android vendor、HAL、下游 kernel → 显示 / modem / 相机 / 音频等硬件
这解释了它的速度优势从何而来：不必先把每个闭源硬件接口重新发明一遍。也解释了它的边界：一旦 Android vendor、HIDL/AIDL、图形 composer、SELinux、分区挂载或内核补丁的组合不再匹配，系统可能“看似能启动”，却在相机、旋转、亮度、通话或休眠上出问题。Droidian 的调试指南中就把 Android 容器、vendor 挂载、composer 服务和 udev 规则列为实际排查点。[4]
2. postmarketOS：主线化不是换一个 kernel，而是重建一条可继承链路
postmarketOS 所说的 mainlining，是把厂商下游 kernel 中仍有价值的驱动、设备树与改动清理后推向上游，最终用更接近 Linux 主线的代码来驱动设备。它不是纯粹的“开源洁癖”：Wi-Fi、蓝牙等常仍需要不可避免的 firmware；不同硬件块的成熟度也极不均匀。[5] [2]
应用 / 多种移动桌面 → 标准 Linux 服务与用户空间 → 上游内核 / 通用驱动 / DTS → firmware 与开放协议 → 硬件
它的收益不是“今天更炫”，而是设备不再必须跟随厂商停更的 Android kernel 分叉。代价是，最有价值也最私有的能力恰恰最难主线化：蜂窝语音、相机 ISP、功耗、音频 DSP 和封闭 GPU 用户态，往往不是一个项目单独能解决的。
四、硬件功能逐项拆账：不要把一个绿色勾当成整机可用
| | | |
|---|
| 有机会直接复用 Android composer 与触控驱动，bring-up 通常较快。 | 若 DRM/KMS、panel、触控驱动已上游，路径干净；否则早期调试周期很长。 | 冷启动、熄屏唤醒、亮度、旋转、户外温度下是否都稳定？ |
| 依赖 Android 图形栈与兼容层，版本匹配是核心风险。 | 取决于 Mesa/内核 DRM 驱动是否成熟；同 SoC 不同 GPU 代际差异极大。 | 合成帧率、触控延迟、视频叠加、长期压力后是否丢帧？ |
| 可利用既有 RIL/基带链路，但 IMS/VoLTE、音频路由和运营商配置仍是设备级问题。 | 数据/SMS、传统语音、VoLTE 是不同难度；尤其 IMS 不是“有 modem 就有”。 | 四家运营商、弱网、切网、来电唤醒、紧急呼叫、VoLTE 分别过了吗？ |
| 可能复用厂商 Camera HAL，但预览、编码、多摄、方向和权限仍需实机验证。 | 主线 V4L2/媒体路径一旦打通更清晰；但手机 ISP、自动对焦和专有算法最难替代。 | 连续预览 30 分钟、前后摄切换、录像、自动曝光/对焦、异常恢复是否可靠？ |
| 可借 Android audio HAL；录放、通话、蓝牙、回声消除每一项都可能不同。 | ALSA/UCM、PipeWire/WirePlumber 等可持续演进，但 modem call-audio 的打通并不轻松。 | 听筒/免提/耳机/BT/双麦/AEC/来电时音频路由，是否逐项验收？ |
| 保留厂商电源链路不代表 Linux 用户空间下就有 Android 级续航。 | 主线低功耗状态、PMIC、modem 唤醒需要完整验证；这是主线化成败的硬指标。 | 24h 待机耗电、深睡比例、来电唤醒、关机充电、过热降频可测吗？ |
| HAL 可复用但权限、守护进程与校准数据易被忽略。 | IIO/传感器驱动与 GNSS 协议可更通用，但设备校准与省电策略仍须补齐。 | GPS TTFF、加速度/距离/光线、后台定位、航向与功耗是否达标？ |
上表描述的是工程依赖，不是每个型号的功能结论。任何“支持”都必须回到该设备页、内核类别与实测版本。
特别是通话：数据联网、短信、传统语音、VoLTE/IMS、紧急呼叫、通话录音和蓝牙通话是多条链路。Droidian 仍将 VoLTE 与 5G 列为持续测试项；postmarketOS 的通话音频项目也把 modem、声卡与现代音频会话管理之间的衔接视为重点。[6] [7]
五、谈性能，先拒绝伪跑分：同一 SoC 不会因换发行版自动变快
“Droidian 和 postmarketOS 谁性能更好？”如果不锁定同一手机、同一内核、同一频率策略、同一图形栈和同一任务，答案没有意义。CPU 指令最终仍在同一颗 SoC 上执行；单纯把 Android 换成 Linux，不会凭空增加算力。
真正影响用户体验的，是下面五个性能账本：
| | |
|---|
| | 短跑分可能很好，长期负载却因温控或错误的 cpuidle 策略掉速。 |
| DRM/KMS 或 Android composer 路径、Mesa/专有栈、Wayland 合成器、屏幕刷新率。 | 桌面 60fps 不代表视频、地图、相机预览、旋转动画都稳。 |
| 硬件编解码、零拷贝、GPU/NPU/DSP runtime、内存带宽、散热。 | CPU fallback 能跑，但功耗与延迟可能完全不具备产品意义。 |
| 基础用户空间、日志、浏览器、桌面、Waydroid 的容器和镜像。 | Linux 本身可很轻，但一旦引入完整 Android 容器，RAM/ROM/后台负荷显著变化。 |
| 深睡、modem 唤醒、PMIC、充电、后台网络、热策略。 | 这是用户最能感知的“性能”，也最无法从桌面截图判断。 |
两项目都可以使用 Waydroid 作为 Android 应用补偿。Waydroid 不是传统模拟器，而是基于 Linux namespace、LXC 与 binder 的 Android 容器，可直接接入所需硬件；它因此接近原生效率，但并不免费：postmarketOS 官方明确提醒，会额外占用 RAM、存储、CPU 与电池。并且金融、DRM、推送、设备完整性检测等商业应用是否可用，仍不能由“容器能启动”推断。[8] [2]
文章不公布“谁更快”的数字，原因不是回避，而是避免误导。未在同一 Redmi Note 7、同一环境下完成 CPU、GPU、待机、相机、蜂窝和热负载测试前，把不同机型、不同内核的社区感受拼成跑分结论，是不负责任的。
如果要做下一阶段实测，建议使用同一台解锁设备、同一电池健康度、同一信号环境、同一屏幕亮度，连续测试：冷启动时间、空闲 8/24 小时耗电、浏览/地图的帧时间、1080p 录放持续性、30 分钟相机预览、通话/来电唤醒、4G/Wi-Fi 切换、热负载降频，以及 Waydroid 前后的 RAM/功耗增量。那才是能比较的性能报告。
六、生态不是“有没有应用商店”，而是三层供给
移动 Linux 的生态要分开看。把 Flatpak、APT/apk 软件仓库和 Android 应用容器混为一谈，会高估实际可用性。
| | | |
|---|
| Debian 包生态大，桌面软件移植资源丰富；但“桌面可装”不等于“手机可用”。 | 继承 Alpine 的轻量与安全导向，apk 路径适合小镜像；移动端适配仍取决于应用本身。 | 浏览器、终端、工具、开源通讯是强项；国内常用超级 App 不是。 |
| Phosh/Mobian 路线相对集中，应用适配有较明确目标。 | 可选 UI 更丰富，适合探索形态；也会带来体验与测试组合增加。 | 产品必须先锁定一套 UI、输入、通知、锁屏和无障碍标准。 |
| 可使用 Waydroid，适合作为迁移期补充而非默认承诺。 | 同样支持 Waydroid，官方更明确建议优先寻找原生替代。 | Android 容器解决部分 App 缺口，但会放大资源、兼容、合规与运维复杂度。 |
| Debian/Ubuntu 经验更容易迁移，APT、systemd、容器工具普及。 | pmbootstrap 将构建、打包、刷写流程抽象为一致的 chroot 工作流；主线协作更靠近 Linux 社区。 | 选择 OS 不能只看用户应用，也要看团队已有驱动、内核、Linux 发行版与 CI 能力。 |
postmarketOS 选择 Alpine 的一个直接原因是小：官方 FAQ 给出的基础安装约 5MB，并强调这对老旧设备的存储空间与一致的 pmbootstrap 构建环境有实际意义。注意，这不是“整台带桌面的手机只占 5MB”，更不是装上浏览器、地图、模型或 Waydroid 后的系统体积。[2] [9]
七、升级与安全：Droidian 的难点是“兼容遗产”，postmarketOS 的难点是“维护供给”
| | |
|---|
| APT/.deb 的成熟路径；内核也可以按设备打包并 OTA 更新。 | Alpine/apk 与稳定版、edge 路径；构建、包与设备配置由 pmbootstrap/pmaports 管理。 |
| 可以更新，但老 Android kernel、boot image、vendor 与兼容层是否继续匹配，是设备适配的核心债务。 | 主线/通用内核的收益更大；但前提是设备确实进入可持续维护的分级，而非仅能启动。 |
| Linux 用户空间可获更新，不自动消除旧 vendor、闭源 blob、基带固件的历史风险。 | upstream-first 可减少对停止维护用户空间和 kernel 分叉的依赖；firmware 与硬件漏洞仍另算。 |
| 安全启动与密钥、分区/回滚、远程升级、SBOM、漏洞响应、运营商认证、售后恢复，都必须由产品团队建立，不会由社区镜像自动提供。 | |
postmarketOS 对设备并非只列一张“支持清单”。其 main、community、testing、downstream、archived 分级，直接把内核是否可升级、是否测试、是否有维护者和 CI 纳入准入条件；预构建镜像主要面向 main/community，以及少量 testing 设备。这个分级比“支持多少台”更有信息量。[10] [11]
八、对产品团队最有用的选择表：先看目标，再选路线
| | | |
|---|
| 把一款已停更 Android 机快速变成边缘网关、开发终端、实验性 AI 设备 | 现有 vendor 与 Halium 基础是否可用；核心功能是否只需少数硬件链路。 | | 启动、网络、音频、相机、待机、远程升级；不要只看桌面。 |
| 做生命周期 5–10 年的行业设备，团队愿意维护内核和驱动 | SoC 是否有良好主线支持；是否能锁定可合作的硬件和驱动资源。 | | 内核类别、DTS、PMIC、modem、相机、硬件 CI、内核升级回归。 |
| 做只依赖 4G、按键、屏幕、语音和少量外设的专用终端 | 是否真的需要手机型 Linux；专用 BSP/RTOS 或精简 Android 是否成本更低。 | | 启动速度、功耗、认证、量产治具、供应链、远程管控总成本。 |
| 当地 App、支付、DRM、VoLTE、紧急服务、售后、合规是否闭环。 | | 真实用户网络、商业应用、长待机、安全升级与灾难恢复全链路。 |
对我们的 AI 终端方向，结论尤其清楚：如果目标是尽快验证“旧 Android 硬件 + Linux 服务 + 云端智能体/边缘控制”，Droidian 可以是一条现实的过渡通道；如果目标是建立可长期维护的设备家族，就应尽早把主线化、驱动归属、硬件 CI 和 OTA 责任写进立项，而不是等产品卖出后再补。
九、量产前的红线清单：少一项，就只能叫 Demo
- 硬件矩阵：每个 SKU 的屏幕、触控、相机、音频、modem、Wi-Fi/BT、GNSS、传感器、充电与低功耗状态都有版本化结果；
- 网络矩阵：目标国家/运营商/频段/SIM，数据、SMS、语音、VoLTE、漫游、弱网、来电唤醒分别验收；
- 性能矩阵：冷启动、RAM、存储、热、功耗、帧时间、视频/相机连续运行，而非一次性跑分；
- 升级矩阵：断电、满盘、跨版本、失败重试、A/B 回滚、救砖和工厂恢复都能闭环；
- 安全矩阵：bootloader 状态、签名链、密钥轮换、漏洞响应、SBOM、日志与隐私边界明确；
- 责任矩阵：谁维护 kernel、谁维护 vendor 或 firmware、谁测试运营商、谁对 OTA 失败负责，不能只写“社区支持”。
最重要的分界线：“能 boot”证明的是端口存在；“能连续升级且各关键硬件稳定工作”才证明它是可维护的设备；“有认证、运维、安全与售后闭环”才谈得上产品。
结语：两种时间尺度，不是一场桌面之争
Droidian 代表的是一种工程现实主义：先接住 Android 世界积累下来的驱动、ISP、基带和电源资产，让存量硬件尽快拥有 Linux 用户空间。
postmarketOS 代表的是另一种更慢、也更有野心的工程观：把设备从厂商下游 kernel 与停止维护的软件分叉中逐步解放出来，使它在原厂离场后仍能被维护。
前者不等于“没有 Linux”；后者也不等于“天然更适合量产”。真正的选择取决于你要复用什么硬件、承受多少前期驱动投入、计划维护几年，以及谁愿意承担那份长期责任。
移动 Linux 的价值，不是成为“第三个手机系统”。它真正打开的问题是：当 Android 的生命周期结束后，硬件还能不能被重新组织、重新维护、重新定义。
资料来源
- Droidian Image creation （https://docs.droidian.org/porting-guide/image-creation/）：Halium 复用 Android drivers、GSI 与 vendor 依赖。
- postmarketOS FAQ （https://postmarketos.org/faq/）：Alpine、upstream-first、firmware、Waydroid 与资源成本。
- Droidian Kernel compilation （https://docs.droidian.org/porting-guide/kernel-compilation/）：Android kernel 适配、Treble/GSI 与 OTA 内核打包。
- Droidian Debugging tips （https://docs.droidian.org/porting-guide/debugging-tips/）：Android container、vendor、composer 等真实端口问题。
- postmarketOS Mainlining （https://wiki.postmarketos.org/wiki/Mainlining）：下游 kernel 到主线化的定义与低功耗要求。
- Droidian VoLTE and 5G testing （https://forum.droidian.org/t/volte-and-5g-testing/64）：VoLTE/5G 的持续测试边界。
- postmarketOS call audio / WirePlumber project （https://postmarketos.org/blog/2025/08/17/callaudiod-wireplumber-project/）：移动通话音频的工程现状。
- Waydroid official site （https://waydro.id/）：Linux namespace、LXC、binder 与 Android 容器架构。
- pmbootstrap project （https://gitlab.com/postmarketOS/pmbootstrap/-/tree/1.48.0）：postmarketOS 的构建、打包与刷写工作流。
- postmarketOS Devices （https://wiki.postmarketos.org/wiki/Devices）：设备分类说明。
- postmarketOS pre-built images （https://wiki.postmarketos.org/wiki/Installation/Using_a_pre-built_image）：预构建镜像适用的设备级别。
