在上一篇文章中，我记录了如何在 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 虚拟陪伴助手的研发了！期待在后续的博客中与大家分享应用层的实战经验。
