OpenHarmony电话子系统架构与业务梳理

文档概述
说明：

1.文章由移远通信技术股份有限公司提供
2.以下内容包含了个人理解，仅供参考，如有不合理处，请联系笔者修改(181-0715-8288)

1. 汇报目标

本文基于 base/telephony 当前仓代码，对 OpenHarmony 电话子系统做一份梳理。目标不是罗列所有接口，而是用一条清晰主线回答下面 4 个问题：

1. 电话子系统到底由哪些模块组成。
2. 模块之间如何协作，谁是底座，谁是业务层。
3. 系统启动后，这些服务是怎样被拉起的。
4. 通话、短信、蜂窝数据、状态分发出现问题时，应该优先看哪里。
   

   

2. 梳理结论

如果只用几句话概括电话子系统，可以这样讲：

• 电话子系统位于应用框架和 modem 之间，向上提供电话 API，向下对接 RIL、HDF 和厂商 modem。
• 整体架构上，core_service 负责打底，ril_adapter 负责触底，call_manager / cellular_call / cellular_data / sms_mms 负责核心业务，state_registry 负责状态分发，telephony_data 负责持久化数据出口。
• 运行形态上，电话能力不是单一进程完成，而是拆分在 telephony 和 foundation 两个进程中协同完成。
• 启动顺序上，core_service 是事实上的先行初始化模块，很多服务都建立在它的卡、网、RIL 上下文之上。
• 排查问题时，最有效的方法不是从 API 往下“盲找”，而是按业务链路拆段定位。

3. 子系统定位与边界

3.1 子系统定位

base/telephony 是 OpenHarmony 电话服务子系统的主仓，承接移动通信相关的基础能力，主要包括：

• SIM 卡与搜网能力
• 蜂窝通话能力
• 蜂窝数据能力
• 短信/彩信能力
• 电话状态订阅与分发
• 电话相关持久化数据访问
• 与 modem/RIL 的统一适配

它位于应用框架和底层通信硬件之间：

• 向上为 JS/NAPI/Native 接口提供服务
• 向下通过 RIL/HDF/厂商适配对接 modem

3.2 外部依赖

电话子系统不是一个独立孤岛，它依赖多个系统能力协同工作：

• HDF / drivers_interface / drivers_peripheral
  • 提供底层驱动框架和硬件接入能力。
• ril_adapter
  • 屏蔽不同 modem 厂商差异，为上层输出统一的 RIL 接口。
• 安全子系统
  • 负责权限校验，例如 GET_TELEPHONY_STATE、SET_TELEPHONY_STATE、PLACE_CALL、SEND_MESSAGES。
• 多媒体子系统
  • 通话音频、视频资源申请与切换依赖音频/多媒体能力。
• 公共事件框架
  • 用于状态广播与事件协同。
• NetManager / DataShare
  • 分别承接蜂窝数据网络管理、电话相关持久化数据访问。
• IMS / 卫星 / 分布式硬件能力
  • 支撑 VoLTE/VoNR/VoWiFi、卫星通话以及分布式通话扩展。

4. 架构总览

4.1 五层视角

从汇报角度看，电话子系统可以抽象成 5 层：

应用 / 系统应用
    |
JS / NAPI / Native Telephony APIs
    |
电话业务服务层
    |- call_manager
    |- cellular_call
    |- cellular_data
    |- sms_mms
    |- state_registry
    |- telephony_data
    |
电话核心底座
    |- core_service
    |
设备接入层
    |- ril_adapter
    |- HDF / driver_peripheral
    |
modem / SIM / 网络

一句话理解：

• core_service 是电话底座
• ril_adapter 是底层适配桥梁
• 其余模块是围绕通话、数据、短信、状态和持久化展开的业务能力层

4.2 Mermaid 架构图

下面这张图更适合在汇报里展示“模块怎么连起来”：

graph TD
    A[应用 / 系统应用] --> B[JS / NAPI / Native Telephony APIs]

    B --> CM[call_manager<br/>通话总控]
    B --> CD[cellular_data<br/>蜂窝数据]
    B --> SM[sms_mms<br/>短彩信]
    B --> CS[core_service 接口<br/>SIM / 搜网]
    B --> SR[state_registry<br/>状态订阅]
    B --> TD[telephony_data<br/>DataShare]

    CM --> CC[cellular_call<br/>蜂窝通话]
    CM --> SR
    CM --> AU[音频 / 蓝牙 / 分布式能力]

    CC --> CS
    CD --> CS
    SM --> CS

    CS --> RA[ril_adapter]
    RA --> HDF[HDF / driver_peripheral]
    HDF --> MD[modem / SIM / 网络]

    CC --> IMS[IMS / 卫星服务]
    SM --> IMS
    CS --> IMS

    CD --> NM[NetManager]
    SM --> DB[短信持久化 / DataShare]
    TD --> DB

    CS --> SR
    CC --> SR
    CD --> SR
    SM --> SR

图里的主线可以概括为：

• core_service 负责打底
• ril_adapter 负责触底
• call_manager / cellular_call / cellular_data / sms_mms 负责业务实现
• state_registry 负责统一向上分发状态
• telephony_data 负责持久化数据出口

5. 核心模块地图

这一部分适合讲“每个模块存在的价值是什么”，而不是讲实现细节。

5.1 core_service

core_service 是电话子系统的底座，主要负责：

• 初始化 TelRilManager
• 初始化 SimManager
• 初始化 NetworkSearchManager
• 建立与 IMS Core 的连接
• 对外提供 SIM 与搜网相关能力

可重点关注：

• core_service/services/core/src/core_service.cpp
• core_service/services/sim
• core_service/services/network_search
• core_service/services/tel_ril

5.2 call_manager

call_manager 是通话总控，主要负责：

• 拨号、接听、拒接、挂断
• 多路通话冲突处理
• 音频、蓝牙、有线耳机状态联动
• 通话记录与状态上报
• 分布式通话与设备协同

它更像“通话编排层”，不直接实现具体蜂窝信令，而是通过连接层与 cellular_call 协作。

5.3 cellular_call

cellular_call 是蜂窝通话实现层，主要覆盖：

• CS 通话
• IMS 通话
• VoLTE / VoWiFi / VoNR
• 视频通话与会议
• 紧急呼叫
• 补充业务与配置业务
• 域选与切换

可以把它理解成“把电话真正打出去、接进来、维持住”的模块。

5.4 cellular_data

cellular_data 负责蜂窝数据能力，核心包括：

• 数据开关控制
• APN 管理
• 数据连接状态机
• 漫游控制
• 数据异常检测与恢复
• 网络管理联动

它内部是 Controller + Handler + StateMachine + APN 的组合模型。

5.5 sms_mms

sms_mms 提供短信和彩信能力，主要包括：

• GSM/CDMA 短信发送与接收
• 短信 PDU 编解码
• Wap Push、小区广播
• 彩信编码、发送、接收
• SIM 卡短信记录读写
• IMS 短信

它既有实时发送链路，也有较重的本地持久化逻辑。

5.6 state_registry

state_registry 是电话状态订阅中心，主要负责：

• 记录订阅关系
• 缓存当前状态
• 在状态变化时回调观察者
• 必要时发布公共事件广播

它本身不产生业务数据，但几乎所有“状态上报不对”的问题最后都可能落到这里。

5.7 telephony_data

telephony_data 是电话持久化数据出口，主要通过 DataShare 提供：

• OpKey 数据
• PDP Profile 数据
• SIM 数据
• 短彩信数据
• GlobalParams 数据

更适合把它理解为电话子系统的数据面支撑模块。

5.8 ril_adapter

ril_adapter 位于电话核心与底层 modem 之间，主要负责：

• 装载厂商库
• 抽象统一的 HRIL 接口
• 事件分发与回调调度
• 屏蔽不同 modem 的实现差异

几乎所有 SIM、搜网、短信、蜂窝数据、蜂窝通话能力，最终都会经过它落到底层。

6. 进程与 SA 布局

6.1 为什么要先看 SA

汇报电话子系统时，只讲模块还不够，因为它并不是单体程序，而是依赖多个 SystemAbility 协同运行。理解 SA、进程和依赖关系，等于理解它“实际上怎么跑起来”。

6.2 SA 总览

SA ID	模块	进程	动态库	说明
4005	call_manager	foundation	libtel_call_manager.z.so	通话总控服务
4006	cellular_call	telephony	libtel_cellular_call.z.so	蜂窝通话服务
4007	cellular_data	telephony	libtel_cellular_data.z.so	蜂窝数据服务
4008	sms_mms	telephony	libtel_sms_mms.z.so	短彩信服务
4009	state_registry	foundation	libtel_state_registry.z.so	电话状态注册与分发
4010	core_service	telephony	libtel_core_service.z.so	电话核心底座

6.3 进程拆分的意义

电话子系统并不是全部跑在同一个进程里：

• core_service、cellular_call、cellular_data、sms_mms 运行在 telephony 进程
• call_manager、state_registry 运行在 foundation 进程

这种拆分背后的逻辑是：

• telephony 进程更靠近电话底座与蜂窝业务实现
• foundation 进程更靠近系统公共服务、通话编排与状态分发

这样做的收益主要有：

• 将底层蜂窝能力与高层通话编排做进程级隔离
• 让通话管理和状态广播更容易与系统公共框架集成
• 降低单进程过重导致的耦合度

6.4 依赖关系

在 SA 配置中，4006、4007、4008 都依赖 4010：

• cellular_call -> core_service
• cellular_data -> core_service
• sms_mms -> core_service

这说明 core_service 是电话子系统中事实上的“先行初始化模块”。

6.5 SA、进程、依赖与入口类对照表

下面这张表适合在汇报时用来快速建立“模块名和运行实体”的映射关系：

SA ID	模块	进程	动态库	显式依赖	入口类	注册方式	运行角色
4005	call_manager	foundation	libtel_call_manager.z.so	无	CallManagerService	DelayedSingleton	通话总控与资源编排
4006	cellular_call	telephony	libtel_cellular_call.z.so	4010	CellularCallService	DelayedSingleton	蜂窝通话控制与连接管理
4007	cellular_data	telephony	libtel_cellular_data.z.so	4010	CellularDataService	DelayedRefSingleton	蜂窝数据开关、APN、状态机
4008	sms_mms	telephony	libtel_sms_mms.z.so	4010	SmsService	DelayedSingleton	短信/彩信与 IMS 短信
4009	state_registry	foundation	libtel_state_registry.z.so	无	TelephonyStateRegistryService	DelayedSingleton	电话状态订阅与事件分发
4010	core_service	telephony	libtel_core_service.z.so	无	CoreService	DelayedSingleton	RIL、SIM、搜网底座

补充说明：

• 4006、4007、4008 在 SA profile 中都声明了对 4010 的依赖，因此真正业务初始化建立在 core_service 就绪之后。
• 4005 与 4009 虽然运行在 foundation 进程，但业务上仍然与 telephony 进程内的服务强关联。
• 4007 使用的是 DelayedRefSingleton，其余几个核心服务使用的是 DelayedSingleton。

7. 启动方式与初始化链路

7.1 启动入口

电话子系统的系统启动入口来自：

• core_service/services/etc/init/telephony.cfg

该配置做了两件关键事情：

1. 在 early-boot 阶段创建电话相关目录。
2. 执行 start telephony，拉起电话服务进程。

telephony 服务的执行路径是：

/system/bin/sa_main /system/profile/telephony.json

也就是说，电话子系统是由 sa_main 根据系统 profile 装载对应 SA，再完成后续模块启动。

7.2 启动主线

从代码和 SA 配置可以把启动链路简化为：

early-boot
  -> init 解析 telephony.cfg
  -> start telephony
  -> sa_main 读取 telephony profile
  -> 加载 core_service(4010)
  -> core_service 初始化 RIL / SIM / 搜网 / IMS
  -> 加载 cellular_call(4006)
  -> 加载 cellular_data(4007)
  -> 加载 sms_mms(4008)
  -> foundation 侧加载 call_manager(4005)
  -> foundation 侧加载 state_registry(4009)

7.3 各服务初始化重点

core_service

CoreService::Init() 的关键动作：

• 创建 TelRilManager 并执行 OnInit()
• 创建 SimManager
• 初始化 IMS Core Client
• 创建并初始化 NetworkSearchManager
• 将对象注册到 CoreManagerInner

一句话：先把“卡、网、RIL”三件套搭起来。

cellular_call

CellularCallService::Init() 的关键动作：

• 创建 handler
• 注册事件处理器
• 订阅 call_manager SA 状态变化
• 初始化 ImsCallClient
• 等待 CoreManagerInner 初始化完成后向核心注册回调

一句话：既依赖底层核心能力，也要和上层通话总控联动。

cellular_data

CellularDataService::Init() 的关键动作：

• 初始化模块内部 controller/handler
• 发布 CellularDataService
• 为每个卡槽执行 AsynchronousRegister()

一句话：服务先拉起，再按卡槽异步接入数据能力。

sms_mms

SmsService::Init() 的关键动作：

• 初始化 ImsSmsClient
• 发布 SmsService
• 等待 CoreService 初始化完成
• 再执行 InitModule()
• 初始化 SmsStateHandler

一句话：可先发布，但真正模块初始化要等 core_service 就绪。

call_manager

CallManagerService::Init() 的关键动作：

• 初始化 CallControlManager
• 初始化通话信息上报处理器
• 初始化 CellularCallConnection
• 初始化通话记录管理
• 初始化蓝牙、分布式通话与设备协同
• 监听音频策略服务和分布式硬件服务

一句话：它是把通话、音频、蓝牙、分布式能力串起来的中枢。

state_registry

TelephonyStateRegistryService::OnStart() 的关键动作：

• 发布状态注册服务
• 初始化扩展能力
• 启动后台线程，为各卡槽发送一次默认的断开通话状态

一句话：尽快让订阅者能看到一份“初始可感知状态”。

7.4 启动时序图

如果希望从“谁先启动、谁依赖谁”的角度理解电话子系统，可以参考下面这张时序图：

sequenceDiagram
    participant INIT as init / early-boot
    participant SA as sa_main
    participant CORE as core_service(4010)
    participant CC as cellular_call(4006)
    participant CD as cellular_data(4007)
    participant SMS as sms_mms(4008)
    participant CM as call_manager(4005)
    participant SR as state_registry(4009)
    participant RIL as ril_adapter / modem

    INIT->>SA: 解析 telephony.cfg 并执行 start telephony
    SA->>CORE: 装载并启动 4010
    CORE->>RIL: 初始化 TelRilManager
    CORE->>CORE: 初始化 SimManager / NetworkSearchManager / IMS Core
    CORE-->>SA: 底座能力就绪

    SA->>CC: 按依赖关系启动 4006
    CC->>CORE: 等待 CoreManagerInner 初始化完成
    CC->>CC: 注册 handler / 事件 / IMS Call Client

    SA->>CD: 按依赖关系启动 4007
    CD->>CORE: 依赖 core_service 提供卡网上下文
    CD->>CD: 初始化 Controller / Handler / StateMachine

    SA->>SMS: 按依赖关系启动 4008
    SMS->>CORE: 等待 core_service 初始化完成
    SMS->>SMS: 初始化 ImsSmsClient / SmsStateHandler / InitModule

    SA->>CM: foundation 侧装载 4005
    CM->>CC: 初始化 CellularCallConnection
    CM->>CM: 初始化通话控制、音频、蓝牙、分布式能力

    SA->>SR: foundation 侧装载 4009
    SR->>SR: 发布状态服务并初始化默认状态

这张图强调的是“依赖顺序”，不是严格时间点；实际执行中部分初始化会异步继续完成。

8. 主要业务能力

8.1 SIM 与搜网能力

由 core_service 承担，主要包括：

• SIM 在位、状态、类型、运营商、号码、语音信箱
• 主卡/默认语音卡管理
• 卡锁、PIN/PUK、STK、eSIM 等能力
• 网络状态、信号、小区、驻网信息
• 选网模式、优选网络模式、Radio 开关
• IMS 注册状态

这是其他电话业务的基础上下文来源。

8.2 通话能力

从业务拆分上看，通话能力由 call_manager + cellular_call 共同完成：

• call_manager
  • 面向上层暴露拨号、接听、挂断等能力
  • 处理多路通话冲突、音频与设备资源协调
  • 对接蓝牙、通话记录、UI、分布式通话
• cellular_call
  • 负责 CS/IMS/卫星等蜂窝通话控制逻辑
  • 处理呼叫事件、补充业务和连接管理

一句话理解：

• call_manager 负责“怎么管理一通电话”
• cellular_call 负责“怎么把电话真正打出去和接进来”

8.3 蜂窝数据能力

由 cellular_data 承担，主要包括：

• 蜂窝数据开关
• 数据连接状态
• APN 管理
• 数据漫游
• 数据恢复与异常处理
• 多 APN / 不同业务类型的数据上下文管理

它与网络管理能力和底层数据状态机耦合较深。

8.4 短信 / 彩信能力

由 sms_mms 承担，主要包括：

• 文本短信发送与接收
• 状态报告、送达报告
• PDU 编解码
• Wap Push、小区广播
• 彩信编码、发送、接收
• SIM 卡短信记录管理
• IMS 短信

它既有实时通道，也有较重的持久化逻辑，因此与 telephony_data 的协同较多。

8.5 状态订阅能力

由 state_registry 提供统一入口，向应用或系统组件提供：

• on
• off

两类订阅接口，再根据 type 细分各种电话事件。对上层而言，它相当于电话子系统的事件总线。

8.6 数据持久化能力

由 telephony_data 提供 DataShare 能力，承接：

• 短信 / 彩信记录
• PDP Profile
• SIM 相关持久化数据
• OpKey / GlobalParams

它是电话子系统“控制面”之外的重要数据支撑。

9. 典型业务链路

这一部分适合在汇报时把“架构图”落到“实际调用流”。

9.1 拨号主链路

应用 / UI
  -> telephony call JS/NAPI API
  -> call_manager
  -> CellularCallConnection
  -> cellular_call
  -> core_service / RIL
  -> ril_adapter / modem
  -> 网络侧建立呼叫
  -> cellular_call 回传呼叫状态
  -> call_manager 处理通话编排、音频/蓝牙/记录
  -> state_registry 向观察者分发通话状态

关键点：

• call_manager 负责通话编排与系统资源协调
• cellular_call 负责蜂窝网络侧呼叫控制

9.2 来电 / 通话状态上报链路

modem / RIL 上报
  -> ril_adapter
  -> core_service / cellular_call handler
  -> call_manager 更新通话控制状态
  -> state_registry 更新 callState
  -> observer / common event / UI 收到回调

如果出现“底层已来电但 UI 没刷新”，一般优先看：

1. cellular_call 是否收到 RIL 事件
2. call_manager 是否完成状态转换
3. state_registry 是否成功分发事件

9.3 蜂窝数据开关链路

应用 / 系统设置
  -> telephony data API
  -> cellular_data service
  -> CellularDataController / Handler
  -> APN / StateMachine / NetManager
  -> core_service / RIL / modem
  -> 返回数据连接状态
  -> state_registry 分发数据连接状态变化

这条链路的关注点一般是：

• 控制层有没有真正下发请求
• APN 是否正确
• 状态机是否进入目标状态
• 断开原因是否被错误标记为 restricted 或 calling only

9.4 短信发送链路

应用
  -> sms API
  -> SmsService
  -> SmsInterfaceManager / SmsSendManager
  -> GSM/CDMA/IMS Sender
  -> core_service / RIL / modem
  -> 发送结果回调
  -> SmsPersistHelper 更新会话与明细

从实现可见，短信发送前后会同时处理两件事：

• 实时发送链路
• 本地会话和消息记录持久化

所以短信类问题不能只看“发没发出去”，还要看“本地记录是否一致”。

9.5 状态订阅链路

应用 / 系统组件
  -> observer.on(...)
  -> state_registry 记录订阅者
  -> 其他电话模块更新状态
  -> state_registry 分发回调 / 广播

state_registry 的价值在于把原本分散在各模块中的状态变化统一收敛成一个出口。

10. 关键时序图

10.1 短信发送时序图

如果希望从“短信发送请求如何进入服务层、如何选择发送通道、如何回写结果”的角度看，可以参考下面这张图：

sequenceDiagram
    participant APP as 应用
    participant API as SMS API
    participant SMS as SmsService
    participant IFM as SmsInterfaceManager
    participant SND as SmsSendManager
    participant CH as GSM / CDMA / IMS Sender
    participant CORE as core_service
    participant RIL as ril_adapter / modem
    participant DB as SmsPersistHelper

    APP->>API: sendMessage(options)
    API->>SMS: 进入短信服务
    SMS->>SMS: 校验权限、校验号码
    SMS->>DB: InsertSessionAndDetail / 查询已有草稿
    SMS->>IFM: TextBasedSmsDelivery(...)
    IFM->>SND: 选择发送管理器
    SND->>CH: 按网络制式选择 GSM / CDMA / IMS 通道
    CH->>CORE: 获取卡槽与网络上下文
    CH->>RIL: 下发短信发送请求
    RIL-->>CH: 返回发送结果 / 状态报告
    CH-->>SND: 回传发送结果
    SND-->>IFM: 回传结果
    IFM-->>SMS: 结束一次发送流程
    SMS->>DB: 更新会话、消息状态、联系人
    SMS-->>APP: sendCallback / deliveryCallback

排查重点：

• SMS API -> SmsService：请求是否成功到达服务层
• SmsService -> SmsInterfaceManager -> SmsSendManager：发送路径是否选对
• Sender -> core_service / ril_adapter / modem：底层发送是否真正发起
• SmsPersistHelper：发送结果是否正确回写到本地会话和消息记录

10.2 典型通话时序图

如果希望从“拨号请求如何落到底层，再如何把状态回传上来”的角度看，可以参考下面这张图：

sequenceDiagram
    participant APP as 应用 / UI
    participant API as Telephony Call API
    participant CM as call_manager
    participant CC as cellular_call
    participant CORE as core_service
    participant RIL as ril_adapter
    participant NET as modem / 网络
    participant SR as state_registry

    APP->>API: dial(phoneNumber, options)
    API->>CM: 发起拨号请求
    CM->>CM: 校验权限、构建通话对象、申请音频等资源
    CM->>CC: 通过 CellularCallConnection 下发呼叫控制
    CC->>CORE: 获取卡槽、网络、IMS 等基础上下文
    CC->>RIL: 下发 CS/IMS 呼叫请求
    RIL->>NET: 与 modem / 网络侧交互建立呼叫
    NET-->>RIL: 返回呼叫建立 / 状态变化事件
    RIL-->>CC: 上报呼叫状态
    CC-->>CM: 回传呼叫状态、补充业务或异常信息
    CM->>CM: 更新通话状态、协调音频/蓝牙/记录
    CM->>SR: 更新 callState
    SR-->>APP: observer / common event / UI 回调

排查重点：

• APP -> API -> call_manager：上层调用是否正确到达通话服务
• call_manager -> cellular_call：通话控制是否成功下发
• cellular_call -> core_service -> ril_adapter -> modem：底层呼叫是否真正发起
• modem -> ril_adapter -> cellular_call -> call_manager -> state_registry：状态是否完整回传

10.3 蜂窝数据开关 / 状态时序图

如果希望从“打开蜂窝数据之后，状态如何逐步推进并回传给观察者”的角度看，可以参考下面这张图：

sequenceDiagram
    participant APP as 设置 / 应用
    participant API as Telephony Data API
    participant CDS as cellular_data service
    participant CTR as CellularDataController
    participant HD as CellularDataHandler
    participant SM as Data StateMachine / APN
    participant CORE as core_service
    participant RIL as ril_adapter / modem
    participant SR as state_registry

    APP->>API: EnableCellularData(true)
    API->>CDS: 请求打开蜂窝数据
    CDS->>CTR: 获取默认卡槽 Controller
    CTR->>HD: SetCellularDataEnable(true)
    HD->>SM: 激活默认 APN / 推进状态机
    SM->>CORE: 获取卡、网、上下文信息
    SM->>RIL: 下发数据激活请求
    RIL-->>SM: 返回连接中 / 已连接 / 失败状态
    SM-->>HD: 更新 APN 与连接状态
    HD-->>CTR: 汇总当前数据状态
    CTR-->>CDS: 返回执行结果
    HD->>SR: UpdateCellularDataConnectState(...)
    SR-->>APP: observer / 数据状态回调

排查重点：

• API -> cellular_data service -> Controller：开关请求有没有成功进入数据服务
• Controller -> Handler -> StateMachine：APN 和状态机是否正确推进
• StateMachine -> core_service -> ril_adapter -> modem：底层数据激活是否成功
• Handler -> state_registry -> observer：状态变化是否被正确通知到上层

如果表现为“开关打开了但状态不变”或“状态变了但界面不刷新”，通常就是卡在后两段中的某一段。

11. 设计特点

11.1 以 core_service 为底座

core_service 不是单纯的一个服务入口，而是电话子系统的底座模块。SIM、搜网、RIL 初始化都从这里起步，其他核心服务大多要等它就绪后再继续初始化。

11.2 业务分层清晰

整体拆分上，大体符合以下思路：

• core_service 负责基础通信能力
• cellular_call 负责蜂窝通话业务实现
• call_manager 负责上层通话编排
• cellular_data 负责数据网络
• sms_mms 负责消息业务
• state_registry 负责状态总线
• telephony_data 负责数据面

这种拆分方式让“能力实现”和“状态暴露/编排”分工比较明确。

11.3 强依赖权限与系统应用身份

从代码可以看到，大量接口不仅校验具体 permission，还要求调用方是 system app。这意味着很多能力默认面向系统应用和系统服务，而不是任意三方应用。

11.4 多卡、多制式、多扩展场景并存

代码里大量以 slotId 为单位管理对象，同时兼容：

• 单卡 / 双卡
• CS / IMS
• VoLTE / VoNR / VoWiFi
• 卫星通话
• 分布式通话
• eSIM / VSim 扩展

因此电话子系统天然不是“单链路模型”，而是多卡、多网络、多通道并存的复杂系统。

12. 问题排查入口

12.1 通话问题

优先排查顺序：

1. call_manager
2. cellular_call
3. core_service
4. ril_adapter
5. state_registry

适用于：

• 拨号失败
• 来电不上报
• 挂断状态不一致
• 蓝牙 / 音频路由异常

12.2 蜂窝数据问题

优先排查顺序：

1. cellular_data/services/src/cellular_data_service.cpp
2. cellular_data/services/src/cellular_data_controller.cpp
3. cellular_data/services/src/cellular_data_handler.cpp
4. cellular_data/services/src/state_machine
5. core_service / ril_adapter

适用于：

• 数据开关无效
• 数据已开但不上网
• 数据状态长时间卡在 connecting
• 通话中数据被挂起

12.3 短信问题

优先排查顺序：

1. sms_mms/services/sms/sms_service.cpp
2. SmsInterfaceManager / SmsSendManager / SmsReceiveManager
3. ImsSmsClient
4. SmsPersistHelper
5. core_service / ril_adapter

适用于：

• 短信发送失败
• 短信收到但未入库
• 送达报告异常
• IMS 短信不通

12.4 状态订阅问题

优先排查顺序：

1. state_registry/services/src/telephony_state_registry_service.cpp
2. 状态源模块是否调用了 update 接口
3. 订阅掩码与 slotId 是否匹配
4. 权限是否满足

适用于：

• observer.on() 无回调
• 只有部分卡槽收到状态
• 广播与观察者回调不一致

13. 关键目录索引

base/telephony
├─ call_manager      # 通话总控
├─ cellular_call     # 蜂窝通话
├─ cellular_data     # 蜂窝数据
├─ core_service      # 电话核心底座
├─ ril_adapter       # RIL 适配
├─ sms_mms           # 短彩信
├─ state_registry    # 电话状态订阅与分发
├─ telephony_data    # 电话持久化数据 / DataShare
└─ docs              # 当前整理文档

后续无论是新增功能、分析故障还是梳理依赖，基本都可以沿着这条主线展开。

14.知识分享

‌Modem（调制解调器）‌，根据谐音俗称“猫”，是一种能实现调制和解调功能的计算机网络硬件，核心作用是完成‌模拟信号与数字信号的相互转换‌，是计算机接入网络的核心中介设备。

核心工作原理
Modem是数字信号和模拟信号的“翻译员”：

‌调制‌：计算机发送数据时，把电脑输出的数字信号转换成电话线/光纤可传输的模拟/光信号；
‌解调‌：计算机接收数据时，把线路传来的模拟/光信号转换成电脑能识别的数字信号。
通过这两个过程，就能实现不同设备间的远程通信。
常见分类
根据应用场景和形态，Modem主要分为以下几类：

14.1 无线Modem（无线猫）

全称无线调制解调器，专为数字信号在无线模拟信道传输设计，支持最新的5G Advanced标准，目前高端产品可支持12Gbps下行速率，还集成了卫星通信技术，常见用于家庭ADSL宽带接入，能让多设备通过无线方式联网。

14.2 宽带无线猫

是整合了路由功能的一体化家庭接入设备，全称宽带无线调制解调器，支持ADSL、光纤等多种接入方式，自带无线功能和WEB配置界面，可以实现多终端同时有线/无线上网，是过去家庭宽带普及阶段非常常见的基础网络设备。

14.3. 内置式调制解调器

属于传统拨号上网时代的产品形态，是一块插入电脑主板扩展槽的扩展卡，无需占用电脑串行端口，价格比外置式更便宜，但安装相对繁琐。随着移动通信技术发展，现在这类Modem已经演进为集成在手机中的通信芯片，比如苹果iPhone 16e搭载的自研Apple C1 5G调制解调器就属于这类形态。

发展历程
1950年代：为美国半自动地面防空警备系统SAGE研制，最早用于军事和航空订票系统；
1958年：AT&T发布全球第一个商业化Modem Bell 103，传输速度仅300bit/s；
1981年：贺氏智能Modem问世，实现电脑自动拨号，大幅降低了使用门槛；
1996年：56kb/s拨号Modem出现，是拨号上网时代的巅峰速率；
2022年：高通发布首款集成5G和AI处理器的调制解调器骁龙X70；
目前：最新的5G Advanced调制解调器（高通X85、联发科M90）已经实现技术突破，计划2025年下半年商用。