总有人问什么时候出 x86 或者 32 位版本。诚实的回答是：不会出。这篇就来解释
原因——不拿"技术原因"四个字搪塞，而是把真实的取舍摆出来。
一句话版本
DSHBox 不是一个程序，而是一堆预编译二进制的组合，它们必须彼此兼容、也必须
和手机兼容。而这里的每一个二进制都是 ARM64 构建：
- 安卓一侧的 PRoot 和 guest 加载器；
- 应用与 guest 之间的共享内存通道；
- Node.js 24 发行版；
- 整套 Debian 13 rootfs。
APK 里只有一种 ABI：arm64-v8a。这套栈内部不允许混搭架构——x86 的 Node.js
没法跑在 ARM64 的 rootfs 里——所以"支持 x86"的真实含义是：再构建、再发布
一整套完整的栈。
为什么"加一种 ABI"没那么简单
ABI 不是编译器上的一个开关，而是"链路上每个二进制在该架构上都正常工作"的
承诺。每种 ABI 都要有自己的一套经过验证的构建——PRoot、加载器、通道、
Node.js、rootfs——以及覆盖各更新路径的测试。而且失败的代价很重：任何一环
对所在架构判断错误，坏掉的是首次启动、是初始化那一步，而不是某个冷门功能。
每一层的 SHA-256 哨兵会在启动时校验完整性——但它校验不出一个从未被构建过的
版本。
为什么放弃 32 位
DSHBox 要求 Android 10 及以上（minSdk 29）。这个安卓版本档位的设备绝大多数
是 arm64，纯 32 位手机是持续收缩的尾部的尾部。发布 armeabi-v7a 意味着为这点
余量再养一套完整的二进制矩阵——而单个 APK 已经约 237 MB，其中大部分是二进制，
换个架构就得原样再来一份。为了那么少的新增设备，这笔账不划算。
为什么模拟器不是出路
在别的架构上跑安卓的办法确实存在，我们也都收到过询问：
- PC 或虚拟机上的 Android-x86 类系统；
- 在设备上把 ARM 指令翻译成其他 CPU 指令的二进制转换层；
- 使用 x86 系统镜像的开发用模拟器。
问题出在工作负载上。PRoot 是基于 ptrace 的用户空间：guest 的几乎每个系统
调用都会被陷入、检查、转发，循环往复、热度极高。这恰好是二进制翻译器表现
最差的那类持续、高密度的系统调用负载。转换出来的环境可能慢，可能悄悄出错，
也可能两者皆有——我们不发布、也不测试这些路径。不声称它们能用，是我们能
给出的最诚实的选项。
为什么没有 iOS
iOS 是另一个操作系统，没有提供这类用户空间运行时的分发途径——"侧载一套
PRoot 加 Debian"在这套平台上根本不成立。网站
FAQ 里一句话讲清了这个边界：Android 10+、ARM64，范围就是如此。
我们转而做什么
把要求说清楚，把 ARM64 构建维护到位，不假装不支持的平台能用。如果你不确定
手头某台设备行不行，《设备要求》有
细节，《首次启动排障》讲了初始化
失败时是什么样子。速查表如下：
|
| | 设备 | 能运行吗 | 说明 |
|---|
| ARM64 手机/平板，Android 10+ | 能 | 受支持的配置 |
| 32 位（armeabi-v7a）设备 | 不能 | 未发布 32 位二进制 |
| x86 安卓（模拟器、Android-x86） | 不能 | 未发布、未测试；翻译层未经验证 |
| iPhone / iPad | 不能 | 另一个操作系统；见 FAQ |
想了解这套栈在受支持架构上如何拼装，见
《无需 Root，也无需 Termux》；
想自己构建并验证，见 《从源码构建
DSHBox》。