Openharmony的编译构建--进阶篇2

本文介绍了在OpenharmonyV3.1中如何新建子系统并在其部件下添加模块,涉及BUILD.gn配置、bundle.json修改、subsystem_config.json更新等步骤。同时,提到了BUILD.gn的不同模板如ohos_hap、ohos_source_set和action的使用,以及Openharmony编译构建的运行机制。

承接上一篇Openharmony的编译构建--进阶篇1中说明了在Openharmony V3.1的如何在标准系统即L2设备添加一个模块的两种情况,此篇对第三种情况进行说明。

四、新建子系统并在该子系统的部件下添加模块

1.在模块目录下配置BUILD.gn,根据类型选择对应的模板

2.新建包含该模块所属部件的bundle.json

此前两步与前面介绍的两种方式并无区别。

3.修改//build/subsystem_config.json

比如:在foundation目录下新建test_subsystem,将第一步与第二步新建的bundle.json与BUILD.gn移入。

修改bundle.json中"subsystem": "test_subsystem",并且BUILD.gn中的subsystem_name = "test_subsystem",part_name = ""进行修改。

{
  "ace": {
    "path": "foundation/ace",
    "name": "ace"
  },
  "ai": {
    "path": "foundation/ai",
    "name": "ai"
  },
  "account": {					# 子系统
    "path": "base/account",		# 子系统目录
    "name": "account"			# 子系统名称
  },
  # 新增示例如下:
  "test_subsystem": {
    "path": "foundation/test_subsystem",
    "name": "test_subsystem"
  }, 
...
}

4.//productdefine/common/products/rk3568.json文件添加部件"account:os_account_test":{}

不再赘述。

Openharmony里执行

./build.sh --product-name rk3568

编译完成后,在//out/rk3568/test_subsystem/目录下可以找到编译完成的可执行文件与动态库。

五、BUILD.gn的其它模板

一些常用的模板类型:

# 生成系统hap
ohos_hap	
# 拷贝文件
ohos_copy
# 源目标集合
ohos_source_set
# 执行脚本,支持shell、python
action
# 工作集
group
# 配置集合
config

ohos_hap例子

ohos_hap("clock")
  hap_profile = "./src/main/config.json" # config.json
  js_assets = ["./src/main/js/defaults"]
  raw_assets = ["./raw_assets"]
  resources = ["./src/main/resources"]
  shared_libraries = ["//third_party/libpng:libpng"] # native库
  certificate_profile = "../signature/systemui.p7b"	 # Cer文件
  hap_name = "SystemUI-NavigationBar" 	# hap包名字
  part_name = "prebuilt_hap"
  subsystem_name = "application"
}
  • 声明一个hap目标,该目标会生成一个hap包,最终将会打包到system镜像中

  • 支持的变量

1.hap_profile:hap包的config.json

2.js_assets:js资源,编译后放置在assets/js/default目录下

3.raw_assets:原始assets,这些assets会直接拷贝到hap包的assets目录下

4.resources:资源文件,编译后放置在assets/entry/resources目录下

5.deps:当前目标的依赖

6.shared_libraries:当前目标依赖的native库

7.hap_name:hap包的名字,可选,默认为目标名

8.final_hap_path:用户可以制定生成的hap的位置,可选,final_hap_path中会覆盖hap_name

9.subsystem_name: hap包从属的子系统名,需要和bundle.json中的名字对应,否则将导致无法安装 到system镜像中

10.part_name: hap包从属的部件名。同subsystem_name

11.js2abc: 是否需要将该hap包转换为ARK的字节码

12.certificate_profile: hap对应的授权文件,用于签名

13.certificate_file: 证书文件,证书文件和授权文件,应用开发者需要去openharmony官网申请

14.keystore_path: keystore文件,用于签名

15.keystore_password: keystore的密码,用于签名

16.key_alias: key的别名

17.module_install_name: 安装时的hap包名称

18.module_install_dir: 安装到system中的位置,默认安装在system/app目录下

ohos_source_set例子:

ohos_source_set("glib_source") {
  source = [
  	"glib/deprecated/gallocator.c",
  	"glib/deprecated/gcache.c",
  	"glib/deprecated/grel.c",
  	...
  ]
  configs = [ ":glib_config"]
}

ohos_shared_library("glib") {
  deps = [ ":glib_source"]
  part_name = "multimedia_media_standard"
  subsystem_name = "multimedia"
}

action例子:

action("gen_config_header") {
  script = "//third_party/ffmpeg/ohos_config.sh"
  
  args = [
    rebase_path("//third_party/ffmpeg", root_build_dir),
    rebase_path("${target_gen_dir}/include/", root_build_dir),
  ]
  
  outputs = [ "${target_gen_dir}/include/config.h"]
}

六、Openharmony编译构建的运行机制

Openharmony侧的编译构建流程主要包含编译命令行解析,调用gn,执行ninja:

  • 命令行解析:解析待编译的产品名称,加载相关配置

  • 调用gn:根据命令行解析的产品名称和编译类型,配置编译工具链和全局的编译选项

  • 执行ninja:启动编译并生成对应的产品版本。

后续更精彩

1.L0与L1的编译构建过程以及后续V3.2版本的构建流程稍有不同,但是如果了解了Openharmony的编译构建的运行机制,可以理解相应的产品的编译过程。如果在技术朋友在此方面有疑惑时,可以留言与私信,或者如果提问的朋友相对较多时,再开一篇进行解析说明。

2.各位朋友和技术爱好者有想了解Openharmony的相关子系统或者框架的,可以留言或私信。

<think>嗯,用户这次的问题是关于OpenHarmony构建时出现的子系统名称不匹配错误:"product_rk3566"vs"device_rk3566"。这显然是个典型的组件配置冲突问题,需要结合用户提供的引用资料来分析。从用户提供的引用内容来看:引用[2]里展示了config.json文件的结构,特别是product_name/device_company/board这些字段的对应关系引用[3]提到构建模板类型,暗示着可能存在多级配置继承关系引用[4]指向环境搭建文档,虽然不直接相关但提醒我要考虑环境配置因素用户真正的问题是构建系统在检查subsystem一致性时发现product和device两部分用了不同前缀(product_vsdevice_),这通常发生在:1芯片厂商的device配置和产品厂商的product配置命名规范不统一2新导入芯片或产品时没有同步修改关联配置考虑到用户是RK3568/RK3566平台(从引用[1]路径推测),这类Rockchip芯片的开发板确实容易出现命名不一致问题,因为硬件适配层(HDF)和产品配置通常是不同团队维护的。解决方案应该分三层处理:最直接的是修改JSON配置文件的字段对应,如引用[2]显示的subsystem嵌套结构其次要检查build_configs目录下的subsystem_build_config.json,这是实际构建时使用的合并配置更深层可能需要调整芯片适配层的hdf_driver/BUILD.gn,因为device_前缀常在这里定义用户可能遇到的难点是找不到所有关联文件的位置,所以我在回复中特别标注了关键路径。考虑到TA正在做产品化适配,补充了关于新增子系统的建议——因为有时候错误是因为遗漏了自定义子系统的声明。补充的进阶建议里强调了SDK版本和芯片解耦的思路,这其实是OpenHarmony官方最近在推的最佳实践(从v3.2开始强调的"deviceprofile"概念)。最后提示编译日志分析工具的使用,因为实际配置是树状继承的,直接看日志比翻文档更高效。</think> 在OpenHarmony构建过程中出现`subsystem name mismatch error 'product_rk3566' vs 'device_rk3566'`错误,通常是由于子系统名称在**设备层(device)**和**产品层(product)**的配置文件中未对齐造成的。以下是系统化的解决方案: --- ### **解决方法分步说明** #### 1. **检查设备层配置文件路径** 确认芯片厂商的`device`目录下配置是否正确: ```text vendor/芯片厂商/rk3566/device_rk3566.json ``` **关键字段**: ```json { "device_name": "device_rk3566", // 设备标识名 "device_company": "Rockchip", // 芯片厂商 "subsystems": [] // 子系统列表 } ``` #### 2. **修改产品层配置文件路径** 在产品目录同步设备标识名: ```text vendor/产品厂商/my_product/config.json ``` **修正字段**: ```json { "product_name": "my_product", "device_company": "Rockchip", // ⚠️ 此处必须与device层一致 ⚠️ "board": "rk3566", // 改为对应芯片名称 "subsystems": [ { "subsystem": "ace", "components": [ ... ] } ] } ``` --- ### **核心冲突点** - **设备层标识**:在 `device/芯片厂商/rk3566/` 中的配置名称(如`device_rk3566`) - **产品层引用**:在 `vendor/产品厂商/my_product/` 中`config.json`的`"board"`字段必须**严格匹配设备层芯片名称**(此处应为`rk3566`而非`product_rk3566`) > 💡 **根源说明**:构建系统会校验设备层与产品层的`device_company + board`组合是否一致。例如当设备层定义为`device_rk3566`时,产品层`board`字段须为`rk3566`而非自定义名称(如`product_rk3566`)[^1][^2]。 --- ### **拓展场景:新增子系统** 若需添加自定义子系统,需同时在**设备层**和**产品层**声明: 1. 在`device/芯片厂商/rk3566/device_rk3566.json`中添加: ```json "subsystems": [ { "subsystem": "my_subsystem", // 子系统名 "components": [ { "component": "my_component" } ] } ] ``` 2. 在`vendor/产品厂商/my_product/config.json`中镜像该声明: ```json "subsystems": [ { "subsystem": "my_subsystem", // 名称完全一致 "components": [ ... ] } ] ``` --- ### **进阶建议** - **依赖隔离**:使用`deps`分隔芯片相关配置(`device_`前缀)和产品特性(`product_`前缀),避免命名耦合 - **版本对齐**:确认OpenHarmony SDK版本与设备层编译模板一致(参考`ohos_prebuilt_shared_library`等模板定义[^3]) - **日志排查**:运行`./build.sh --product-name my_product --build-target=make_all` 后检查`out/rk3568/build_configs/subsystem_info/*.json`校验合并结果[^1] > 📌 **引用说明**:本文解决方案综合了OpenHarmony设备层与产品层配置的匹配规范[^2],子系统声明机制[^3],以及构建系统的配置合并流程[^1]。 --- ### 相关问题 1. 如何为OpenHarmony设备新增一个自定义子系统? 2. 设备层(device)和产品层(product)在编译流程中的交互逻辑是什么? 3. 如何查看OpenHarmony构建过程中的完整子系统依赖树? 4. 当芯片型号升级(如rk3566→rk3576)时,如何高效迁移设备层配置?
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值