在上一篇文章中，我记录了如何在 OpenHarmony 移植初期，通过 hdc shell 强行手动构建目录、配置网络，最终让 RISC-V 开发板连上公网的过程。

那种通过命令行直接操控底层硬件的感觉很爽，但爽过之后，必须回归工程现实。作为团队的一员，我不能指望负责系统全量编译的队友（比如 dfq）每次刷机后都用这套繁琐的流程去重新联网。

一个成熟的系统软件工程师，不应只停留在“能把问题修好”，更要做到“把解决方案沉淀到架构中”。今天这篇文章，我将详细记录我是如何将一次临时的“手工 Hack”，一步步翻译成 OpenHarmony 的源码补丁（Patch），并交付给队友进行自动化整合的。

核心思维转换：从“现场搭积木”到“修改建筑图纸”

理解源码修改的第一步，是思维模式的转换。

在板子上敲命令，就像是拿到了一套盖好的毛坯房，发现没水没电，于是自己找管子、接电线，勉强能住。但是一旦开发板被重新烧录，房子被推倒重来，一切配置又要从零开始。

而修改源码，是去修改这栋楼的建筑图纸。我要在图纸上标明：“以后出厂的每一套房子，必须自带 wpa_supplicant 这个家具，必须把网络配置文件放在指定抽屉里，且一通电必须自动把网连上”。

按照这个思路，我将本次源码固化分为了三个关键战役。

战役一：组件注入 —— 让系统出厂自带“工具箱”

之前我们在 /vendor/bin/ 下找不到 WiFi 工具，是因为编译系统默认没有把它们打包进去。我们需要在板子的配置清单里显式声明。

我定位到了开发板的核心配置文件 device/board/spacemit/musepaper2/ohos.build 和具体的编译逻辑文件 BUILD.gn。

在 ohos.build 中，我在 spacemit_products 的 module_list 末尾加入了依赖：

"module_list": [
    ...
    "//third_party/wpa_supplicant:wpa_supplicant",
    "//third_party/wpa_supplicant:wpa_cli",
    "//vendor/spacemit/musepaper2/wifi_config:wifi_config_file"
]

并在 BUILD.gn 的 musepaper2_group 的 deps 中做了同样的补充。 思考： OpenHarmony 的 gn/ninja 编译系统是高度模块化的。通过修改这两处，等于告诉编译服务器：“请在下一次构建镜像时，把这些第三方工具和我的自定义配置一同打包进 /vendor/ 分区”。

战役二：配置持久化 —— “无中生有”的说明书

工具进去了，还需要配置文件。之前在板子上我是用 echo 临时写的 wpa_supplicant.conf。在源码层面，我需要在 vendor/spacemit/musepaper2/ 目录下新建一个 wifi_config 文件夹，并创建这个 .conf 文件。

但仅仅放一个文件在那儿，编译器是不会理睬的。必须配上专门的打包规则。我编写了一个 BUILD.gn：

import("//build/ohos.gni")

ohos_prebuilt_etc("wifi_config_file") {
  source = "wpa_supplicant.conf"
  module_install_dir = "etc/wifi"
  part_name = "spacemit_products"
}

这短短几行代码非常优雅地解决了一个底层问题：使用 ohos_prebuilt_etc 模板，系统会在编译时自动将我的配置文件挪到镜像的 /vendor/etc/wifi/ 目录下，实现了真正的“出厂预置”。

战役三：开机自启逻辑 —— 雇佣一个“智能管家”

工具和配置都有了，最后也是最关键的一步：系统重启后，谁来拉起这个服务？

在 OpenHarmony 中，系统启动由 init 进程接管，它的行为完全由 .cfg 文件定义。我找到了 device/board/spacemit/musepaper2/cfg/init.musepaper2.cfg 这个“开机剧本”。

这里需要分两步走： 1. 文件系统准备（fs 阶段）： WiFi 服务启动前需要套接字目录。我在 jobs 的 fs 阶段加入了目录创建和权限分配指令：

"cmds" : [
    ...
    "mkdir /data/service/el1/public/wifi 0771 wifi wifi",
    "mkdir /data/service/el1/public/wifi/wpa_supplicant 0771 wifi wifi",
    "mkdir /data/service/el1/public/wifi/sockets 0771 wifi wifi"
]

注意这里的 wifi wifi 权限设定。Linux 的权限管理是严苛的，不赋予正确的用户组，服务根本跑不起来。

2. 注册常驻服务（services 阶段）： 接着，我在剧本的 services 数组中添加了 WiFi 守护进程：

{
    "name" : "wpa_supplicant",
    "path" : ["/vendor/bin/wpa_supplicant", "-B", "-i", "wlan0", "-c", "/vendor/etc/wifi/wpa_supplicant.conf"],
    "uid": "wifi",
    "gid": ["wifi", "system"],
    "secon": "u:r:wpa_supplicant:s0"
}

这段配置定义了进程的启动路径、依赖的配置文件、运行的 UID/GID，以及非常重要的 SELinux 安全上下文（secon）。

交付闭环：项目团队的协作之道

完成上述所有文件的备份、修改与本地代码审查后，我将这 5 个关键文件的绝对路径和作用整理成了一份标准的《补丁合并指南》，打包发送给了负责主线代码整合的队友 。

虽然我们的完整镜像编译目前还在不断调优中，但可以确定的是，只要这份源码补丁合入主线，底层网络的基建就算彻底扫清了障碍。

总结与感悟： 从应用层开发转向底层系统移植，最大的挑战在于没有 IDE 惯着你。所有的错误都在冷冰冰的日志里，所有的配置都要遵循严苛的系统生命周期。但当你理清了 BUILD.gn 的依赖关系，看懂了 init.cfg 的启动时序，看着自己写的一行行脚本随着固件烧录，赋予了一块冷冰冰的电路板连接世界的能力时，那种属于程序员的极致快乐，是难以言表的。

接下来，有了稳定的网络支撑，我终于可以放开手脚，去推进我们项目实训的重头戏——3D 虚拟陪伴助手的研发了！期待在后续的博客中与大家分享应用层的实战经验。