1.高通提前公布骁龙865/765源码，高通高通三方ROM刷机包能更快搞起来吗？
2.高通提前公布骁龙865/765源码：三方ROM刷机包进展如何？
3.OpenHarmony 3GPP协议开发深度剖析——一文读懂RIL

高通提前公布骁龙865/765源码，开放开放三方ROM刷机包能更快搞起来吗？

结论：高通已公布骁龙/的源码源码部分源码，为三方ROM刷机包的设置开发铺平了道路。

       在去年底的高通高通骁龙峰会上，高通重磅推出骁龙和骁龙移动平台，开放开放学分管理 源码随后市场迅速涌现了多款基于这两款芯片的源码源码手机新品。四个月后，设置高通打破常规，高通高通开始在Code Aurora论坛上分享部分骁龙和平台的开放开放核心源码开发资料。

       这些源码的源码源码开放并非新鲜事，它们包含了高通对Linux内核和AOSP框架的设置定制改动，旨在优化对骁龙/芯片的高通高通支持。在过去，开放开放像小米、源码源码三星S等厂商在进行软硬件调试和优化时，都曾依赖高通提供的涨停浪涌指标源码BSP（板级支持包）。

       此次源码的公开，无疑为基于骁龙/的第三方固件，如LieageOS、CM、魔趣等提供了更强的技术支持，加速了这些第三方ROM的开发进程。值得注意的是，与去年高通在5月公开骁龙源码相比，今年的发布时间提前了一个月，显示出高通对开发者社区的积极响应和对开源精神的持续投入。

高通提前公布骁龙/源码：三方ROM刷机包进展如何？

结论：高通已经发布了骁龙（kona）和骁龙（lito）移动平台的部分源码，为第三方ROM开发者打开了新大门。

       在去年底的骁龙峰会上，两大芯片的亮相后，已有众多手机厂商基于这些平台推出了新品。四个月后，仿新版小刀源码高通打破常规，将骁龙和的部分源码开发资料上传至Code Aurora论坛（CAF），关注的核心在于对Linux内核和AOSP框架的定制修改，旨在支持这些尖端芯片的运行。

       以往，高通会将修改后的Linux内核、AOSP代码和软件工具以BSP形式提供给OEM和ODM厂商，如小米和三星S，让他们借此进行软硬件的调试和优化。现在，随着这批新源码的公布，第三方ROM的开发者，如LieageOS、CM和魔趣等，将迎来加速发展的契机。

       对比去年，流金线指标源码高通在骁龙源码的公开时间上，今年提前了一个月，显示出公司对于开放源码支持的重视，预示着更多个性化和定制化操作系统的可能性正在逐渐扩大。

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

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

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

       谈到终端协议开发，我首先想到的就是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驱动对应的服务名称。