本篇章中紧张列举Android系统中，3个关于电话语音方面的经典App，考试测验着结合公开出来的源码进行剖析，包括：
打电话运用Dialer（传说中的Phone）录音机运用SoundRecorder小爱通话（com.xiaomi.aiasst.service）结合高下文，以及前文中关于RIL/telephony的干系层级关系，对手机SIM打电话通话过程信令和语音的数据进行剖析。
别找了，这玩意就一空壳，上层运用的这几个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锁！
包括两点：
真的是“高真个食材，每每采取最朴素的烹饪办法”，也便是说，这样搞是没有出息的。当前这种打法，和下一篇章中的《安卓提权与特权运用Mock Bluetooth》，这些做法，都无法绕开BL锁，也就意味着很少有客户群体用，无法快速实现我们思考方案的【希望在当世大量手机的存量市场的条件下，采取一种所有手段都无法约束的标准化办法，打通互联网/移动互联网 与传统电话网络之间的隔离】。
而且，上述列举的这个内容，还没有涉及法律风险的问题。你刷别人的机器，或者是勾引别人刷机，你可以推脱为“用户自发的行为”？还是法律约定的“毁坏打算机系统”罪？刷机的人无责，你供应这种工具的是不是有责？
以是走这条线路方向的，还是谨言慎行，千万记得武断不移的走社会主义道路，这才是阳光大道。
