为什么内部 SD 卡槽永远用不了

不是 EtchDroid 不想做，是 Android 根本不让做

EtchDroid 的 FAQ 里有一句话：

"Other apps might be able to get around this limitation by using root access; EtchDroid does not require root and will never do so."

这直接回答了为什么内部 SD 卡槽不被支持。下面把技术细节说清楚。

Android 对存储访问的两层限制

Android 的存储权限模型分两个阶段，恰好对应了 EtchDroid 为什么做不到：

阶段一：分区挂载限制

从 Android 4.0 开始，可存储介质（内部存储、SD 卡）由系统以分区方式挂载。应用通过标准文件 API（File、DocumentFile）访问的是已挂载的分区，而不是原始块设备（/dev/block/mmcblk1）。这意味着：

• 应用只能写 SD 卡上已经存在的文件系统
• 应用无法访问 SD 卡的分区表（MBR/GPT）
• 应用无法替换整个磁盘的文件系统

但 EtchDroid 需要做的恰好是替换整个磁盘的分区表和文件系统——这只有原始块设备写入权限才能做到。

阶段二：USB Host API 的物理隔离

EtchDroid 唯一能走的路是 USB Host API。但内部 SD 卡槽的控制器不在 USB 总线上，它走的是 SDIO（Secure Digital Input/Output）总线——物理上就不是 USB 设备，USB Host API 根本看不到它。

所以这条路从硬件层就走不通，跟权限无关。

其他刻录工具是怎么做到的

能写内部 SD 卡槽的刻录工具（比如 Rufus for Android 的某些变种），本质上走的是 root 路径——通过 su 拿到 shell 权限，然后用 dd 或直接写 /dev/block/ 节点。

EtchDroid 的产品决策从第一天就和这条路径对立：无 root 是核心承诺，不是可选项。开发者认为 root 权限对普通用户来说太危险，也与 EtchDroid 的"零门槛、零配置"定位冲突。

这算不算一个硬伤

对于"用 Android 手机写 Linux U 盘"这个场景，不算——因为绝大多数 Linux 用户用 U 盘而不是手机内部存储来启动电脑。真正影响的是树莓派场景：用户必须买一根 USB 读卡器。

不过好消息是：USB 读卡器很便宜，而且一条读卡器就能同时满足"写 U 盘装系统"和"写 SD 卡装树莓派"两个需求。把它当作应急工具箱里的一个常备配件就好。