1.OpenHarmony源码解析之电话子系统——通话流程
2.OpenHarmony—内核对象事件之源码详解
3.OpenHarmony Camera源码分析
4.OpenHarmony编译构建系统详解，源译从零搭建windows下开发环境，码编巨方便！源译
5.OpenHarmony代码下载编译及源码跳转配置
6.4步成功将三方库——speexdsp移植到OpenHarmony

OpenHarmony源码解析之电话子系统——通话流程

       OpenAtom OpenHarmony的码编电话子系统为OS提供了基础的无线通信能力，支持多种网络制式，源译包括高速无线数据传输和互联网接入。码编火影ol源码主要功能涵盖语音、源译短信、码编彩信、源译SIM卡管理等。码编

       电话子系统是源译OpenHarmony架构的重要组成部分，负责CS域（如语音呼叫）和PS域（如数据业务）的码编服务。系统结构包括应用层（如电话应用、源译短信应用等）、码编框架层（SDK提供接口，源译Framework提供功能模块，如call_manager、cellular_call等）、Hril层（抽象无线硬件设备）和Vendor lib层（与modem交互）等。

       代码结构方面，通话管理模块负责CS、IMS和OTT通话，蜂窝通话模块支持2G到5G的语音和数据功能。电话核心服务提供RIL管理和SIM卡功能，数据库模块负责数据存储。RIL Adapter模块屏蔽硬件差异，短彩信模块处理短信和彩信功能，状态注册模块监控网络状态等变化。

       源码解析中，通话功能的实现涉及多个模块间的协作，如通话管理、蜂窝通话服务、Telephony核心服务和RIL适配。以电话接听（Answer）为例，流程从用户点击answer，通过层层调用，涉及call_manager、cellular_call等服务，最终到达modem处理AT命令。整个过程显示了系统内部复杂的服务交互和跨层通信机制。

       电话子系统的核心类处理了各种通话类型和上层应用的接口，如dial、answer等。从UI响应到调用底层modem，每个环节都体现了OpenHarmony的模块化设计和通信流程。

OpenHarmony—内核对象事件之源码详解

       对于嵌入式开发和技术爱好者，raknet 源码深入理解OpenHarmony的内核对象事件源码是提升技能的关键。本文将通过数据结构解析，揭示事件机制的核心原理，引导大家探究任务间IPC的内在逻辑。

       关键数据结构

       首先，了解PEVENT_CB_S数据结构，它是事件的核心：uwEventID标识任务的事件类型，个位（保留位）可区分种事件；stEventList双向循环链表是理解事件的核心，任务等待事件时会挂载到链表，事件触发后则从链表中移除。

       事件初始化

       事件控制块由任务自行创建，通过LOS_EventInit初始化，此时链表为空，表示没有事件发生。任务通过创建eventCB指针并初始化，开始事件管理。

       事件写操作

       任务通过LOS_EventWrite写入事件，可以一次设置多个事件。1处的逻辑允许一次写入多个事件。2-3处检查事件链表，唤醒等待任务，通过双向链表结构确保任务顺序执行。

       事件读操作

       轻量级操作系统提供了两种事件读取方式：LOS_EventPoll支持主动检查，而LOS_EventRead则为阻塞读。1处区分两种读取模式，2-4处根据模式决定任务挂起或直接读取。

       事件销毁操作

       事件使用完毕后，需通过LOS_EventClear清除事件标志，并在LOS_EventDestroy中清理事件链表，确保资源的正确释放。

       总结

       通过以上的详细分析，OpenHarmony的内核事件机制已清晰可见。掌握这些原理，开发者可以更自如地利用事件API进行任务同步，并根据需要自定义事件通知机制，提升任务间通信的灵活性。

OpenHarmony Camera源码分析

       当前，开源在科技进步和产业发展中扮演着越来越重要的角色，OpenAtom OpenHarmony（简称“OpenHarmony”）成为了开发者创新的温床，也为数字化产业的发展开辟了新天地。作为深开鸿团队的OS系统开发工程师，我长期致力于OpenHarmony框架层的研发，尤其是对OpenHarmony Camera模块的拍照、预览和录像功能深入研究。

       OpenHarmony Camera是joytokey 源码多媒体子系统中的核心组件，它提供了相机的预览、拍照和录像等功能。本文将围绕这三个核心功能，对OpenHarmony Camera源码进行详细的分析。

       OpenHarmony相机子系统旨在支持相机业务的开发，为开发者提供了访问和操作相机硬件的接口，包括常见的预览、拍照和录像等功能。

       系统的主要组成部分包括会话管理、设备输入和数据输出。在会话管理中，负责对相机的采集生命周期、参数配置和输入输出进行管理。设备输入主要由相机提供，开发者可设置和获取输入参数，如闪光灯模式、缩放比例和对焦模式等。数据输出则根据不同的场景分为拍照输出、预览输出和录像输出，每个输出分别对应特定的类，上层应用据此创建。

       相机驱动框架模型在上层实现相机HDI接口，在下层管理相机硬件，如相机设备的枚举、能力查询、流的创建管理以及图像捕获等。

       OpenHarmony相机子系统包括三个主要功能模块：会话管理、设备输入和数据输出。会话管理模块负责配置输入和输出，以及控制会话的开始和结束。设备输入模块允许设置和获取输入参数，而数据输出模块则根据应用场景创建不同的输出类，如拍照、预览和录像。

       相关功能接口包括相机拍照、预览和录像。相机的主要应用场景涵盖了拍照、预览和录像等，本文将针对这三个场景进行流程分析。

       在分析过程中，我们将通过代码注释对关键步骤进行详细解析。以拍照为例，首先获取相机管理器实例，然后创建并配置采集会话，包括设置相机输入和创建消费者Surface以及监听事件，lightapp 源码配置拍照输出，最后拍摄照片并释放资源。通过流程图和代码分析，我们深入理解了拍照功能的实现。

       对于预览功能，流程与拍照类似，但在创建预览输出时有特定步骤。开始预览同样涉及启动采集会话，并调用相关接口进行预览操作。

       录像功能则有其独特之处，在创建录像输出时，通过特定接口进行配置。启动录像后，调用相关方法开始录制，并在需要时停止录制。

       通过深入分析这三个功能模块，我们对OpenHarmony Camera源码有了全面的理解，为开发者提供了宝贵的参考和指导。

       本文旨在全面解析OpenHarmony Camera在预览、拍照和录像功能上的实现细节，希望能为开发者提供深入理解与实践的指导。对于感兴趣的技术爱好者和开发者，通过本文的分析，可以更深入地了解OpenHarmony Camera源码，从而在实际开发中应用这些知识。

OpenHarmony编译构建系统详解，从零搭建windows下开发环境，巨方便！

       OpenHarmony的dev-tool更新让在Windows下搭建鸿蒙系统开发环境变得便捷，尤其对于MCU开发者来说。本文将带你从头开始，详细讲解如何在Windows上搭建dev-tool环境，降低学习OpenHarmony的门槛。首先，理解OpenHarmony的编译构建框架至关重要，它基于GN和Ninja构建，组织平台、子系统和组件，构建过程类似用针线制作衣服，通过命令行驱动，GN生成Ninja文件指导构建。

       在2.0版本中，大部分组件已采用GN和Ninja，未来将全面替代。构建流程包括设置和编译两个步骤，cvwarpperspective 源码通过命令行工具如"hb set"和"hb build"来操作。具体过程可在weharmonyos.com的文档中获取更详尽信息。

       环境搭建则需要准备GNU环境，因为OpenHarmony主要依赖GNU工具链，包括在Windows上安装对应版本的Python、Node.js和hpm，以及Visual Studio Code和DevEco Device Tool。其中，Python和Node.js的安装需注意版本选择，而DevEco Device Tool的安装需注意避免中文字符在用户名中，且可能需要设置npm代理。

       针对HiV开发板，需要下载专用源代码，设置正确的编译工具链，并在DevEco Device Tool中进行编译操作。整个过程包括设置工具链、打开工程、执行编译任务，直至看到"SUCCESS"。目前仅支持轻量型系统和Hi开发板，后续将扩展支持其他开发板。

       现在，你已经具备了在Windows上搭建OpenHarmony开发环境的完整流程，开始你的鸿蒙OS学习之旅吧！

OpenHarmony代码下载编译及源码跳转配置

       本文旨在指导在Linux（如Ubuntu .和.，其他系统可参考）环境下下载和编译OpenHarmony（OH）代码，并配置Visual Studio Code（VSCode）以实现Native框架（C++）代码的智能跳转，以提升阅读OH源码的便捷性。

       1. 下载与编译

       从OH官网下载链接（gitee.com/openharmony/d...）获取代码。进入代码根目录后，执行build.sh脚本，例如针对rk开发板的编译命令会包含选项`--gn-flags="--export-compile-commands"`，用于生成compdb数据库，以备后续使用。

       2. VSCode插件与配置

       在编译过程中，安装VSCode的clangd插件，它与compdb文件配合。记得禁用默认的C/C++插件。接着，使用VSCode通过SSH（Windows和macOS用户适用）访问OH源代码目录，创建.vscode文件夹，其中包含settings.json。

       3.1. 插件安装与启用

       在settings.json中填写以下配置：

       - clangd.path: 指定OH预构建的clangd路径。

       - --compile-commands-dir: 编译产生的compdb文件路径，例如在rk上为out/rk/compile_commands.json，需根据实际编译产品找到相应路径。

       - --query-driver: 指定OH预构建的clang编译器路径。

       3.2. VSCode配置

       关闭并重新打开VSCode，当C++文件（如foundation文件夹下的Native C++代码）打开时，clangd将开始索引，索引完成后即可享受代码跳转功能。

4步成功将三方库——speexdsp移植到OpenHarmony

       四步实现三方库移植：

       第一步：三方库的下载与Linux下编译分析。下载最新分支代码，通过分析编译过程，确保正确构建动态链接库与测试用可执行文件。这一步通常涉及两种编译方式：一是通过CMakeLists.txt文件在原生库根目录中使用cmake或cmake-gui生成makefile，然后执行make；二是通过autogen.sh和configure.ac文件在原生库目录中构建，使用./autogen.sh和./configure生成Makefile，最后执行make和make install。在Linux环境下，需要配置编译环境，确保安装了cmake、make、automake等工具，并对编译过程进行深入分析。

       第二步：将三方库加入OpenHarmony的编译构建体系。定义子系统，将三方库放置在OpenHarmony源码的third_party目录下，并在ohos.build文件中配置子系统，将其添加到build/subsystem_config.json中。定义组件和目标模块，确保在gn文件中正确引用组件名，并将目标模块加入相应的组件。同时，产品引用中添加子系统及其组件，例如在vendor/hihope/rk/config.json中定义。

       第三步：增量编译动态链接库与可执行文件。在OpenHarmony源码中执行./build.sh命令，指定产品名称、ccache选项、目标编译库名称及目标CPU架构（如arm，适用于OHOS 3.2及以上版本）。根据编译结果调整gn文件，消除编译警告，并生成动态链接库与测试用的可执行文件，存放于out目录下。

       第四步：验证移植功能与API接口导出。将编译出的动态链接库与可执行文件部署到开发板上，并使用hdc_std工具验证三方库功能正常。对于API接口导出，需要在PC端生成包含所有对外导出头文件的allHeads.h文件、动态库放置在allDySos目录下、测试用的可执行文件存放于allTests目录中，并执行自动化测试脚本export_interface.sh以导出接口。

       总结：完成三方库移植需搭建OpenHarmony南向开发环境，具备开发板与hdc_std工具的使用能力。移植时需注意库与平台的兼容性，确保不涉及对os_api、opensl、opengl依赖，不涉及硬件与驱动。遵循以上四步，三方库移植过程得以顺利实现。

OpenAtom OpenHarmony三方库创建发布及安全隐私检测

       OpenAtom OpenHarmony 三方库（简称“三方库”或“包”），是经过验证可在 OpenHarmony 系统上重复使用的软件组件，助力开发者快速开发 OpenHarmony 应用。三方库分为两类：一类是使用 JavaScript 和 TypeScript 的三方库，通过源码或 OpenHarmony HAR/HSP 引入；另一类是 C 和 C++ 语言的三方库，通过 N-API 暴露 JS 接口或编译在操作系统中使用。

       鼓励开发者通过 OpenHarmony 三方库中心仓分享三方库，促进开源资源的利用和应用生态的繁荣。本文将介绍三方库的创建、发布与安全隐私检测。

       三方库创建与发布

       创建三方库

       创建 OpenHarmony 三方库，支持 IDE 和 OHPM 命令行两种方式。通过 IDE 创建，选择“Static Library”模板，完善 oh-package.json5 的信息。命令行创建需参照三方中心仓指导文档操作。

       编译与打包

       完成后，通过 DevEco Studio 编译构建，生成 HAR/HSP，用于其他模块引用或上传至 OHPM 平台。配置 .ohpmignore 文件可忽略打包文件。

       发布三方库

       发布前确保删除敏感信息。配置 OHPM 公钥，完成发布，发布成功后，平台将通知审核进度。

       三方库安全隐私检测

       安全是核心原则，三方库通过自动化工具扫描和人工审核检测。工具扫描包含完整性与安全性检查，识别恶意行为。人工复审测试功能实现，确保三方库无漏洞和功能问题。

       工具扫描

       包括完整性与安全性检查，识别风险类型，如安全漏洞、权限滥用、网络连接、数据跨境、内容合规、个人数据搜集等，确保三方库安全。

       人工复审

       测试三方库功能，确保其在 OpenHarmony 上验证有效。未实现功能或无法验证的三方库将被退回。

       为了帮助开发者学习鸿蒙 (Harmony OS) 开发技术，提供了《鸿蒙 (Harmony OS)开发学习手册》资源，内容覆盖入门、概念、快速入门、基础知识、ArkTS 开发等，希望对学习有所帮助。

OpenHarmony 3GPP协议开发深度剖析——一文读懂RIL

       市场上针对终端操作系统3GPP协议开发的相关资料较为稀缺，即便在Android领域，相关学习文档也较为有限，更不用说专门的协议开发书籍了。这可能与市场需求有关，目前市场上从事前后端软件开发的人员最多，包括我自己。

       鉴于我在某手机协议开发团队工作过一段时间，对协议的AP侧和CP侧开发都有所涉猎，因此我尝试基于OpenAtom OpenHarmony（以下简称“OpenHarmony”）源码编写一些内容，旨在帮助大家了解协议开发领域，尽可能将3gpp协议内容与OpenHarmony电话子系统模块相结合进行讲解。据我所知，目前终端协议开发人才非常紧缺。首先声明，我不是协议专家，且已离开该领域五六年，如有错误，欢迎指正。

       谈到终端协议开发，我首先想到的就是RIL。

       CP：Communication Processor（通信处理器），通常理解为modem侧，也可以理解为底层协议，这部分由各个modem芯片厂商完成（如海思、高通）。

       AP：Application Processor（应用处理器），通常指手机终端，通常理解为上层协议，主要由操作系统Telephony服务进行处理。

       RIL：Radio Interface Layer（无线电接口层），通常理解为硬件抽象层，即AP侧将通信请求传给CP侧的中间层。

       AT指令：AT指令是应用于终端设备与PC应用之间连接与通信的指令。

       常规的Modem开发与调试可以使用AT指令进行操作，而各家的Modem芯片的AT指令都会有各自的差异。因此，手机终端厂商为了能在各种不同型号的产品中集成不同modem芯片，需要进行解耦设计来屏蔽各家AT指令的差异。

       于是，OpenHarmony采用RIL对Modem进行HAL（硬件抽象），作为系统与Modem之间的通信桥梁，为AP侧提供控制Modem的接口，各Modem厂商则负责提供对应于AT命令的Vender RIL（这些一般为封装好的so库），从而实现操作系统与Modem间的解耦。

       框架层：Telephony Service，电话子系统核心服务模块，主要功能是初始化RIL管理、SIM卡和搜网模块。对应OpenHarmony的源码仓库OpenHarmony/telephony_core_service。这个模块也是非常重要的一个模块，后期单独再做详细解读。

       硬件抽象层：即我们要讲的RIL，对应OpenHarmony的源码仓库OpenHarmony/telephony_ril_adapter。RIL Adapter模块主要包括厂商库加载，业务接口实现以及事件调度管理。主要用于屏蔽不同modem厂商硬件差异，为上层提供统一的接口，通过注册HDF服务与上层接口通讯。

       芯片层：Modem芯片相关代码，即CP侧，这些代码各个Modem厂商是不开放的，不出现在OpenHarmony中。

       硬件抽象层又被划分为hril_hdf层、hril层和venderlib层。

       hril_hdf层：HDF服务，基于OpenHarmony HDF框架，提供hril层与Telephony Service层进行通讯。

       hril层：hril层的各个业务模块接口实现，比如通话、短彩信、数据业务等。

       vendorlib层：各Modem厂商提供的对应于AT命令库，各个厂商可以出于代码闭源政策，在这里以so库形式提供。目前源码仓中已经提供了一套提供代码的AT命令操作，至于这个是针对哪个型号modem芯片的，我后续了解清楚再补充。

       下面是ril_adapter仓的源码结构：

       本文解读RIL层很小一部分代码，RIL是如何通过HDF与Telephony连接上的，以后更加完整的逻辑梳理会配上时序图讲解，会更加清晰。首先，我们要对OpenHarmony的HDF（Hardware Driver Foundation）驱动框架做一定了解，最好是动手写一个Demo案例，具体的可以单独去官网查阅HDF资料。

       首先，找到hril_hdf.c文件的代码，它承担的是驱动业务部分，源码中是不带中文注释的，为了梳理清楚流程，我给源码关键部分加上了中文注释。

       上述代码中配置了对应该驱动的moduleName为"hril_hdf"，因此我们需要去找到对应驱动的配置文件，以HiDV开发板为例，它的驱动配置在vendor_hisilicon/HiDV/hdf_config/uhdf/device_info.hcs代码中可以找到，如下：

       这里可以发现该驱动对应的服务名称为cellular_radio1，那么telephony_core_service通过HDF与RIL进行通信肯定会调用到该服务名称，因此无查找telephony_core_service的相关代码，可以很快定位到telephony_core_service/services/tel_ril/src/tel_ril_manager.cpp该代码，该代码中有一个关键类TelRilManager，它用来负责管理tel_ril。

       看tel_ril_manager.cpp中的一个关键函数ConnectRilAdapterService，它就是用来通过HDF框架获取RIL_ADAPTER的服务，之前定义过RIL_ADAPTER_SERVICE_NAME常量为"cellular_radio1"，它就是在vendor_hisilicon/XXXX/hdf_config/uhdf/device_info.hcs中配置的hril_hdf驱动对应的服务名称。