欢迎加入开源鸿蒙 PC 社区https://harmonypc.csdn.net/DBX 是基于Tauri 2、Rust 和 Vue 3的数据库客户端。本次适配保留原有业务代码在 Tauri 的 OpenHarmony 后端之上接通 OHOS 原生编译、ArkTS Ability、ArkWeb 页面和系统文件、窗口接口。本文按实际适配顺序说明遇到了什么问题、依据什么定位、修改了哪一层以及如何确认修改生效。构建和真机操作统一使用devecocliRust 与第三方 C/C 库由 Cargo、ohrs和 OHOS SDK 原生工具链编译。2026-10-04 实测结果当前签名 HAP 已在 HarmonyOS API 26 的 2in1 真机上覆盖安装并启动真实 DBX 主界面、新建连接与 SQLite 表单正常显示原生桥接完成请求往返应用自绘按钮完成最大化和还原工具栏拖动改变了窗口位置系统文件选择器可打开和取消应用私有目录中的 SQLite 数据库完成连接测试与连接。仓库地址https://atomgit.com/OpenHarmonyPCDeveloper/ohos_dbx一、先确定适配边界适配不是重新实现一个 GUI 框架而是将 DBX 的 Tauri 依赖栈切到具有 OHOS 支持的修订再处理应用自身的平台差异Vue 业务界面 ├─ Tauri IPC → Rust 数据库与存储逻辑 └─ OHOS 平台适配器 → ArkTS 文件与窗口接口 ↓ EntryAbility / ArkWeb ↓ DevEco 构建的签名 HAP相关代码集中在以下位置位置职责Cargo.toml、src-tauri/Cargo.tomlTauri 依赖修订、平台依赖与 feature 门控src-tauri/src/lib.rs启动、私有数据目录、平台初始化src-tauri/src/ohos_hilog.rs将 Rust 日志接入系统 hilogapps/desktop/src/lib/backend/ohosPlatform.ts前端与 ArkTS 的请求、回复及窗口操作apps/desktop/src/lib/backend/platformDialog.ts、platformFs.ts文件对话框与文件读写的平台入口src-tauri/gen/ohos/entry/EntryAbility、入口页面、权限及原生.sosrc-tauri/gen/ohos/ohos-rs-ability/项目内的本地 HAR、ArkWeb 控制器与事件接入scripts/ohos.mjs、scripts/build-ohos-native.mjsdevecocli 包装与 Rust 原生构建agents/scripts/build_ohos_native.pyOHOS 原生 Agent / 插件制品构建与 ELF 校验harmonyos/工具链说明、定位记录与适配时间线二、解决“OHOS 被当成 Linux 编译”的问题现象与定位OHOS Rust 目标aarch64-unknown-linux-ohos同时满足target_os linux和target_family unix。只按 Linux 判断的平台分支会把 GTK/WebKitGTK 依赖、Linux 渲染环境变量或 Linux 外部程序选择逻辑带入 OHOS。DBX 原有的wry修订也早于 OHOS 后端的接入。单独修改应用目标 triple 不够必须让 Tauri、wry、tao 和 Ability 桥接使用匹配的依赖栈。处理方式将 Tauri 相关依赖切到支持 OpenHarmony 的feat/open-harmony修订原有 wry 平台补丁继续保留在对应平台模块中。对只属于普通 Linux 的实现使用显式门控#[cfg(all(target_os linux, not(target_env ohos)))]托盘、原生菜单及桌面插件按目标条件编译Tauri capabilities 拆分为公共声明与桌面插件声明。current_platform()、current_plugin_target()优先判断 OHOS生成ohos-arm64等目标键而不是沿用linux-arm64。这一步同时解决了编译依赖选择和运行时制品选择操作系统名称相近不代表二进制 ABI 可以混用。具体修改集中在工作区依赖配置、src-tauri/src/lib.rs和crates/dbx-core的平台识别逻辑中。三、建立可复现的 Windows 构建链路工具链与项目配置项目本轮使用的配置宿主Windows x64Rust / Cargo1.99.0安装 OHOS 目标标准库Rust 目标aarch64-unknown-linux-ohosohrs1.4.2devecocli1.3.4SDKDevEco Studio 的 OpenHarmony SDK编译目标 API 26HAP 兼容配置compatibleSdkVersion: 6.1.1(24)HAP 目标配置targetSdkVersion: 26.0.0、runtimeOS: HarmonyOS原生构建工具SDK Clang / sysroot、CMake、NinjaOpenSSL 构建使用 GNU make 与 Perl构建入口的调整原先依赖 Tauri CLI 临时回调服务的构建方式不适合作为独立的 DevEco 工程入口。现在由entry/hvigorfile.ts的原生构建 hook 调用scripts/build-ohos-native.mjs构建 Vue 前端。准备 Tauri 配置和 OHOS SDK 编译环境。使用ohrs/ Cargo 编译 Rust 库并生成 NAPI 类型启用sqlite-bundled,custom-protocol。交给 DevEco 完成 ArkTS 编译、HAP 打包与签名。scripts/ohos.mjs负责从仓库根目录进入壳工程并调用 devecocli不再连接临时 WebSocket 服务。保留已经适配的gen/ohos工程不重新生成并覆盖路由、权限或本地 HAR 配置。Windows 路径与原生依赖harmonyos/env-windows.sh根据实际 SDK 位置组织环境处理 Windows 短路径和 Bash PATH 分隔符不再硬编码用户名或代理。GNU make 可通过OHOS_BUILD_TOOLS_DIR或 PATH 提供Perl 模块通过PERL5LIB提供。OHOS 交叉编译使用 SDK Clang宿主 MSVC 构建使用 Windows 原生 Perl 与 MSVC 环境。两套编译器、sysroot 和 Perl 环境分开配置避免把宿主参数带入 OHOS 构建。安装与构建示例npminstall-gdeveco/deveco-clilatest devecocli--versionrustup targetaddaarch64-unknown-linux-ohoscargoinstallohrs--locked# 换成本机 DevEco Studio 的 SDK 目录exportDEVECO_SDK_HOMEDevEco Studio 安装目录/sdkexportCARGO_PROFILE_DEV_DEBUG0sourceharmonyos/env-windows.shpnpmbuild:ohos --build-mode debug若 npm 提示官方实现包的安装脚本未获准可仅对本次安装放行不必修改全局安全配置npminstall-gdeveco/deveco-clilatest --allow-scriptsdeveco/deveco-cli-common签名材料沿用本机配置并覆盖目标设备。新环境可在src-tauri/gen/ohos中查看devecocli signature generate --help证书、密码和设备标识不写进仓库教程。签名 HAP 输出位置src-tauri/gen/ohos/entry/build/default/outputs/default/entry-default-signed.hap在这里插入图片描述图 1早期最小应用验证2026-09-182in1 模拟器。smoke-app窗口已经显示Hello World用于区分基础显示链路与后面的 DBX 业务页面加载。四、让 RustAbility 真正加载业务页面路由和入口页面启动时的failed to create page: RustAbility指向页面入口与路由元数据而不是 Vue 业务代码。处理时保留项目显式配置的routerMap并补齐实际入口页入口组件为RustAbilityPage使用Entry({ routeName: RustAbility })声明页面内容沿用项目中的 RustAbility 实现。main_pages.json登记pages/RustAbilityWindowStage 使用实际页面路径加载awaitwindowStage.loadContent(pages/RustAbility);Ability HAR 放在 DevEco 项目根内的ohos-rs-ability/entry 通过本地依赖引用统一模块名为ohos_rs_ability。这样模块路径、包身份与页面入口都由同一个壳工程管理。图 2入口修复过程中的历史白窗2026-10-04真机。可见 DBX 窗口和标题但没有业务内容这是当时的页面加载现象截图不是修复后的运行结果。原生初始化与控制器关联两个启动顺序需要明确区分原生模块准备好之后才能创建业务窗口。EntryAbility.nativeReady保存异步初始化 PromiseonWindowStageCreate等待它完成再通知 Rust 生命周期并加载内容。Web 控制器关联到 Web 组件之后才能设置下载委托。SDK 曾明确报告The WebviewController must be associated with a Web component。委托注册从创建 Web 数据对象的阶段移到.onControllerAttached()再执行 URL / HTML 加载。图 3已解决问题的报错摘录图。依据 E59 / E60 留档与原始 crash 日志重新排版明确不是原始终端或设备截图保留页面入口、控制器关联和SIGILL的关键定位信息分别对应本节及第六节的处理过程。页面加载 API 返回成功只是中间证据。最终确认来自设备上的 UI 树和截图工具栏、连接侧栏、统计卡和常用操作均显示为真实 DBX 业务界面。五、修正私有数据目录的初始化时机OHOS 数据存储采用 Ability 的context.filesDir/identifier。原生初始化仍传入nativeModule.init({basePath:this.context.filesDir});定位启动异常时日志已经证明旧 XDG 数据目录解析成功随后访问 AbilitybasePath才进入异常路径。检查 Tauri 生命周期发现Builder::build()在 setup 运行前通过.take()消费全局 OHOS APP。因此不能在 setup 中再次从该全局读取 Ability 上下文。修复位于src-tauri/src/lib.rs在run()中、构建 Builder 之前取得basePath再把这个路径值移入 setup 闭包。存储目录仍由现有sandboxed_data_dir逻辑生成不改回共享用户目录。旧数据迁移沿用非覆盖策略复制到新的私有目录已有目标文件不覆盖旧目录不删除。解决的是上下文所有权与初始化时机而不是通过清空用户数据绕过问题。对应定位记录见harmonyos/errors.md的 E59。六、修复 OpenSSL ARM 特性检测导致的延迟退出这一问题说明了为什么短时间启动检查不足以证明运行链路正常应用启动后约 14 秒TLS 工作线程因SIGILL退出。对实际崩溃文件中的地址使用 SDKllvm-addr2line符号化定位到ChaCha20_ctr32_sve调用链经过 ChaCha20-Poly1305 TLS 加密。OpenSSL 3.6.3 的 ARM 特性检测没有把本轮 OHOS musl 环境识别为getauxval平台选择了基于信号的探测路径。修复采用 SDK 提供的辅助向量与 HWCAP而不是禁用 TLS、关闭证书校验或关闭全部汇编优化。scripts/ohos-openssl.h的关键内容#if!defined(__ASSEMBLER__)(defined(__aarch64__)||defined(__arm__))#includesys/auxv.h#defineOSSL_IMPLEMENT_GETAUXVAL#endif构建脚本统一使用该头文件设置CC_SHELL_ESCAPED_FLAGS1并把 forced-include 写成单个参数-include仓库路径/scripts/ohos-openssl.h。其中有三个具体处理点C 声明不进入汇编输入避免汇编器把 typedef 等声明当成指令。含空格的 Windows 路径由编译参数解析器正确处理。-include与文件名保持一个 joined 参数避免 OpenSSL Configure 把独立文件名识别成第二个构建目标。完整原生重编译后SDK 反汇编确认OPENSSL_cpuid_setup调用了getauxval(16)、getauxval(26)SVE / SVE2 分派由 HWCAP 控制。之后真机展示实际主界面并继续完成连接与窗口交互。对应记录见 E60。图 4完成入口、初始化时序和 HWCAP 修复后的真机主界面2026-10-04。工具栏、连接侧栏、统计卡和常用操作区均已显示为方便阅读此图由原始运行截图裁取应用窗口区域。与图 2 的历史白窗形成前后对照。七、接通页面与 OHOS 原生接口代理存在不等于方法已获准调用最初可以在页面中看到__DBX_OHOS_NATIVE__也能取得request函数但直接调用返回Error: Jsb Permission Denied。这将定位范围从“页面没有加载”收敛到 JSBridge 的授权与调用路径。当前请求入口在DbxPlatform.request()中读取 SDK 的getLastJavascriptProxyCallingFrameUrl()在解析和执行请求之前检查调用页面 URL。可信范围限定为应用的tauri://localhost、Tauri 本地 HTTP(S) 页面及指定的开发端口不采用页面自行传入的来源字符串。原生入口同步返回拒绝原因或空字符串前端据此处理调用拒绝业务结果仍通过异步回复完成页面 request({ id, action, ...options }) → 原生检查 SDK 报告的调用页面 → 执行文件或窗口操作 → __DBX_OHOS_REPLY__(id, value, error) → 前端完成对应 Promise设备上的只读state请求得到空的接受回执以及{ value: false, error: null }回复随后最大化、还原和文件选择器均通过真实页面操作触发。验证结束后临时状态探针、日志与诊断弹窗从源码移除。文件接口与数据库路径分开设计前端通过platformDialog.ts、platformFs.ts和ohosPlatform.ts接入原生接口桌面端继续使用原有插件。HAP 声明权限对应用途ohos.permission.INTERNET数据库连接及网络请求ohos.permission.FILE_ACCESS_PERSIST系统选择器所授文件、目录权限的持久化文件访问从用户操作系统选择器开始。普通导入复制为应用沙箱中的常规文件原 URI 的保留、描述符生命周期与授权恢复由 ArkTS 平台层管理。路径检查逐级检查符号链接并对保留描述符核对 inode不通过开放全部/proc来扩大访问范围。数据库使用普通沙箱文件。真机通过原生确认框创建filesDir/databases/时间戳/database.dbSQLite 表单的“测试”返回连接成功随后连接出现在应用侧栏和已连接统计中。这条路径将 SQLite 文件、锁与辅助文件放在同一应用存储范围内。图 5真机新建连接对话框2026-10-04。画面展示数据库分类和类型选择是从主界面实际进入连接流程的运行截图。窗口装饰和拖动落到正确的层DBX 自绘窗口按钮而 Tauri 配置中的decorations: false在本轮 OHOS 后端不能单独完成系统装饰管理。处理放在EntryAbility加载页面并设置窗口布局后显式调用setWindowDecorVisible(false)和setWindowTitleButtonVisible(false, false, false)。修改前系统装饰与应用自绘按钮同时出现。图 62026-09-18 的模拟器历史截图。关闭确认框后方仍可看到上下两组窗口控制按钮说明仅保留前端自绘控件不足以管理原生装饰。修改后应用工作区保留一组窗口控制按钮。图 72026-10-04 的真机 SQLite 工作区左侧显示已连接的验证连接右上保留一组最小化、最大化和关闭按钮。图片裁取应用区域编辑器中的PRAGMA是当时可见的编辑内容数据库连接成功依据前述表单测试与连接状态。最大化与还原分别使用主窗口的maximize()、recover()而不是调用桌面专属后端。拖动则分成两个时机前端pointerdown发起请求原生 Web.onTouch收到 Down 后记录状态在 Move 回调中同步调用startMoving()结束或取消触摸时释放拖动状态。真机几何变化提供了直接证据操作实际观察的窗口边界[left, top, right, bottom]初始浮动窗口[515, 292, 2605, 1686]点击应用最大化按钮[0, 0, 3120, 1978]点击还原按钮[515, 292, 2605, 1686]工具栏拖动(1600, 330) → (1750, 430)[665, 392, 2755, 1786]这里验证的是窗口真正改变了状态与位置而不是点击命令返回成功。主窗口截图同时显示右上角只有一组应用窗口控制按钮。八、OHOS 原生 Agent / 插件制品的构建原则平台键修正之后还需要让制品来源与 ABI 一致。agents/scripts/build_ohos_native.py使用 OHOS SDK Clang、sysroot 和目标 Rust 标准库构建真实原生可执行文件供 Agent / 插件构建流程调用。本段记录构建与制品校验本轮已经编译plugins/examples/hello-workbench/backend的 OHOS arm64 后端并通过 ELF 校验。检查包含 ELF64 小端格式、CPU 架构、可执行入口、程序头及加载段边界以及动态 musl 加载器不把普通 Linux glibc 制品改名成 OHOS 制品也不把加载器名称单独当成来源证明。# OHOS_SDK_ROOT 指向包含 native/ 的 SDKCMake/Ninja 位于 PATHpython agents/scripts/build_ohos_native.py--targetohos-arm64\--manifest-path plugins/examples/hello-workbench/backend/Cargo.toml\--bindbx-example-hello --target-dir target/ohos-plugin\--outputtarget/ohos-plugin/dbx-example-helloAgent 发布 job 使用DBX_OHOS_RUNNER、DBX_OHOS_SDK_ROOT指定原生构建环境。Go 与 Java 制品分别按 OHOS Go 工具链、OHOS JRE 的实际运行环境组织不使用GOOSlinux或普通 Linux JRE 代替目标平台。九、复现构建与实测的方法在仓库根目录部署已成功构建的签名产物--skip-build表示不重复构建并不省略安装与启动DEVICE设备名或序列号devecocli device listpnpmrun:ohos --skip-build--device$DEVICEdevecocli ui window list--device$DEVICEdevecocli ui layout--device$DEVICE--window窗口ID--depth20--formatjson devecocli ui screenshot--device$DEVICE--path截图路径.pngpnpmlogs:ohos--device$DEVICE--keywordDBX--tail100本次实测按以下证据链进行构建证据DevEco 完成 Rust / ArkTS 编译、HAP 打包与签名。页面证据设备 UI 树出现真实业务节点主界面截图为 3120×2080非黑像素约 54.98%并可见 DBX 工具栏、连接侧栏与操作区。交互证据实际打开新建连接、选择 SQLite系统文件选择器打开后取消可回到连接表单。原生证据桥接请求得到回复窗口最大化、还原和拖动具有可测量的边界变化。数据库证据应用沙箱中的 SQLite 文件连接测试成功并完成连接。截图先检查像素再检查可见内容设备需处于解锁、亮屏状态。日志经ohos_hilog.rs接入 hilog使用DBX标签检索。历史报错定位时同时参考实际崩溃文件和未剥离的 Rust 库避免仅凭启动命令或短时 Smoke 的返回值作结论。ArkWeb 代理调用与权限接口说明可参照官方 WebviewController 文档。功能到底能用到什么程度下面三张表是这份文档最实用的部分软件迁移能力按T0 / T1 / T2三档来列——T0 基础能力能不能编、能不能装、能不能起、能不能渲染、T1 主要能力数据库客户端的日常核心功能、T2 增强能力桌面端的加分项。表里的结论都取自正文各节和 2026-10-04 的真机实测证据状态分三种能用在真机上实际操作过并有可复核的证据构建输出、UI 树、截图、窗口边界或日志。待验证正文只给出做法或原则尚未给出实测结论。未适配桌面端专属能力OHOS 下按目标条件编译关闭属于按平台特点主动取舍。T0 基础能力能不能编、能不能装、能不能起、能不能渲染能力状态依据Rust 与原生 C/C 依赖交叉编译能用第二节、第三节ohrs/ Cargo 与 SDK Clang、sysroot、CMake、Ninja 编译aarch64-unknown-linux-ohos第六节 OpenSSL 重编译后经 SDK 反汇编确认 HWCAP 分派HAP 打包与签名能用第三节DevEco 完成 ArkTS 编译、HAP 打包与签名产物为entry-default-signed.hap真机安装与启动能用开头 2026-10-04 实测结果与第九节签名 HAP 在 HarmonyOS API 26 的 2in1 真机上覆盖安装并启动业务页面加载能用第四节RustAbilityPage与main_pages.json登记入口windowStage.loadContent(pages/RustAbility)第九节 UI 树出现真实业务节点主界面渲染能用第九节主界面截图 3120×2080、非黑像素约 54.98%工具栏、连接侧栏与操作区均可见页面与原生桥接能用第七节页面request()→ 原生校验调用页面 →__DBX_OHOS_REPLY__回复设备上只读state请求取得回执窗口装饰与窗口操作能用第七节setWindowDecorVisible(false)、setWindowTitleButtonVisible(false, false, false)后只保留一组应用按钮最大化、还原、拖动的窗口边界实测发生变化运行日志与崩溃可定位能用第六节、第九节日志经ohos_hilog.rs接入 hilog标签DBXSIGILL退出用llvm-addr2line定位到ChaCha20_ctr32_sve小结编、装、起、渲染这条底线上每一环都有真机证据第九节把构建、页面、交互、原生、数据库五类证据分别列出不靠启动命令的返回值下结论。T1 主要能力数据库客户端的日常核心能力状态依据新建连接流程能用第七节图 5真机进入新建连接对话框显示数据库分类与类型SQLite native 驱动端到端能用第七节在filesDir/databases/时间戳/database.db建库「测试」返回连接成功连接随后出现在侧栏与已连接统计中应用私有数据目录能用第五节使用context.filesDir/identifier初始化时机修正后不再依赖共享 XDG 目录旧数据按非覆盖策略迁移旧目录保留文件读写与系统选择器能用第七节platformDialog.ts、platformFs.ts、ohosPlatform.ts接入原生接口选择器打开后取消可回到连接表单ohos.permission.FILE_ACCESS_PERSIST持久化授权宿主构建链路可复现能用第三节harmonyos/env-windows.sh与scripts/ohos.mjs在 Windows x64 宿主上一条命令完成前端、Rust 库与 HAP 构建OHOS 原生 Agent / 插件制品Rust 侧能用第八节编译hello-workbench的 OHOS arm64 后端并通过 ELF 格式、架构、程序头与 musl 加载器等校验Go / Java 原生制品待验证第八节说明按 OHOS Go 工具链与 OHOS JRE 的实际运行环境组织但未给出对应构建与运行实测结论小结数据库客户端的日常主线新建连接、系统选择器、私有目录、SQLite 连接测试与连接都已在真机跑通没有实测结论的只有 Go / Java 原生制品这一项它属于制品矩阵的工程量不是配置问题。T2 增强能力桌面端的加分项能力状态依据系统托盘未适配第二节按目标条件编译OHOS 构建不引入托盘依赖原生菜单未适配第二节与托盘同样按目标条件编译桌面插件未适配第二节桌面插件按平台门控Tauri capabilities 拆分为公共声明与桌面插件声明第七节中文件、对话框等能力改由platformDialog.ts、platformFs.ts等平台入口承担桌面端继续使用原有插件小结这一档没有一项是「做不出来」——托盘、原生菜单、桌面插件在 OHOS 上本就没有对应的系统概念按平台条件编译关闭而不是硬搬。这么算下来整体到什么程度把上面三张表合起来看T0 基础能力Rust 与原生依赖交叉编译、HAP 打包签名、覆盖安装与启动、业务页面加载、主界面渲染均在真机上实测通过。T1 主要能力页面与原生桥接往返、窗口装饰处理与最大化/还原/拖动、系统文件选择器、应用私有数据目录、SQLite 连接测试与连接、Rust 侧原生插件制品构建均在真机上实测通过Go / Java 原生 Agent / 插件制品只给出组织原则尚无实测结论。T2 增强能力系统托盘、原生菜单、桌面插件按平台条件编译关闭属于按平台特点主动取舍不是没做出来。这里不折算百分比三张表每一项都对应正文的实测证据或明确的取舍说明缺实测证据的项如实标为「待验证」不用估算把表补满。一句话总结DBX 已在 HarmonyOS API 26 的 2in1 真机上完成签名 HAP 的覆盖安装与启动业务页面、原生桥接、窗口操作、文件选择器、私有数据目录与 SQLite 连接等日常链路均已实测跑通托盘、原生菜单、桌面插件按平台特点关闭Go / Java 原生制品只给出组织原则、尚无实测结论。关于 OpenHarmony PC 社区加入开源鸿蒙 PC 社区的引导见本文开头。欢迎在 PC 社区平台申请新建项目https://atomgit.com/OpenHarmonyPCDeveloper本项目按社区规范提交入库申请命名按社区「项目命名指导」仓库统一命名为ohos_项目名项目名与官网保持一致社区同规范仓库如ohos_marktext、ohos_joplin。本项目对应ohos_dbx。流程在社区community仓按「新建仓库指南」提交 issue 申请标题规范为【新建仓申请-XXX】审批通过后由社区维护者创建仓库代码托管至 https://atomgit.com/OpenHarmonyPCDeveloper。README 与变更记录按社区「开源项目发布规范」仓库根 README 保持「简介 / 安装 / 权限 / 使用示例 / 约束与限制含支持的 API 与 SDK 版本/ 目录结构 / 贡献 / 协议」等要素License 与 ChangeLog 随仓库提供。目标仓库地址https://atomgit.com/OpenHarmonyPCDeveloper/ohos_dbx仓库尚在社区审批流程中暂未生效。