HarmonyOS鸿蒙Next中关于OH50、51及以后的串口arkui开发的询问

HarmonyOS鸿蒙Next中关于OH50、51及以后的串口arkui开发的询问 各位大佬好，本人目前正在苦于deveco studio使用arkui进行串口收发的问题。

之前我在OH41、51上已经实现小型系统上修改JS运行时态(@system.app)（北向，把HDF那一套用在这里面，C++编写），添加南向代码，实现图形化界面点击按钮控制LED灯的效果。

目前问题是在OH50的标准系统上，目前我已经修复好官方uart_adapter的代码，实现南向使用HDF的Dispatch来操控串口进行通信，那么按之前的经验，下一步应修改北向代码，也是修改 JS运行时态，但是由于现在是针对标准系统，我找不到方式入手。因为在源码里面一个是 ace_engine 和 ace_engine_lite。代码挺大不同。

再者，其实不应该在@system.app对应的源码上修改，因为本来这个包不应该有串口这些功能在里面，应该自行实现一个包，再自行调用。

主要本人的技能是嵌入式为主，所以对JS这些不太了解。

我在网上看大家说要自行实现NAPI，但是我这边NAPI貌似还没实现完全，一跑到NAPI里面就闪退（LA架构）而且NAPI的使用场景貌似也不是用在外设交互里面。

综述，我的问题如下：

  1. 如何实现在标准系统下实现@system.app的修改，添加自己的接口？
  2. 如何自己实现一个类似于@system.app的包？

还有一个问题，我看网上说，OH51开始才用官方提供的串口接口，但是我看的是 @ohos.usbManager.serial 看着好像是只适用USB串口。我改完 uart_adapter 的代码是想用在 /dev/ttyS1 这些设备里面的。难道就算用新API也不能操控 /dev/ttyS1 吗？


更多关于HarmonyOS鸿蒙Next中关于OH50、51及以后的串口arkui开发的询问的实战教程也可以访问 https://www.itying.com/category-93-b0.html

2 回复

鸿蒙Next中OH50及以后版本，串口开发使用ArkTS语言。通过@ohos.serialport模块实现串口通信，支持打开、配置、读写等操作。需在module.json5中声明ohos.permission.USE_SERIAL_PORT权限。

更多关于HarmonyOS鸿蒙Next中关于OH50、51及以后的串口arkui开发的询问的实战系列教程也可以访问 https://www.itying.com/category-93-b0.html


针对你的问题，结合HarmonyOS Next的架构演进，核心思路已从直接修改运行时转向基于扩展框架进行开发。

1. 标准系统下如何添加接口（替代修改@system.app） 在标准系统（OH50+）中，不应直接修改[@system](/user/system).app或Ace Engine源码。正确的路径是开发Native API（NAPI）扩展，并通过ArkTS接口暴露给应用。这是系统支持的扩展方式。

  • NAPI是实现关键：你遇到的闪退问题，很可能是NAPI模块注册、与ArkTS侧的类型映射、或线程模型不正确导致的。NAPI正是用于桥接C/C++（你的HDF驱动交互代码）与ArkTS应用层，是外设交互的标准桥梁。你需要确保你的NAPI模块在napi_module_register阶段正确注册，且导出的函数符合NAPI规范。
  • 创建HAP包：将编译好的NAPI库（.so）和对应的ArkTS接口定义（.d.ts）打包到HAP中。应用通过import你的模块来调用接口。

2. 如何实现自己的扩展包 这实质是创建一个自定义的HarmonyOS Ability Package。

  • 工程结构：在DevEco Studio中创建Library类型的模块。
  • 接口定义：在ets目录下提供ArkTS的API定义文件（.d.ts），声明可供调用的方法。
  • NAPI实现：在cpp目录下实现具体的NAPI代码，这里调用你已实现的HDF Dispatch层来控制串口。
  • 打包与引用：将该模块编译打包为.har文件，供其他应用作为依赖引用。这便是一个类似[@system](/user/system).app的自定义功能包。

3. 关于串口API（@ohos.usbManager.serial与/dev/ttyS1） 你的理解是正确的。@ohos.usbManager.serial API设计用于管理USB转串口适配器（如/dev/ttyUSB*），并非直接操作原生UART设备节点（如/dev/ttyS1）。

  • 你通过修改uart_adapter并经由HDF驱动操作/dev/ttyS1的路径，在标准系统下需要通过上述自定义NAPI扩展的方式向上提供ArkTS接口。目前OpenHarmony官方并未在标准系统的应用框架层直接提供操作原生串口的统一ArkTS API。

总结建议 停止尝试修改运行时源码。你的工作重点应转为：

  1. 调试并完善你的NAPI实现，确保其能稳定运行。这是连接HDF驱动与ArkUI应用的核心。
  2. 在DevEco Studio中建立独立的Library工程，将NAPI封装为ArkTS接口，形成可复用的HAR包。
  3. 在你的UI应用中依赖并调用这个自定义HAR包，实现通过ArkUI按钮控制串口的功能。

这符合HarmonyOS Next的标准开发范式，能确保应用的兼容性和可维护性。

回到顶部