BTrunc设计思路 - Githubissues

1.架构 1.1.TMO

1.2.DMO

备注：DMO其定位是作为TMO通信模式的延伸，其最佳射频范围是在250米以内，作用范围小，通常是在TMO模式不可用的情况下，比如高山，隧道，这时需要用DMO来代替，完全不依赖网络信号的强弱

1.3.Echat

2.时序图 2.1.GotaSystem 初始化

备注：GotaUI启动时，启动GotaSystem这个框架服务，GotaSystem完成内部子系统初始化之后，向GotaUI发送启动完成消息，GotaUI继续完成依赖GotaSystem的初始化，比如注册关心的消息 2.2.GotaSystem内部子系统初始化过程

2.3.LTEPhone的初始化过程

2.4.LteServiceTracker的初始化流程

2.5.CallReceiver的初始化流程

2.6.CallInscreen的初始化过程

2.7. CallOutScreen的初始化流程

2.8. GotaWidgetProvider的初始化流程

2.9. CallStatusProcessForMDS的初始化流程

2.10.LTECallTracker初始化

2.11.LTEMedia的创建

2.12.LTECallTracker激活

2.13.LTECallTracker反激活

2.14.来电

全双工接通来电

主动呼叫

话权超时 2.15.群组更新

备注：大概流程如下 1） CP向AP发送组信息更新指示信令PTTGROUPUPDATE； 2） LTERIL收到该信令后通知注册该信令的监听者LTEGroupManager； 3） LTEGroupManager收到该消息后延迟6秒向RIL发起群组查询的请求 4） CP收到AP群组查询请求后上报PTTGROUPINFO信令，将终端所属群组带上来 5） LTERIL收到群组信息后，解析，委托给监听者LteSystemGroupReader更新到数据库 2.16.DMO

DMOCallTracker申请话权

申请话权成功

申请释放话权成功

DMORIL上报话权听时序图

修改DMO模式下参数时序图（以修改亚音频为列） 2.17.DMO Active激活流程

备注：DMOPhone的Active流程，由于没有跟其他Phone的切换交互，所以相对简单，但是也要考虑切换失败的情况，比如DMO模块上电失败等。DMO上电成功后，需要设置的参数包括频率，亚音频，信噪比，切换到DMO声音通道等 2.18.服务状态的状态机

未注册状态到注册状态

Register状态后的初始化过程

飞行模式

摇晕状态 2.19.LTEPhone与DMOPhone相互切换

2.20.PPP0的建立释放

备注：进入到Register状态，才会发起ppp0的建立流程，当退出Register状态(切换到其他状态)时，会发起ppp0的释放流程2.21.GotaSystem向GotaUI上报消息

备注：暂态消息，状态，信号 UI要求注册后就立刻上报 2.22飞行模式

2.类图与职责 2.1.System类图

2.2.UI类图

2.3.LTECallTracker类图

2.4.DMO类图

2.5.DMO代码分类图

2.6.DMO类图

2.6.RIL类图

备注：负责DMO CP侧与DMO AP侧交互的接口类，是AP与Modem连接的管理层，用于管理AP与Modem之间的一对一的响应以及Modem主动上报的命令，以及控制Modem硬件驱动。主要负责数据的可靠性传输，AT命令的发送以及Response的解析，不涉及到状态维护，包括收和发两个线程 2.7.Echat类图

2.6.具体职责 GotaSystem.java 对UI提供所有的业务功能接口供UI调用，对UI屏蔽具体的实现，所以对UI来说，只知道有GotaSystem，而不知道GotaSystem之下的任何子系统

PhoneRespone.java 提供UI对gotasystem系统业务的消息注册，以及GotaSystem对UI的消息上报，内部保存UI对系统业务关心的消息注册表（RegistrantList.java类的实例对象）

PhoneManager.java 负责处理LTEPhone和DMOPhone的初始化以及二者的切换。同时，为GotaSystem提供当前激活的Phone实例，以供下发具体命令

PhoneBase.java 是LTEPhone和DMOPhone的基类，是抽象类，onActive()处理激活当前Phone时要做的事情，onDeactive()处理被反激活时要做的事情

LTEPhone.java 初始化子功能模块以及下发所有处于LTEPhone状态的事件，包括呼叫、服务状态、群组、短信等等。在GotaSystem.java中与BTrunC业务相关的所有具体实现都是通过该类调用相关模块的状态类下发到ril层，是BTrunC业务消息的分发中心

LteServiceTracker.java 状态机，初始化四个服务状态以及相关的状态管理和切换，其包含四个子状态：RegisteState，UnRegisteState,DistanceKillState,AirplaneState与这四个状态相关的事件都是由其注册到ril中并接受ril的上报事件下发到四个状态中处理

ServiceStateBase.java 状态机基类，Enter():主要是通知serviceTracker进入某个状态后通知UI;exit():退出时所需要做的某些操作。其四个子状态类为 UnRegisteState.java：正常模式进入后的首个状态； RegisteState.java ：attach后进入的状态； AirplaneState.java ：飞行模式状态； KilledState.java ：收到遥晕遥毙后的状态；

LteEcmManager.java 处理网络状态及拨号相关的业

LteGroupManager.java初始化四个群组更新状态的管理和切换，GroupStatusNomal，GroupStatusUpdate,GroupStatusRead,GroupStatusSetScan，通过上报事件驱动状态变化并在相应的状态中处理业务，向上提供对外的接口，如设置扫描组、主动请求群组更新。调用接口一方不需要关心当前群组更新的状态，模块内部已经处理好了流程并发和需要兼容的场景

GroupStatus.java是四个群组状态的基类。主要包含五个方法：（某一个复杂的具体业务用状态机还是很新奇的） readGroupInfo():读取群组 handleUpdateGroup():处理更新群组 handleGroupInfo():处理群组上报消息 updateScanGroupInfo():下发设置扫描组的指令 handleUpdateScan():处理设置扫描组的结果消息其四个子状态类为： GroupStatusNomal.java：未进行群组更新及设置扫描组的正常状态 GroupStatusUpdate.java ：收到GroupUpdate后进入的状态 GroupStatusRead.java ：处理完GroupUpdate进入读群组时的状态 GroupStatusSetScan.java ：收到GroupInfo后设置扫描组的状态

WMSDispatcher.java 处理短信收发消息

LTECallTracker.java 框架层中集群业务在RIL之上的处理，其存在前提是LTEPhone 搜到网并处于注册状态，负责LTEPhone以及RIL中与呼叫相关业务的事件的接收和处理，在有来电或去电时，根据Call id及其他呼叫参数新建Call，在新建Call时，添加CallList用来跟踪当前所有的Call，在Call挂断时，从CallList里删除对应的Call CallBase：基类，抽象Call的基本功能业务。 PTTCall：继承CallBase，创建呼叫状态类，负责呼叫管理、话权管理、状态通知。呼叫状态LTECallStatus分别包括6个状态，LTECallDefaultStatus，LTECallWaitingStatus，LTECallConnectStatus，LTECallIdleStatus，LTECallSpeakStatus，LTECallListenStatus

1）呼叫状态管理，呼叫包括全双工和半双工两种类型，呼叫类型不同，呼叫状态有区别，将全双工的呼叫状态分为待机状态、等待状态、呼叫状态、断开状态；将半双工的呼叫状态分为待机状态、等待状态、话权空闲状态、话权听状态、话权讲状态，断开状态，维护呼叫链表CallList，每一路Call分别维护各自的呼叫状态管理。LTECallTracker通过CallList中的Call来管理呼叫中的这些状态，状态的转换是以事件消息来驱动（比如，起呼（请求事件）、来电（RIL上报事情）等 2）消息的上报机制，业务处理与 UI的显示同步，LTECallTracker需要实时的把业务状态上报给UI。在LTECallTracker没有把收到的事件直接上报给UI处理，而是LTECallTracker将各种事件转换成状态的变化，然后将激活的状态和去激活的状态上报给UI。在LTECallTracker里注册所有的事件消息到ril里，在收到ril上报的消息时，根据Call id以区分到具体哪一路Call 3）主动请求的处理主动请求的事件由LTECallTracker根据callId分发到各个Call里，由具体Call通知状态进行处理、

3.用例图 3.1.PhoneRespone用例图

3.2.PhoneManager的用例图

3.3.LTEPhone的用例图

备注：下发所有处于LTEPhone状态的事件，包括拨号，查询状态，lte话权申请，释放等等业务的下发中转站 3.4.CallReciver的用例图

备注：数据为驱动来加载界面，还是界面为驱动来选择数据， 3.5.CallInScreen的用例图

备注：CallInScreen对象将CallActivity处理的业务逻辑分离出来，实现界面与业务的解耦，充当CP的角色

3.6.CallOutScreen的用例图

备注：负责屏幕之外的UI相关，包括状态栏的消息通知、铃声、提示音、震动、传感器的开关等，

3.7.CallStatusProcessForMDS用例图

备注：CallStatusProcessForMDS主要负责通知MDS程序，当前是否处于语音和视频呼叫中，避免两个程序抢占Camera和Mic资源导致程序异常（很具体的业务了）

3.8.LTECallTracker

备注：LTECallTracker负责呼叫状态的管理，处理集群呼叫业务，与RIL进行交互；负责媒体的管理：实现音视频的输入输出，与LinePhone进行交互； 3.9.LTERIL

3.10.LTEMedia

3.11.TMO与DMO切换

3.12.DMO

3.13.Echat

4.状态机 4.1.Phonestate状态机

4.2.群组更新业务的状态机

4.3.呼叫业务的状态机

全双工的状态图备注：全双工有三个状态，默认状态（LTECallDefaultStatus），接通中状（LTECallWaitingStatus），通话中状态（LTECallConnectStatus）

半双工的状态图备注：在半双工中，话权等待（LTECallIdleStatus）、话权听（LTECallListenStatus）、话权讲（LTECallSpeakStatus）都属于通话状态，在实现中，通话状态（LTECallConnectStatus）属于父状态，话权等待、话权听、话权讲这三个状态属于通话状态的子状态 4.4.echat的业务状态机

图13: 系统状态转化

图14: 集群通话状态转化

5.流程图 5.1.LTEPhone的active流程

5.2.LTEPhone切换到DMOPhone的流程

5.3.通话状态

5.4.LTE状态切换

5.5.DMO进入

5.6.DMO话权切换

6.UI 这就是为什么CallReciver那么臃肿的原因，system 只是提供接口，一旦某个业务是依赖于多个接口的组合判断，最好是根据具体业务放在不同的manager中统一处理，不然 CallReciver和万能类差不多了

设计思路为：CallReceiver监听GotaSystem的状态信息变化，CallInScreen、CallOutScreen、GotaWidgetProvider、CallStatusProcessForMDS监听CallReceiver的状态信息变化，当GotaSystem状态信息发生变化时，将状态信息通知CallReceiver进行处理，CallReceiver对状态信息做出处理后，再将处理后的状态信息通知CallInScreen、CallOutScreen、GotaWidgetProvider、CallStatusProcessForMDS。而观察者根据这些状态信息，向用户呈现界面、铃声、震动、通知、摄像头和MIC的占用等情况 8.数据库设计各个模块的Provider只提供数据库的最基本增删改查操作，其对外的具体接口需求由各Manager进行封装，表和字段设计如下： CallLog: 只记录单呼的通话记录

Contacts：联系人相关的信息，如姓名，号码，头像，姓名的拼音缩写，电话号码，号码类型，头像

GotaGroup：快播组和扫描组

Settings：设置

GroupManager

9.安全

数据安全存储思路 1）对于集群业务数据，实时数据（包括语音、视频对讲、位置数据等）不在终端侧进行离线存储 2）其他非实时数据包括集群通讯录、群组列表、集群通话记录、短彩信及多媒体附件（图片、音视频等，附件加文本不超过20M）需要缓存到本地，这部分缓存数据同样需要加密存储到本地，应用退出或系统关机后立马删除 3）其他应用数据，通过CPU 加密能力调用加密算法进行数据加密，完成加密后保存到设备分区达到安全存储目的 4）设备信息擦除模块，支持安全删除用户敏感数据来对用户信息进行保护，全盘销毁功能，系统分区和数据分区中数据全部擦除，销毁后不可恢复

图1-8密卡服务架构图

10.MCPTT / ECHAT 10.1.场景视图

图2：系统位置图备注：用户的任何MCPTT业务请求，最终都是通过McPttApp下发到Gota System Framework，再通过sip协议栈下发到网络接口 10.2.系统间通信交互图

图4: 系统间交互通信图 10.3.技术点 1.通信：信令面AP使用sip协议通过公网数据业务和核心网进行通讯，媒体面通过公网数据业务，使用RTP来发送、接收媒体数据，网络链接一般是LTE的EHT0网口，也可以是WIFI，甚至可以是3G网络，SipRil和ETH0之间，一般通过socket通讯来下发控制指令，使用select方式接收网络侧下发的指令； 2.Qualcomm Modem和AP是物理相连，通过共享物理内存来相互通信 3.休眠与唤醒：业务逻辑处理过程中保持唤醒，Alarm定时先唤醒系统，后处理业务逻辑的目的，心跳保活流程 10.4.开发视图

备注：开发涉及到两台PC（一台安装Windows操作系统，一台安装Ubuntu操作系统），分别用于APK的开发、ROM软件的阅读修改和ROM软件的编译。在Ubuntu系统上编译ROM软件之前，将Window开发出来的APK，预置到ROM代码中，和ROM代码一起编译，最后形成一套整机软件，由flashtool工具下载到目标样机中 10.5.逻辑视图

图8: 系统分层结构图 10.6.需求场景集群客户不再满足于原有的专网集群通信，提出了公网集群通信以及不同厂商接口标准化的需求，即从非标准的专网集群向标准化的公专网结合集群演进。MCPTT业务正是为了满足这些需求而产生，用户可以通过蓝牙、局域网，LTE等多种方式来接入MCPTT服务，UE实现时需要考虑对各种不同网络环境的支持；提供专业对讲服务的行业定制终端，公专网络部署，专网版的微信；系统性能包括MCPTT涉及的呼叫建立时间、媒体传输的时延、对网络带宽的占用等内容； MCPTT系统的用户面信令都是承载在RTP协议上的，由RTCP控制；为了确保网络的安全性，MCPTT系统，在控制面提供空口加密和SIP信令加密。在用户面提供端到端加密；

10.7.协议 RTCP - 多媒体控制协议