鸿易通app

HOA 鸿易通这款实验性应用就像是在安卓生态里硬塞进了一扇通往鸿蒙的单向门，它不折腾系统也不求 Root，只为了让普通手机能直接运行鸿蒙原生的 HAP 包。这背后的技术逻辑其实挺有意思，相当于在安卓的 SurfaceView 上强行用 ACE 引擎渲染 ArkTS 页面，再通过 ABI 桥接让闭源的.so 文件在 bionic 环境下苟延残喘地运行。这种“借壳上市”的做法充满了极客的浪漫与无奈，毕竟它并没有把整套鸿蒙系统搬过来，而是基于 ArkUI-X 做了定向适配，本质上是在安卓的骨架上硬穿了一层鸿蒙的皮肤。

不过生活不是代码，现实也没那么完美。表格里的限制清单看得人心里直打鼓：后台服务、分布式能力统统不支持，这意味着那些依赖复杂生态联动的小众应用在这里只能看个寂寞。更让人头疼的是性能问题，ArkUI-X 的渲染管线未经优化，稍微复杂的页面就可能卡顿得像老式拖拉机；每个 HAP 启动独立进程的设计虽然隔离性好，但多开几个瞬间内存压力就爆表，长时间运行还容易资源泄漏，不得不频繁重启。安全性方面更是个雷区，HDC daemon 默认开放端口且无认证机制，这简直就是给黑客递了把钥匙，绝对只能在开发调试时玩玩，千万别在生产环境冒险。

更新日志里那些新增的兼容实现和消除依赖的操作，更像是开发者在悬崖边小心翼翼地修补漏洞。对于玩机用户来说，HOA 既是一次探索技术边界的高光时刻，也是一场需要时刻紧绷神经的冒险游戏。它证明了跨生态运行的可能性，但也赤裸裸地展示了理想与现实之间的巨大鸿沟，这种在破碎中寻求完整的尝试，或许才是开源精神最真实的写照。

HOA鸿易通app(Harmony on Android)是一个面向开发者和玩机用户的实验性项目应用。目标是让普通安卓设备无需刷机、无需Root，直接加载并运行鸿蒙原生HAP包。它并不是把整套鸿蒙系统搬进安卓，而是基于ArkUI-X的Android构建体系做定向适配，用ETS虚拟机执行HAP里的modules.abc字节码，用ACE渲染引擎把ArkTS页面画到Android的SurfaceView上，再通过musl→bionic的ABI桥接层加载鸿蒙原生.so。

支持到什么程度

| 完整 Bundle Manager | 不支持 | 未实现，bundleInfo_ is nullptr 日志警告 | | 后台能力 / Service | 不支持 | 未实现 | | 分布式 / 多设备 | 不支持 | 未实现 |

已知限制

HOA 仍在早期开发阶段，以下为已知限制：

• HAP 兼容性：目前只有部分 HAP 能正常运行。依赖未实现系统 API 的 HAP 会白屏或崩溃。

• 性能：ArkUI-X 渲染管线未经优化，复杂页面可能卡顿。

• 内存：每个 HAP 启动一个独立进程，多 HAP 同时运行内存压力较大。

• 稳定性：长时间运行可能出现资源泄漏，建议测试后重启 app。

• 安全性：HDC daemon 无认证机制（默认 8710 端口），仅适合开发调试，不要在生产环境使用。

原理

HOA 基于 ArkUI-X 的 Android 构建体系，通过多个仓库的定向适配使运行时能够加载并执行 OHOS 原生格式的 HAP：

• ArkTS 渲染：ETS VM 执行 modules.abc 字节码，ACE 引擎将 UI 树渲染到 Android SurfaceView

• 原生 .so 支持：通过 libb.so（musl ABI bridge）在 Android bionic 上运行 OHOS 闭源 .so；ELF patch 将 DT_NEEDED libc.so 替换为 libb.so；elf_load_with_deps 对无 RUNPATH 的 .so 做拓扑依赖加载

• HDC 协议：实现 OHOS HDC daemon，支持 DevEco Studio 设备识别与一键部署

关键机制：Java 层通过 setOhosHapMode(true) 设置环境变量，经 JNI 传入 ETS VM，在模块路由时激活 OHOS 兼容路径（自动适配 SDK 5.0/6.0 ABC record 名格式差异），使 ArkUI-X 能正确加载 OHOS 编译的 ABC 文件。

更新日志

v26.7.9.1版本

新增 libdeviceinfo_ndk.z.so 兼容实现

新增 libasset_ndk.z.so stub 实现

新增 libbundle_ndk.z.so 兼容实现

新增 librawfile.z.so 兼容实现

禁用 MALLOC_CANARY_DEBUG，消除 libb.so 对 backtrace 的外部依赖