1.OpenHarmony代码编译及源码跳转配置
2.OpenHarmony 3GPP协议开发深度剖析——一文读懂RIL
3.OpenHarmony系统解决方案 - 配置屏幕方向导致开机动画和Launcher显示异常
4.OpenHarmony Camera源码分析
5.鸿蒙轻内核M核源码分析：中断Hwi
6.OpenHarmony 代码学习4：Ability子系统 源码解析（更新太快，跟不上步伐了）

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将开始索引，索引完成后即可享受代码跳转功能。

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驱动对应的服务名称。

OpenHarmony系统解决方案 - 配置屏幕方向导致开机动画和Launcher显示异常

       系统版本：OpenHarmony-3.2-Release

       遇到的问题是配置屏幕方向导致开机动画和Launcher显示异常。

       问题现象出现在源码文件foundation/window/window_manager/resources/config/rk/display_manager_config.xml和系统文件/etc/window/resources/display_manager_config.xml中。

       异常效果是：正常效果下，系统运行平稳，无异常表现。

       问题的原因在于ScreenRotationController初始化时序的不当，使ScreenRotationController在Launcher加载Window时未触发。

       解决办法是调整ScreenRotationController的初始化时序，确保在Launcher加载Window时触发。通过修改源码文件foundation/window/window_manager/wmserver/src/window_node_container.cpp，对WindowNodeContainer::RemoveWindowNode和WindowNodeContainer::AddWindowNode函数进行代码修改。

       在定位问题的过程中，我们了解到若应用方向需要随系统切换，可在module.json5的ability中配置orientation为auto_rotation_restricted。

       为帮助大家更好地学习鸿蒙 (OpenHarmony) 开发技术，特别整理了《鸿蒙 (OpenHarmony)开发学习手册》（共计页），旨在提供深入学习资源。

       以下为手册的入门指南：

       《鸿蒙 (OpenHarmony)开发学习手册》入门必看：qr.cn/FV7h

       HarmonyOS 概念：qr.cn/FV7h

       如何快速入门？：qr.cn/FV7h

       开发基础知识：qr.cn/FV7h

       基于ArkTS 开发：qr.cn/FV7h

       手册覆盖了以下鸿蒙 (OpenHarmony) 开发领域：

       Ability开发

       UI开发

       公共事件与通知

       窗口管理

       媒体

       安全

       网络与链接

       电话服务

       数据管理

       后台任务(Background Task)管理

       设备管理

       设备使用信息统计

       DFX

       国际化开发

       折叠屏系列

       ……

OpenHarmony Camera源码分析

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

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

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

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

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

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

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

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

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

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

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

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

鸿蒙轻内核M核源码分析：中断Hwi

       在鸿蒙轻内核源码分析系列中，本文将深入探讨中断模块，旨在帮助读者理解中断相关概念、鸿蒙轻内核中断模块的源代码实现。本文所涉及源码基于OpenHarmony LiteOS-M内核，读者可通过开源站点 gitee.com/openharmony/k... 获取。

       中断概念介绍

       中断机制允许CPU在特定事件发生时暂停当前执行的任务，转而处理该事件。这些事件通常由外部设备触发，通过中断信号通知CPU。中断涉及硬件设备、中断控制器和CPU三部分：设备产生中断信号；中断控制器接收信号并发出中断请求给CPU；CPU响应中断，执行中断处理程序。

       中断相关的硬件介绍

       硬件层面，中断源分为设备、中断控制器和CPU。设备产生中断信号；中断控制器接收并转发这些信号至CPU；CPU在接收到中断请求后，暂停当前任务，转而执行中断处理程序。

       中断相关的概念

       每个中断信号都附带中断号，用于识别中断源。中断优先级根据事件的重要性和紧迫性进行划分。当设备触发中断后，CPU中断当前任务，执行中断处理程序。中断处理程序由设备特定，且通常以中断向量表中的地址作为入口点。中断向量表按中断号排序，存储中断处理程序的地址。

       鸿蒙轻内核中断源代码

       中断相关的声明和定义

       在文件 kernel\arch\arm\cortex-m7\gcc\los_interrupt.c 中定义了结构体、全局变量和内联函数。关键变量 g_intCount 记录当前正在处理的中断数量，内联函数 HalIsIntActive() 用于检查是否正在处理中断。中断向量表在中断初始化过程中设置，用于映射中断号到相应的中断处理程序。

       中断初始化 HalHwiInit()

       系统启动时，在 kernel\src\los_init.c 中初始化中断。HalHwiInit() 函数在 kernel\arch\arm\cortex-m7\gcc\los_interrupt.c 中实现，负责设置中断向量表和优先级组，配置中断源，如系统中断和定时器中断。

       创建中断 HalHwiCreate()

       开发者可通过 HalHwiCreate() 函数注册中断处理程序，传入中断号、优先级和中断模式。函数内部验证参数，设置中断处理程序，最终通过调用 CMSIS 函数完成中断创建。

       删除中断 HalHwiDelete()

       中断删除操作通过 HalHwiDelete() 实现，接收中断号作为参数，调用 CMSIS 函数失能中断，设置默认中断处理程序，完成中断删除。

       中断处理执行入口程序

       默认的中断处理程序 HalHwiDefaultHandler() 仅用于打印中断号后进行死循环。HalInterrupt() 是中断处理执行入口程序的核心，它包含中断数量计数、中断号获取、中断前后的操作以及调用中断处理程序的逻辑。

       开关中断

       开关中断用于控制CPU是否响应外部中断。通过宏 LOS_IntLock() 关闭中断， LOS_IntRestore() 恢复中断状态， LOS_IntUnLock() 使能中断。这组宏对应汇编函数，使用寄存器 PRIMASK 控制中断状态。

       小结

       本文详细解析了鸿蒙轻内核中断模块的源代码，涵盖了中断概念、初始化、创建、删除以及开关操作。后续文章将带来更多深入技术分享。欢迎在 gitee.com/openharmony/k... 分享学习心得、提出问题或建议。关注、点赞、Star 和 Fork 到个人账户，便于获取更多资源。

OpenHarmony 代码学习4：Ability子系统 源码解析（更新太快，跟不上步伐了）

       深入探讨OpenHarmony代码学习中关于Ability子系统的源码解析，重点关注基于monthly_的代码架构与配置。

       在源码解析中，SystemAbility的配置sa_profile至关重要，它确保了以c++实现的SA在加载注册逻辑时能够完成SA的注册，反之，未配置profile的System Ability将不会完成注册。可见abilitymgr等系统服务SA以特定方式运行，如.xml所示，ams的libabilityms.z.so在foundation进程中启动，并在启动后即向samgr组件注册SystemAbility，实现本地跨IPC访问。

       进一步，分析AbilityManagerService作为SystemAbility的管理器，提供管理Ability生命周期的管理能力。以AbilityManagerService::StartAbility为起点，此方法支持4种Startability，其中IRemoteObject属于分布式软总线子系统的ipc组件，负责进程间通信。理解IPC与RPC机制，IPC与RPC在实现跨进程通信中扮演重要角色，IPC使用Binder驱动，适合设备内跨进程通信，而RPC采用软总线驱动，适用于跨设备跨进程通信。客户端与服务器通过客户端-服务器模型进行通信，通过代理获取服务提供方的接口进行数据交互。三方应用通过FA提供的接口绑定服务提供方的Ability，获取代理，实现通信。

       在StartAbility中，callerToken由AbilityRuntime::AbilityContextImpl::StartAbility传入的AbilityContextImpl成员变量token_决定，通常指要启动的Ability。此调用链将在后续应用启动流程中总结，具体路径可参考官网介绍。

       继续深入代码分析，观察StartAbility中的调用链，最终向BMS调用StartAbilityInner方法。根据ability类型的不同，启动方式也不同，已在代码段中进行了标注。在OpenHarmony代码学习中，PageAbility作为具备ArkUI实现的Ability，是最具直观性的用户可见并可交互的实例，通常由missionListManager启动。

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

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

       在2.0版本中，大部分组件已采用GN和Ninja，未来将全面替代。构建流程包括设置和编译两个步骤，通过命令行工具如"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—内核对象事件之源码详解

       对于嵌入式开发和技术爱好者，深入理解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进行任务同步，并根据需要自定义事件通知机制，提升任务间通信的灵活性。