<?xml version="1.0" encoding="utf-8" ?><rss version="2.0"><channel><title><![CDATA[JonrayZ的博客]]></title><description><![CDATA[]]></description><link>https://blog.youkuaiyun.com/JonrayZ</link><language>zh-cn</language><generator>https://blog.youkuaiyun.com/</generator><copyright><![CDATA[Copyright &copy; JonrayZ]]></copyright><item><title><![CDATA[DataNetwork 数据网络 HAL 抽象架构]]></title><link>https://blog.youkuaiyun.com/JonrayZ/article/details/161602358</link><guid>https://blog.youkuaiyun.com/JonrayZ/article/details/161602358</guid><author>JonrayZ</author><pubDate>Thu, 11 Jun 2026 23:12:00 +0800</pubDate><description><![CDATA[是 Android 11+ Telephony 框架中数据面 HAL 抽象的核心类。它代表一个已建立的蜂窝数据连接在框架层的逻辑对象，负责管理该连接的网络接口（NetworkAgent）、链路属性（LinkProperties）、能力集（NetworkCapabilities）、QoS 参数以及连接的生命周期。在 Android 13+ 的 5G 多切片（Network Slicing）架构中，一个 SIM 卡可以同时拥有多个。]]></description><category></category></item><item><title><![CDATA[Telephony 线程模型 — AsyncResult / RegistrantList / HandlerThread]]></title><link>https://blog.youkuaiyun.com/JonrayZ/article/details/161602543</link><guid>https://blog.youkuaiyun.com/JonrayZ/article/details/161602543</guid><author>JonrayZ</author><pubDate>Thu, 11 Jun 2026 23:11:10 +0800</pubDate><description><![CDATA[Android Telephony 框架是全异步 + 多线程架构的典范。由于 RIL 层通信本质上是异步的（AT 命令 → Modem → 等待响应），Google 设计了一套贯穿全框架的异步消息传递基础设施（异步结果载体）、（观察者列表）、Registrant（弱引用观察者）。这三个类虽不超过 300 行代码，却是整个 Telephony 框架几十万行代码的"血管系统"——所有 RIL 回调、状态变更通知、跨层消息都通过它们流转。]]></description><category></category></item><item><title><![CDATA[RILD 原生层架构设计 (Native RIL Daemon)]]></title><link>https://blog.youkuaiyun.com/JonrayZ/article/details/161778879</link><guid>https://blog.youkuaiyun.com/JonrayZ/article/details/161778879</guid><author>JonrayZ</author><pubDate>Mon, 08 Jun 2026 23:16:06 +0800</pubDate><description><![CDATA[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 使用经典的"动态加载 + 回调注入"模式。]]></description><category></category></item><item><title><![CDATA[多 SIM 协作 (DSDS/DSDA) 架构文档]]></title><link>https://blog.youkuaiyun.com/JonrayZ/article/details/161602602</link><guid>https://blog.youkuaiyun.com/JonrayZ/article/details/161602602</guid><author>JonrayZ</author><pubDate>Sun, 07 Jun 2026 22:48:28 +0800</pubDate><description><![CDATA[多 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 资源协调者。]]></description><category></category></item><item><title><![CDATA[功耗管理与唤醒锁 (WakeLock) 架构文档]]></title><link>https://blog.youkuaiyun.com/JonrayZ/article/details/161602652</link><guid>https://blog.youkuaiyun.com/JonrayZ/article/details/161602652</guid><author>JonrayZ</author><pubDate>Sun, 07 Jun 2026 22:19:49 +0800</pubDate><description><![CDATA[Telephony 子系统是 Android 设备功耗的。Modem 与 AP 之间的通信存在本质的异步性：AP 发送命令后，Modem 可能需要几毫秒到几十秒才能响应。在此期间，如果 CPU 进入深度休眠，RIL 层将无法接收 Modem 的响应，导致命令超时、重试，甚至 Radio 挂死。因此，Telephony 系统在所有关键路径上使用确保 CPU 不会在等待 Modem 响应期间休眠。Android 16 的 WakeLock 管理体现了的三层设计。]]></description><category></category></item><item><title><![CDATA[eSIM / LPA (Local Profile Assistant) 架构文档]]></title><link>https://blog.youkuaiyun.com/JonrayZ/article/details/161602393</link><guid>https://blog.youkuaiyun.com/JonrayZ/article/details/161602393</guid><author>JonrayZ</author><pubDate>Sat, 06 Jun 2026 23:39:10 +0800</pubDate><description><![CDATA[eSIM (embedded SIM) 是 GSMA 定义的嵌入式 SIM 卡标准 (SGP.22)，允许用户无需物理 SIM 卡即可下载运营商 Profile。Android 16 通过API 层— 面向 App 的公开 API控制器层— 权限控制 + 操作队列连接层— 绑定到系统 LPA App（如 Google Play Services）卡层EuiccPort— APDU 命令透传到 eUICC 芯片。]]></description><category></category></item><item><title><![CDATA[飞行模式与 Radio 开关架构文档]]></title><link>https://blog.youkuaiyun.com/JonrayZ/article/details/161602667</link><guid>https://blog.youkuaiyun.com/JonrayZ/article/details/161602667</guid><author>JonrayZ</author><pubDate>Sat, 06 Jun 2026 23:35:30 +0800</pubDate><description><![CDATA[Radio 的开关是 Telephony 框架最基础也是最复杂的操作之一。它不是简单的"发一个命令给 Modem"，而是一个涉及数据连接拆除、通话挂断、IMS 注销、卫星 Modem 协调、多原因仲裁的完整生命周期管理。// TelephonyManager.java — Radio 电源状态常量// Radio 已关机// Radio 不可用（芯片未初始化）// Radio 已开机。]]></description><category></category></item><item><title><![CDATA[APN / DataProfile 数据配置架构文档]]></title><link>https://blog.youkuaiyun.com/JonrayZ/article/details/161602343</link><guid>https://blog.youkuaiyun.com/JonrayZ/article/details/161602343</guid><author>JonrayZ</author><pubDate>Fri, 05 Jun 2026 00:02:44 +0800</pubDate><description><![CDATA[APN (Access Point Name) 是手机建立数据连接的核心配置，告诉 Modem 如何接入运营商的分组数据网络。Android 16 使用三层模型（ApnSetting→→）来管理这些配置，通过统一加载、缓存和分发。]]></description><category></category></item><item><title><![CDATA[NITZ 网络时间与时区同步架构]]></title><link>https://blog.youkuaiyun.com/JonrayZ/article/details/161602526</link><guid>https://blog.youkuaiyun.com/JonrayZ/article/details/161602526</guid><author>JonrayZ</author><pubDate>Fri, 05 Jun 2026 00:02:15 +0800</pubDate><description><![CDATA[NITZ (Network Identity and Time Zone) 是 3GPP TS 22.042 定义的标准机制，允许移动网络通过 NAS 信令（MM Information / GMM Information）向 UE 下发当前时间、时区偏移和夏令时信息。Android Telephony 框架通过状态机处理 NITZ 信号，并将同步后的时间/时区建议发送给（系统级时间服务）。]]></description><category></category></item><item><title><![CDATA[SIM 电话本 (Phonebook) 架构文档]]></title><link>https://blog.youkuaiyun.com/JonrayZ/article/details/161602701</link><guid>https://blog.youkuaiyun.com/JonrayZ/article/details/161602701</guid><author>JonrayZ</author><pubDate>Tue, 02 Jun 2026 22:42:27 +0800</pubDate><description><![CDATA[SIM 电话本是 SIM 卡上存储联系人信息的 EF 文件系统。Android 16 维护了：传统的（基于逐条线性记录读取）和新的（基于 Modem 内建电话本功能），通过统一接口对外提供服务。]]></description><category></category></item><item><title><![CDATA[SIM PIN/PUK 管理架构文档]]></title><link>https://blog.youkuaiyun.com/JonrayZ/article/details/161602705</link><guid>https://blog.youkuaiyun.com/JonrayZ/article/details/161602705</guid><author>JonrayZ</author><pubDate>Tue, 02 Jun 2026 22:40:52 +0800</pubDate><description><![CDATA[SIM 卡安全是 Android Telephony 的基础安全保障。PIN（Personal Identification Number）和 PUK（Personal Unblocking Key）是两个核心的 SIM 卡访问控制手段。]]></description><category></category></item><item><title><![CDATA[PhoneFactory / Phone 启动流程架构设计]]></title><link>https://blog.youkuaiyun.com/JonrayZ/article/details/161204671</link><guid>https://blog.youkuaiyun.com/JonrayZ/article/details/161204671</guid><author>JonrayZ</author><pubDate>Mon, 01 Jun 2026 22:14:24 +0800</pubDate><description><![CDATA[从 RIL 连接的建立、UiccController 的创建、Phone 实例的构造到 SubscriptionManagerService 的启动，所有核心组件都在。获取 Phone 实例。这个过程如同"创世"——它必须恰好执行一次（double-checked lock），必须按正确的依赖顺序创建所有单例，必须在失败时提供合理的错误处理。反射注入比简单的工厂模式更灵活——不需要预先注册所有可能的子类，支持运行时根据配置决定实例化哪个类。统一了这两种实现，通过运行时判断来切换 GSM/CDMA 的行为。]]></description><category></category></item><item><title><![CDATA[RIL (Radio Interface Layer) 深度架构设计]]></title><link>https://blog.youkuaiyun.com/JonrayZ/article/details/161204683</link><guid>https://blog.youkuaiyun.com/JonrayZ/article/details/161204683</guid><author>JonrayZ</author><pubDate>Mon, 01 Jun 2026 22:13:34 +0800</pubDate><description><![CDATA[RIL 是整个 Telephony 框架中最核心、最底层的组件。它位于 Framework 与 Vendor Modem 之间，承担着"翻译官"和"调度员"的双重角色——将 Java 层的调用翻译为硬件可以理解的 AT 命令/协议消息，并将 Modem 的响应和主动上报转发回 Framework。它是整条调用链的"最后一公里"。: RIL 的设计是一个经典的"中间层"架构，Google 在此投入了大量工程努力来处理异步通信、跨进程边界（Treble）、电源管理（WakeLock）以及 HAL 版本兼容性。]]></description><category></category></item><item><title><![CDATA[Subscription (多卡管理) 架构设计]]></title><link>https://blog.youkuaiyun.com/JonrayZ/article/details/161204696</link><guid>https://blog.youkuaiyun.com/JonrayZ/article/details/161204696</guid><author>JonrayZ</author><pubDate>Wed, 27 May 2026 00:14:34 +0800</pubDate><description><![CDATA[这是一个乐观假设：用户拔卡后很可能会再次插入同一张卡（或者同运营商的另一张卡），提前将状态设为 enabled 可以减少用户重新插卡后的等待时间（无需从 disabled 手动重激活）。这在 multi-threaded 的环境中是经典的"写串行化"策略。的公开 API 层）持有订阅信息的缓存，通过此机制确保当底层数据变化时，公开 API 层能感知并重新从数据库加载。这样就避免了"值没变但执行了昂贵的切换操作"的情况，提高了系统效率。当一张新的 SIM 卡（或之前插过的卡）被放入卡槽时，是如何工作的？]]></description><category></category></item><item><title><![CDATA[SignalStrength 信号强度架构设计]]></title><link>https://blog.youkuaiyun.com/JonrayZ/article/details/161204690</link><guid>https://blog.youkuaiyun.com/JonrayZ/article/details/161204690</guid><author>JonrayZ</author><pubDate>Mon, 25 May 2026 22:50:14 +0800</pubDate><description><![CDATA[不同 RAT 的信号测量物理意义完全不同（GSM 的 RSSI vs LTE 的 RSRP vs NR 的 SS-RSRP），因此每个。]]></description><category></category></item><item><title><![CDATA[IMS (IP Multimedia Subsystem) 架构设计]]></title><link>https://blog.youkuaiyun.com/JonrayZ/article/details/161204661</link><guid>https://blog.youkuaiyun.com/JonrayZ/article/details/161204661</guid><author>JonrayZ</author><pubDate>Mon, 25 May 2026 22:49:36 +0800</pubDate><description><![CDATA[IMS 是移动网络从 CS (Circuit Switched) 演进到 PS (Packet Switched) 的关键架构。它使语音通话从传统的电路交换迁移到基于 IP 的分组交换网络上运行，这就是我们熟悉的 VoLTE (Voice over LTE) 和 VoWiFi (Voice over WiFi)。Android 框架不自己实现 IMS 协议栈，而是通过一套精巧的插件化架构委托给 Vendor 提供的  实现。Google 的核心工作在于定义标准接口、管理服务生命周期、处理注册状态分发以及实现]]></description><category></category></item><item><title><![CDATA[UICC 架构与卡状态机详细设计]]></title><link>https://blog.youkuaiyun.com/JonrayZ/article/details/161204698</link><guid>https://blog.youkuaiyun.com/JonrayZ/article/details/161204698</guid><author>JonrayZ</author><pubDate>Sun, 24 May 2026 23:11:07 +0800</pubDate><description><![CDATA[Google 在 UICC 模块的设计中体现了多项经典软件工程实践：全局单例控制、分层对象树建模、观察者模式事件分发、双缓存（内存+SharedPrefs）快速卡识别、以及完善的关机保护机制。这是策略模式（Strategy Pattern）的典型应用——不同的卡应用有不同的 EF 文件结构和解析方式，但对外提供统一的。作为 fallback 值。这确保了在旧版 HAL（不支持 SlotPortMapping）或异常情况下，系统仍能正常运行，体现了"向后兼容"和"降级服务"的设计思想。]]></description><category></category></item><item><title><![CDATA[Android Tethering/netd 集成架构深度分析]]></title><link>https://blog.youkuaiyun.com/JonrayZ/article/details/161204720</link><guid>https://blog.youkuaiyun.com/JonrayZ/article/details/161204720</guid><author>JonrayZ</author><pubDate>Sun, 24 May 2026 23:10:11 +0800</pubDate><description><![CDATA[方法不仅仅是类型匹配（equals），而是考虑了请求参数的多维度相似性。Tethering（网络共享）模块是 Android 的网关功能核心，使设备可以充当 IP 路由器，通过 USB、WiFi 热点、蓝牙、以太网等下游接口向其他设备共享互联网连接。)，如果蜂窝也不可用，下一次重试不再请求蜂窝（避免持续占用不必要的移动网络请求），而是等待 Wi-Fi/以太网等其他上游变得可用。每个错误状态对应一个特定操作的失败（IP转发开启/关闭、Tethering启动/停止、DNS设置），进入错误状态后通过。]]></description><category></category></item><item><title><![CDATA[Telecom 通话管理框架架构设计]]></title><link>https://blog.youkuaiyun.com/JonrayZ/article/details/161204709</link><guid>https://blog.youkuaiyun.com/JonrayZ/article/details/161204709</guid><author>JonrayZ</author><pubDate>Fri, 22 May 2026 18:35:43 +0800</pubDate><description><![CDATA[状态含义转换条件NEW通话刚创建，尚未拨出或接听DIALING正在拨出对端响应 →ACTIVERINGING来电正在响铃用户操作 →ACTIVEACTIVE通话进行中hold() →ON_HOLDON_HOLD通话保持中unhold() →ACTIVE通话已断开最终状态，Call 将被移除。]]></description><category></category></item><item><title><![CDATA[【Telephony】IPC 跨层通信机制深度解析 (Binder & HAL)]]></title><link>https://blog.youkuaiyun.com/JonrayZ/article/details/161204729</link><guid>https://blog.youkuaiyun.com/JonrayZ/article/details/161204729</guid><author>JonrayZ</author><pubDate>Fri, 22 May 2026 18:35:21 +0800</pubDate><description><![CDATA[Android Telephony 系统由于横跨应用层、系统服务层、硬件抽象层，其内部存在大量复杂的进程间通信（IPC）与进程内事件分发机制。理解这些通信链路，是排查 Telephony 问题的先决条件。Telephony 内部包含三种核心的通信/分发机制：第三方应用或系统 App 无法直接实例化  对象，所有对外暴露的 API 都必须通过标准的 Android Binder 机制跨进程调用。跨进程调用 (IPC)getServiceState()getService("phone")返回 ITelepho]]></description><category></category></item></channel></rss>