爆打葡萄汁-CSDN博客

原创 DataNetwork 数据网络 HAL 抽象架构

是 Android 11+ Telephony 框架中数据面 HAL 抽象的核心类。它代表一个已建立的蜂窝数据连接在框架层的逻辑对象，负责管理该连接的网络接口（NetworkAgent）、链路属性（LinkProperties）、能力集（NetworkCapabilities）、QoS 参数以及连接的生命周期。在 Android 13+ 的 5G 多切片（Network Slicing）架构中，一个 SIM 卡可以同时拥有多个。

2026-06-11 23:12:00 159

原创 Telephony 线程模型 — AsyncResult / RegistrantList / HandlerThread

Android Telephony 框架是全异步 + 多线程架构的典范。由于 RIL 层通信本质上是异步的（AT 命令 → Modem → 等待响应），Google 设计了一套贯穿全框架的异步消息传递基础设施（异步结果载体）、（观察者列表）、Registrant（弱引用观察者）。这三个类虽不超过 300 行代码，却是整个 Telephony 框架几十万行代码的"血管系统"——所有 RIL 回调、状态变更通知、跨层消息都通过它们流转。

2026-06-11 23:11:10 259

原创 RILD 原生层架构设计 (Native RIL Daemon)

RILD (Radio Interface Layer Daemon) 是 Android Telephony 框架中承上启下的核心守护进程。它位于 Framework RILJ 层与 Vendor Modem 之间，是 Treble 隔离边界的最底层。——RILJ 将 Java 调用转为 HIDL/AIDL，rild 进一步将 HIDL/AIDL 请求转发给 Vendor RIL 动态库，最终通过 AT 命令或 QMI 协议与 Modem 通信。: rild 使用经典的"动态加载 + 回调注入"模式。

2026-06-08 23:16:06 245

原创多 SIM 协作 (DSDS/DSDA) 架构文档

多 SIM 卡协作是 Android 16 Multi-SIM 子系统（DSDS — Dual SIM Dual Standby，DSDA — Dual SIM Dual Active）的核心。它解决了多个 SIM 卡共存时的数据路线仲裁、Radio 资源分配、订阅设置同步等关键问题。组件职责模式决定哪个 Phone 承载默认数据连接，管理 PS Attach 状态数据路线仲裁者协调多 Phone 间的 Radio Access Family 变更，确保资源分配一致性Radio 资源协调者。

2026-06-07 22:48:28 223

原创功耗管理与唤醒锁 (WakeLock) 架构文档

Telephony 子系统是 Android 设备功耗的。Modem 与 AP 之间的通信存在本质的异步性：AP 发送命令后，Modem 可能需要几毫秒到几十秒才能响应。在此期间，如果 CPU 进入深度休眠，RIL 层将无法接收 Modem 的响应，导致命令超时、重试，甚至 Radio 挂死。因此，Telephony 系统在所有关键路径上使用确保 CPU 不会在等待 Modem 响应期间休眠。Android 16 的 WakeLock 管理体现了的三层设计。

2026-06-07 22:19:49 236

原创 eSIM / LPA (Local Profile Assistant) 架构文档

eSIM (embedded SIM) 是 GSMA 定义的嵌入式 SIM 卡标准 (SGP.22)，允许用户无需物理 SIM 卡即可下载运营商 Profile。Android 16 通过API 层— 面向 App 的公开 API控制器层— 权限控制 + 操作队列连接层— 绑定到系统 LPA App（如 Google Play Services）卡层EuiccPort— APDU 命令透传到 eUICC 芯片。

2026-06-06 23:39:10 132

原创飞行模式与 Radio 开关架构文档

Radio 的开关是 Telephony 框架最基础也是最复杂的操作之一。它不是简单的"发一个命令给 Modem"，而是一个涉及数据连接拆除、通话挂断、IMS 注销、卫星 Modem 协调、多原因仲裁的完整生命周期管理。// TelephonyManager.java — Radio 电源状态常量// Radio 已关机// Radio 不可用（芯片未初始化）// Radio 已开机。

2026-06-06 23:35:30 207

原创 APN / DataProfile 数据配置架构文档

APN (Access Point Name) 是手机建立数据连接的核心配置，告诉 Modem 如何接入运营商的分组数据网络。Android 16 使用三层模型（ApnSetting→→）来管理这些配置，通过统一加载、缓存和分发。

2026-06-05 00:02:44 233

原创 NITZ 网络时间与时区同步架构

NITZ (Network Identity and Time Zone) 是 3GPP TS 22.042 定义的标准机制，允许移动网络通过 NAS 信令（MM Information / GMM Information）向 UE 下发当前时间、时区偏移和夏令时信息。Android Telephony 框架通过状态机处理 NITZ 信号，并将同步后的时间/时区建议发送给（系统级时间服务）。

2026-06-05 00:02:15 272

原创 SIM 电话本 (Phonebook) 架构文档

SIM 电话本是 SIM 卡上存储联系人信息的 EF 文件系统。Android 16 维护了：传统的（基于逐条线性记录读取）和新的（基于 Modem 内建电话本功能），通过统一接口对外提供服务。

2026-06-02 22:42:27 230

原创 SIM PIN/PUK 管理架构文档

SIM 卡安全是 Android Telephony 的基础安全保障。PIN（Personal Identification Number）和 PUK（Personal Unblocking Key）是两个核心的 SIM 卡访问控制手段。

2026-06-02 22:40:52 221

原创 PhoneFactory / Phone 启动流程架构设计

从 RIL 连接的建立、UiccController 的创建、Phone 实例的构造到 SubscriptionManagerService 的启动，所有核心组件都在。获取 Phone 实例。这个过程如同"创世"——它必须恰好执行一次（double-checked lock），必须按正确的依赖顺序创建所有单例，必须在失败时提供合理的错误处理。反射注入比简单的工厂模式更灵活——不需要预先注册所有可能的子类，支持运行时根据配置决定实例化哪个类。统一了这两种实现，通过运行时判断来切换 GSM/CDMA 的行为。

2026-06-01 22:14:24 131

原创 RIL (Radio Interface Layer) 深度架构设计

RIL 是整个 Telephony 框架中最核心、最底层的组件。它位于 Framework 与 Vendor Modem 之间，承担着"翻译官"和"调度员"的双重角色——将 Java 层的调用翻译为硬件可以理解的 AT 命令/协议消息，并将 Modem 的响应和主动上报转发回 Framework。它是整条调用链的"最后一公里"。: RIL 的设计是一个经典的"中间层"架构，Google 在此投入了大量工程努力来处理异步通信、跨进程边界（Treble）、电源管理（WakeLock）以及 HAL 版本兼容性。

2026-06-01 22:13:34 214

原创 Subscription (多卡管理) 架构设计

这是一个乐观假设：用户拔卡后很可能会再次插入同一张卡（或者同运营商的另一张卡），提前将状态设为 enabled 可以减少用户重新插卡后的等待时间（无需从 disabled 手动重激活）。这在 multi-threaded 的环境中是经典的"写串行化"策略。的公开 API 层）持有订阅信息的缓存，通过此机制确保当底层数据变化时，公开 API 层能感知并重新从数据库加载。这样就避免了"值没变但执行了昂贵的切换操作"的情况，提高了系统效率。当一张新的 SIM 卡（或之前插过的卡）被放入卡槽时，是如何工作的？

2026-05-27 00:14:34 222

原创 SignalStrength 信号强度架构设计

不同 RAT 的信号测量物理意义完全不同（GSM 的 RSSI vs LTE 的 RSRP vs NR 的 SS-RSRP），因此每个。

2026-05-25 22:50:14 262

原创 IMS (IP Multimedia Subsystem) 架构设计

IMS 是移动网络从 CS (Circuit Switched) 演进到 PS (Packet Switched) 的关键架构。它使语音通话从传统的电路交换迁移到基于 IP 的分组交换网络上运行，这就是我们熟悉的 VoLTE (Voice over LTE) 和 VoWiFi (Voice over WiFi)。Android 框架不自己实现 IMS 协议栈，而是通过一套精巧的插件化架构委托给 Vendor 提供的实现。Google 的核心工作在于定义标准接口、管理服务生命周期、处理注册状态分发以及实现

2026-05-25 22:49:36 246

原创 UICC 架构与卡状态机详细设计

Google 在 UICC 模块的设计中体现了多项经典软件工程实践：全局单例控制、分层对象树建模、观察者模式事件分发、双缓存（内存+SharedPrefs）快速卡识别、以及完善的关机保护机制。这是策略模式（Strategy Pattern）的典型应用——不同的卡应用有不同的 EF 文件结构和解析方式，但对外提供统一的。作为 fallback 值。这确保了在旧版 HAL（不支持 SlotPortMapping）或异常情况下，系统仍能正常运行，体现了"向后兼容"和"降级服务"的设计思想。

2026-05-24 23:11:07 240

原创 Android Tethering/netd 集成架构深度分析

方法不仅仅是类型匹配（equals），而是考虑了请求参数的多维度相似性。Tethering（网络共享）模块是 Android 的网关功能核心，使设备可以充当 IP 路由器，通过 USB、WiFi 热点、蓝牙、以太网等下游接口向其他设备共享互联网连接。)，如果蜂窝也不可用，下一次重试不再请求蜂窝（避免持续占用不必要的移动网络请求），而是等待 Wi-Fi/以太网等其他上游变得可用。每个错误状态对应一个特定操作的失败（IP转发开启/关闭、Tethering启动/停止、DNS设置），进入错误状态后通过。

2026-05-24 23:10:11 303

原创 Telecom 通话管理框架架构设计

状态含义转换条件NEW通话刚创建，尚未拨出或接听DIALING正在拨出对端响应 →ACTIVERINGING来电正在响铃用户操作 →ACTIVEACTIVE通话进行中hold() →ON_HOLDON_HOLD通话保持中unhold() →ACTIVE通话已断开最终状态，Call 将被移除。

2026-05-22 18:35:43 249

原创【Telephony】IPC 跨层通信机制深度解析 (Binder & HAL)

Android Telephony 系统由于横跨应用层、系统服务层、硬件抽象层，其内部存在大量复杂的进程间通信（IPC）与进程内事件分发机制。理解这些通信链路，是排查 Telephony 问题的先决条件。Telephony 内部包含三种核心的通信/分发机制：第三方应用或系统 App 无法直接实例化对象，所有对外暴露的 API 都必须通过标准的 Android Binder 机制跨进程调用。跨进程调用 (IPC)getServiceState()getService("phone")返回 ITelepho

2026-05-22 18:35:21 262

原创 CellBroadcast 小区广播架构

小区广播（CB，Cell Broadcast）是一种点对多点的消息服务，允许网络运营商同时向小区内的所有移动设备发送文本消息。公众告警系统（PWS）：紧急地震、海啸、气象灾害等告警ETWS（Earthquake and Tsunami Warning System，日本地震/海啸预警）CMAS（Commercial Mobile Alert Service，美国商业移动告警，含总统级告警、极端威胁、安珀警报等）KPAS（韩国公共告警系统）EU-Alert（欧盟告警系统）小区信息广播。

2026-05-21 18:18:23 252

原创 TelephonyRegistry 事件中心架构设计

它充当 Telephony 框架内部事件与外部 App 监听器之间的"广播塔"——框架内部产生的事件（如服务状态变化、信号强度更新、来电通知）通过 TelephonyRegistry 分发到所有注册的 App 监听者。这支持了 Android 10+ 的位置权限临时授予模式——App 可以声明"虽然我有位置权限，但这次注册请不要给我位置敏感的小区数据"。这极大减少了不必要的 IPC 调用——一个只关注信号强度的 App 不会收到服务状态和小区信息变化的事件。这是一个微妙的细节但非常重要的正确性保障。

2026-05-21 01:05:47 231

原创 ServiceState (网络服务状态) 架构设计

使用数组而非单个 int 的原因是为了利用 Java 的引用相等性（reference identity）——数组是对象，不同轮询生成不同的数组对象可以实现精确的请求关联。这减少了跨进程调用的开销。如何通过"轮询+事件"双通道模型准确捕捉底层网络的每一次变化，并深入分析 Google 在此模块中的多项精妙设计技巧。Google 设计了。这种设计避免了"广播风暴"：当语音漫游状态变化时，不需要通知只是监听数据漫游变化的模块。动态管理不同的接入类型（WWAN/IWLAN），这充分体现了"多态统一"的设计哲学。

2026-05-20 00:02:08 254

原创 Data Connection (数据连接) 架构设计

至此，Telephony Harness 的四大核心业务模块——UICC（物理卡）、Subscription（逻辑卡）、ServiceState（网络注册）、DataConnection（数据连接）——已全部覆盖。它们构成了从"插入 SIM 卡"到"能打电话、能上网"的完整链路。: Android 16 的数据连接架构从老版本的"APN 类型为中心"彻底转变为"NetworkRequest 驱动"模式。等都是 Per-SIM 的），体现了 Google 的"SIM 级别资源隔离"设计原则。

2026-05-20 00:01:02 221

原创运营商配置 (CarrierConfig) 架构设计

定义了超过 500 个配置键，覆盖 VoLTE、VoWiFi、ViLTE、5G NR、紧急呼叫、短信、数据连接、Supplementary Service 等所有 Telephony 业务。运营商配置是 Android Telephony 框架中控制通话、短信、数据、IMS 等所有业务行为的"总开关"。定义了超过 500 个配置键，覆盖 VoLTE、VoWiFi、5G NR、紧急呼叫、短信、Supplementary Service 等所有 Telephony 业务。配置按订阅隔离，通过。

2026-05-19 00:32:12 257

原创语音通话业务 (Voice Call) 架构设计

IDLE（空闲）、RINGING（振铃）、OFFHOOK（摘机/通话中）。

2026-05-19 00:30:25 256

原创【Netd】初始化解析

启动失败直接退出：Netd 启动过程中核心模块（如 NetlinkManager、NetdNativeService）初始化失败会直接exit(1)，导致进程退出，进而引发 Framework 无法获取 Netd 服务（对应你之前遇到的阻塞）；分层初始化逻辑：从 “基础环境→内核通信→业务控制器→对外服务→进程常驻” 逐层依赖，前序模块失败会导致后续无法执行；常驻核心是 Netd 进程不退出的关键，此步骤后进程进入 “等待 - 处理请求” 循环，直到系统关机或进程被杀死。

2026-01-21 23:50:09 267

原创记录一下MMKV使用

MMKV是腾讯开源的高性能键值存储框架，相比SharedPreferences具有显著优势：采用mmap内存映射和增量更新技术，读写性能接近内存操作；原生支持多线程安全和跨进程通信；支持更多数据类型。文章通过对比SharedPreferences和ContentProvider，分析了MMKV的核心优势、关键技术实现和适用场景，并提供了使用MMKV+Gson存储SIM卡信息的完整案例，包括单例模式实现、线程安全处理和跨进程支持。MMKV适合高频读写、大数据量存储等场景，但不适合结构化数据存储和复杂查询需求。

2025-07-19 23:46:51 1011

JonrayZ的博客