手机实时提取SIM卡打电话的信令和声音-(二、Android提取声音经典案例)
本篇章中主要列举Android系统中，3个关于电话语音方面的经典App，尝试着结合公开出来的源码进行分析，包括：
- 打电话应用Dialer（传说中的Phone）
- 录音机应用SoundRecorder
- 小爱通话（com.xiaomi.aiasst.service）
结合上下文，以及前文中关于RIL/telephony的相关层级关系，对手机SIM打电话通话过程信令和语音的数据进行分析。
- 打电话应用（包名：com.android.incallui等）
别找了，这玩意就一空壳，上层应用的这几个Dialer、Telecom、TeleService，甚至是framework的服务telephony/telecomm，这些，都是空壳。所有的打电话逻辑基本都封装在RIL底层的vendor目录，然后底层就会挂载modem.img基带镜像中的驱动，触发GSM模块的AT指令进行对应的操作。然后这一堆vendor相关的，不开源。
上述的这一堆应用和服务，干了些啥呢？约束和权限。它们啥正事没干，光干这个去了，弄了一堆广播、IBinder等反射调用，然后在反射中悄悄隐藏对user、对system_id等判断，不符合的就把你的操作拦了，净整些没用的。
但是，回过头来一思索，感觉好像Android这样搞也没错。作为一个操作系统层面的平台，某一款手机选用高通、MTK、展讯、海思各种芯片都有可能，而且具体打电话的逻辑都封装在模块里面，它能怎么办呢，除了约束一下接口、把各个平台的调用方式统一，归结到RIL的架构体系下，然后开放RILd之外，它还能干啥？
结果这么一轮操作下来，Android打电话部分，最核心的篇章反倒是【Android 音频策略】，尴尬不？我们平时看到的电话的操作界面，以及上述的这些电话应用和服务，都是为GSM模块/4G模块打杂的。
特意注明：按照规划，如果使用此方式，发布的应用将属于定制ROM的范畴。
电话应用的上下调用逻辑大致如下：
我又开始搬运了，《Android Dialer--通讯整体过程分析》及它引用的文章，挺经典的，有兴趣的可以跳进去看看。懒得写了，写了也没啥用，一个空壳应用你写出花来，也解决不了我们最初的需求，何必浪费大家时间。内容大致如下图所示：
https://blog.csdn.net/qq_35427437/article/details/89968398
注：这个章节其实挺重要的，我们有一版烧录ROM的过程产品就是修改RIL的逻辑，进行电话信令的收发和事件状态的同步，只是它不涉及语音媒体数据而已。
- 录音机应用（包名不固定，有些手机如Oppo/Vivo会重写）
录音机，大家其实都知道是怎么回事，靠这玩意取语音数据，可以。但想靠它的原理来拦截语音数据，使其不默认流向听筒/麦克风，就想太多了。
录音机的原理，其实是手机底板硬件设计时，预留的一个接口，GSM模块流出来的语音同步数据，会在底板进行统一的调度，然后再根据音频策略进行分流。
在Android中，这个接口其实一直都有，基本就类似于：mRecorder.setAudioSource(MediaRecorder.AudioSource.VOICE_CALL);
这样的代码就默认能够从调度策略中，同时取到本地麦克风和听筒扬声器这两个音频设备混杂在一起的声音数据。区别只是App需要权限而已，普通App调用不了。但我们本篇以及前面几个篇章也没说是普通App（都定制ROM、刷固件了，能普通吗）
你看，打电话的音频数据也取到了，电话信令在上一章节也取到了。完全达到了我们预研初期说的【手机实时提取SIM卡打电话的信令和声音】，好了，结项。今晚开香槟、吃大餐。（现在就完结了，会不会被耐心读到这里的读者打死？）
明显不行，或者说还不够。我们最初的目的，并不是监听或者监控，而是对“打电话”这个行为进行接管，把它从接听的最末尾的节点中解放出来，转移到其它周边的设备或应用（咱也不管它是用蓝牙耳机接打、3.5mm音频线耳机接打，或是AI接打）。前述的研究，明显还不能实现这个逻辑，需要进一步预研。
本篇，引一个其它文章《android实现通话自动录音上传》，感兴趣的可以看看。本身录音应用也没什么内容，都是手机底板和系统预留的接口，留就有、不留就没有，有权限就能读，没权限就读不了。有什么好说的呢。内容大致如下：
https://www.jianshu.com/p/e64cf8be09cf?share_token=8639f66e-1f26-4175-be10-3ea3ed755540
- 小爱通话
各位大哥我错了，找不到源码。它的apk取了，逆向工程了一下，有一些信息，但是没开源，知识产权所限，我们也不能乱写。
不仅这个App，后面的特权应用Mock Bluetooth，我们也仅取到了apk，没有关于源码的任何信息。
后面读者或者其它大佬，有这方面的资源和信息，可以分享一下，大家互相学习，一起促进共同进步。
总体来讲，小爱通话这个应用还是不错的。至少，其联网后ASR的文字识别率还是杠杠的。当然其AI，智能化程度跟智障也差不了多少。仁者见仁吧。
- 总结
我们想了一下，还是决定留一些篇幅在末尾，讲述一下这个路线，以及定制ROM的过程产品。我们这个团队花了挺长时间在这个方向，而且出了一版过程产品。详情可以参看我们之前写的篇外《篇外、自研专用手机产品和风险分析》，想一想，为什么我们会总结这么一篇出来。
我们输出了一个基于红米的ROM固件，刷了之后，确实实现了预期的效果，可能有Bug但先放下。本想基于这套理论去走手机方案商定制机型/刷现有公版手机的方案（因为我们改动的基本都在AOSP里面）。
但实践证明，这个路，是走不通的。
定制机型主要是价格问题，工业化生产制约成本最大的因素就是数量，这么搞根本没有任何竞争优势。而且自己发行设备，当初移动电信营业厅的合约机的道路，前车之鉴不远。
刷现有公版手机的方案，更加坎坷。我们早期一直认为这个方向难点在于内核适配、AOSP framework逻辑调整、稳定性，再不济就是刷机的步骤繁琐、机型适配等地方。毕竟，应用提权嘛，还是得有这种觉悟。
最后固件出来了，刷了3台测试机，我尼玛，难点在于解锁BL锁！包括两点：
- 不同品牌和机型为解锁BootLoader，设置了层层阻碍。
- 很多耳熟能详应用，依照这些，来判断是不是安全环境，不安全不允许安装和使用。也就是说你要是敢刷机，就要做好“专用”设备的心理准备。
真的是“高端的食材，往往采用最朴素的烹饪方式”，也就是说，这样搞是没有前途的。当前这种打法，和下一篇章中的《安卓提权与特权应用Mock Bluetooth》，这些做法，都无法绕开BL锁，也就意味着很少有客户群体用，无法快速实现我们思考规划的【希望在当世大量手机的存量市场的前提下，采用一种所有手段都无法约束的标准化方式，打通互联网/移动互联网 与传统电话网络之间的隔离】。
而且，上述列举的这个内容，还没有涉及法律风险的问题。你刷别人的机器，或者是引导别人刷机，你可以推卸为“用户自发的行为”？还是法律约定的“破坏计算机系统”罪？刷机的人无责，你提供这种工具的是不是有责？
所以走这条线路方向的，还是谨言慎行，千万记得坚定不移的走社会主义道路，这才是阳光大道。
5万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
