Openharmony拨打电话全流程介绍-51CTO.COM

Openharmony拨打电话全流程介绍-51CTO.COM

想了解更多关于开源的内容，请访问：

51CTO 开源基础软件社区

​​https://ost.51cto.com​​

1、背景介绍

3.1版本标准系统增加了通话相关的联系人应用，来电应用等，在系统服务层面电话相关功能也比较完善，相关modem模块目前从代码中看到有美格智能的slm790和紫光展锐的模块，之前介绍过​​鸿蒙电话服务子系统功能划分介绍​​，只是对官方文档的介绍，可以通过这个文档先去了解一下各个功能模块。今天从上到下分析下代码调用流程，以拨打电话为例介绍鸿蒙电话子系统的各个部分。电话服务子系统的在/base/telephony目录下，大概有700多个文件，11万多行代码。

2、应用层js代码介绍

应用层拨打电话的应用是联系人，联系人应用的通话记录，联系人查看，拨号盘和收藏都有对拨电话的调用。

最终调用的是app.js中的call函数，此函数调用的是@ohos.telephony.call中的dial方法。

应用层只是调用电话框架层的api，这个api就是@ohos.telephony.call提供的。

3、拨打电话NAPI实现介绍

应用层调用的是js函数，而电话服务层是c语言实现的，二者之间的桥梁就是通过NAPI实现的，有关NAPI介绍请参照这几篇文章源码解析之JavaScript API框架(NAPI)。简单来说js的函数在c层都有对应的实现，它们之间是一一对应的关系，比如js的dial对应的是c++的DialCall，相关代码如下，这部分代码在通话管理模块。

NapiCallManager::DialCall函数中调用的函数是。

HandleAsyncWork(env, asyncContext, “DialCall”, NativeDialCall, NativeDialCallBack)。

之后跳转到了CallManagerClient中的DialCall，然后是CallManagerProxy::DialCall，如下：

4、如何从CallManagerServiceProxy到CallManagerServiceStub

到CallManagerProxy::DialCall中后代码突然不清晰了，callManagerServicePtr_是什么，它的DialCall在哪里，顺藤摸瓜，它的位置如下：

SystemAbilityManagerClient::GetInstance().GetSystemAbilityManager()和managerPtr->GetSystemAbility(systemAbilityId_)是理解下一步调用位置的关键。

这里涉及到了另外一个知识点，就是进程通信，这里使用了ipc机制，可以查看官方文档的介绍。

在目录foundation/comminucotion下的ipc下有readme文档，贴一张原图：

大体意思是proxy通过samgr也就是SystemAbilityManager，去调用跨进程的Stub中的函数，代码层面可以通过systemAbilityId_和接口类去定位函数调用的对应关系，这里的abilityid是TELEPHONY_CALL_MANAGER_SYS_ABILITY_ID，接口类是ICallManagerService，通过查找定位到了CallManagerServiceProxy和CallManagerServiceStub。

函数调用就是从CallManagerServiceProxy::DialCall过渡到了CallManagerServiceStub::OnDialCall。

5、从CallControlManager::DialCall到 蜂窝通话(cellular_call)模块

CallManagerServiceStub::OnDialCall中调用到了CallControlManager::DialCall，然后又走到了。

CallRequestHandlerService::DialCall()，这里调用了一个发送事件函数，这是一种线程异步处理机智可以看这篇文章，只要有发就有收，我们找到收事件的地方。

对应关系在如下位置，由此找到了函数CallRequestHandler::DialCallEvent。

CallRequestHandler::DialCallEvent中有针对类型的判断：

我们走CallRequestProcess::DialRequest分支，然后走到了CellularCallIpcInterfaceProxy::Dial。

在这里我们又遇到了ipc，同样的方法此时id是TELEPHONY_CELLULAR_CALL_SYS_ABILITY_ID。

找到stub函数位置是CellularCallStub::Dial，此时已经到了蜂窝通话模块目录。

6、从蜂窝通话(cellular_call)到 核心服务(core_service)

CellularCallStub::Dial直接调用的是CSControl::Dial。

在这里又出现了类型判断，判断手机网络制式是gsm还是cdma，了解通信行业的都知道gsm和cdma是2G时代的两种制式标准，一个是欧洲主导的，一个是高通主导的，扯得有点远，继续看代码。

二者最终调用的是CSControl::EncapsulateDialCommon，然后CellularCallConnectionCS::DialRequest。

然后进入到了核心服务模块。

然后是TelRilManager::Dial和TelRilCall::Dial。

7、从核心服务(core_service)到 RIL适配层(RIL Adapter)

TelRilCall::Dial中调用了TelRilBase基类的SendBufferEvent(HREQ_CALL_DIAL, wData)函数代码如下：

cellularRadio_这个成员的初始化实在TelRilManager中。

这又涉及到了另外一个知识点驱动相关看这篇OpenHarmony HDF HDI基础能力分析与使用，对modem的操作在RIL适配层被当做了驱动服务来使用的，SendRequest就是对驱动的异步调用，在驱动中的函数RilAdapterDispatch负责对SendRequest的接收处理。

而这个处理函数是驱动加载时运行起来的。

RilAdapterDispatch中的函数DispatchRequest位于HRilManager中，然后调用DispatchModule。

继续调用HRilManager::Dispatch，进入HRilCall中的ProcessCallRequest，然后根据HREQ_CALL_DIAL在函数指针数组reqMemberFuncMap_找到了处理函数HRilCall::Dial，然后处理逻辑变到了callFuncs_->Dial中。

8、RIL适配层(RIL Adapter)中的处理流程

要知道callFuncs_->Dial的最终位置，就要查找callFuncs_的赋值流程， HRilCall::RegisterCallFuncs上层调用是

HRilManager::RegisterCallFuncs再上层是HRilRegOps。

HRilRegOps在LoadVendor中调用，这又涉及到了modem的加载机制，具体厂商modem处理的部分是通过so加载的方式引入的。

通过打开so文件并建立函数的对应关系，最终调用的at命令的具体实现部分。

so的代码目录在vendor目录下，通过成员为函数指针的结构体建立关联性。

也就是callFuncs_->Dial在so中的处理函数是ReqDial，在这里边组装了具体的at命令 ，拨打电话的命令是ATD，GenerateCommand(cmd, MAX_CMD_LENGTH, “ATD%s%s;”, pDial->address, clir)。

最终通过WriteATCommand函数写入到了at命令的通道，通道就是具体的modem模块与主处理器的硬件连接了。

也就是当前代码中的usb通道。

想了解更多关于开源的内容，请访问：

51CTO 开源基础软件社区

​​https://ost.51cto.com​​。