手机实时提取SIM卡打电话的信令和声音

探索一：GSM硬件与Android电话RIL

缘起

其实，对手机呼叫转发的需求，确实是由来已久。此处转发个2012年的帖子：

如何通过将手机呼叫代理到SIP或skype来进行“穷人漫游”?

https://qastack.cn/android/26754/how-to-make-poor-mans-roaming-by-proxying-cell-calls-to-sip-or-skype

看了，我只能说：想屁吃呢，它要能搞，十年前它就搞出来了，直接搜就出来了，等现在？还网上求助，你当上龙王庙求雨呢，发个帖就能把答案等到了？

不曾想，现世报、来得快，时隔两年，轮到我来踩这个坑了，所以说人不能太嚣张，对待前人没有走通的路，甚至是无人区，还是要心存敬畏之心。

多年后，我们翻看这些历史的篇章，这些也算是前辈了，好比莱特兄弟发明飞机前，无数先辈萦绕多年的飞天梦一样，人类何时才能像鸟儿雄鹰一样翱翔蓝天？

但是毕竟我们还是跟它们不同，我们生在红旗下、长在新中国，在项目需求的驱动下，我们有能力、也有决心去开拓新兴领域，而不是单纯去发帖等待答案。（不过他做得好像也没错，时隔多年，他如果不小心翻到这里，那他的需求，也算有答案了，虽然只是无数个解之一，不一定算得上最优解）

在本篇章中，我们将从最基础的地方入手，从原理层面，论证如果要实现这些能力，需要哪些支持？现有的市面上的技术和方案，是否已能满足要求？如果要往下开展，我们可以从哪些方向入手？

就让我们一起愉快的开始探索吧。

硬件-GSM模块

原理

我们作为软件研发，甚至是应用层面的人员，一天天的扯调频/调幅方式和逻辑，感觉也不太合适。此处抽象一点，主要做的A/D、D/A转换（模拟/数字转换），然后按照规划，在数模转换的前期，将数字信号提取出来、并且拦截原先通往话筒和听筒的通路。

手机GSM的工作原理框图大致如下：（我也是抄的，看看就行）

该原理的逻辑和图示，出处为《图解通信原理与案例分析-15》，写得挺详细通俗易懂的，有兴趣的可以查阅。

https://blog.51cto.com/u_11299290/3196103

GSM模块介绍

从历史的条件已知，过往的2G时代做得比较经典的GSM模块不外乎就几款，我们根据百度的结果，列举了几款常用的GSM模块，如文档《常见GSM模块介绍》所描述。

https://wenku.baidu.com/view/549c79e0336c1eb91b375d94

注意：这里有个很有意思的现象，我们说，项目需要“将数字信号提取出来、并且拦截原先通往话筒和听筒的通路”，现在，妈蛋，它根本没有数字的接口出来。看到了吧？出来的都是模拟信号，引脚引出的控制口是异步口，是用来收发AT指令控制信号的。

怎么取数据？还拦截原先的话筒/听筒的信号？看了好几款芯片都是这样，心慌慌。

简易版的手机

GSM模块会这样设计，不是没有道理的，因为没有需求。正常GSM模块或4G模块的封装，都是以易用性为基准。即不管是老人机、电话手表，还是高级的智能机，使用模块后，只需要装配少量的外部元器件，就可以实现一个稳定可通话设备。

但如果一个封装，引一个数字同步信号的引脚出来，也就意味着底板需要增加A/D、D/A模组，平白增加功耗和成本。

简易版的通话设备，可参考下面这位哥哥的纯手工的作品《使用Arduino和GSM模块进行呼叫和消息》，内容还是写得很详细的，打电话该有的功能都具备。

https://blog.csdn.net/acktomas/article/details/116123675

Linux-ALSA架构

架构简析

ALSA(Advanced Linux Sound Architecture)是linux上主流的音频结构，在没有出现ALSA架构之前，一直使用的是OSS(Open Sound System)音频架构主要的区别就是在OSS架构下，App访问底层是直接通过Sound设备节点访问的。而在ALSA音频架构下，App是通过ALSA提供的alsa-lib库访问底层硬件的操作，不再访问Sound设备节点了。这样做的好处可以简化App实现的难度。

具体的文章，可参考《ALSA系统简析》一文，看了感觉挺好的。（我就是搬运工）

https://blog.csdn.net/LinuxArmbiggod/article/details/128270673

Android 音频策略

闲话不说，直接上图：

这一堆输入输出设备里面，比较常用的就是HDMI，扬声器，3.5mm圆孔耳机，USB耳机，还有蓝牙耳机。

注意：这里的输入输出通道，对我们的后续选型有直接的影响。

没错，我就是那个搬运工，文章出处《Android 音频策略（音频优先级，音频输入输入，声音优先级）》，感兴趣的自己看。

https://zhuanlan.zhihu.com/p/617022941

RIL与打电话流程

这个章节，本来我是打算写很多内容的，一个原因是我们预研时在这里投入了大量的力气，另一个原因是这个架构是Android关于电话策略的核心内容。

但是后来我看了同为CSDN的分享《Android打电话流程学习（一）》，觉得我写得再好，也不会有它写得那么详细简洁，不写了，想看自己去看。反正我在RK平台调试时，基本也是按照这个脉络来上下调整的。

https://blog.csdn.net/weixin_45099376/article/details/126499597

界面应用Dialer和其它系统应用，与RIL的交互时序可参考下图：

从移植的角度看Android声音

我们当时去试的时候，手上有两款设备：RK3288/3399设备，和一个Root过的红米手机。试验和调试过程相当的漫长，一言难尽，不同平台依赖的内核和modem.img都不同。

具体的调试逻辑，可以参考瑞芯微RK的架构，以及网友前辈分享的文章《Android Audio 调试总结》，基本上来讲移植一款芯片到新的底板上要修改和调试的内容，跟文中描述的也差不多。区别是该文只涉及声卡芯片和声音驱动以及架构的调整，不涉及Modem的选型和调整而已。

https://zhuanlan.zhihu.com/p/56792351

语音架构和逻辑大致如下图：（看看就好）

总结

写了一大堆文字，都是搬运工，人懒就是没办法。我们做这块的探索，前前后后三个多差不多四个月，一直在寻觅一条出路，未果。

原因主要有以下两点：

1. 声音的切换流程，从硬件原理的角度来看，一定是在底板中实现，Modem中输出的直接就是模拟信号，怎么提数字信号？怎么拦截？当然我们选型的模块，可以找有数字同步引脚的模块，但是基本没有意义。所以，封装后的分流，要么走蓝牙HF的通道，要么从模拟信号中再加一个A/D、D/A转换模块，要么就找个有数字引脚的引出数字信号。
2. RIL/telephony这个逻辑，真的是锁得很严，当之无愧称为“系统级”应用，不要说提权、Root应用了，我就这么说吧：改了之后手机的稳定性都存疑，内核日志唰唰唰的往外冒。正常人绝对不会想去碰这个代码和逻辑。

综上，要想实现最初的需求和能力，还需进一步探索。稍后再看我们进一步的篇章，探索过程，人类的主观能动性相当重要，勿忘初心、砥砺前行。