update whereNOTIF_SMS_BATCH set state=.99. where BUSI_

Android6.0中对短信的处理比起老版本还是變化有点大的在分析源代码之前,我们可以先猜测一下中接收短信的大致流程首先根据之前分析phone应用的经验,猜测最先接收到短信消息的肯定是Modem接着上报的RILJ,RILJ在通知到XXXTracker之后也许会有个SmsManager的东西作统一管理,再之后就是App层当然,这仅仅是猜测到底是不是需要看代码。

RILJ与RILD以及Modem的交互方式在之前的phone应用分析中就已经详细叙述了这里直接从RILJ开始。由于接收短信底层主动上报的消息(非URC消息)因此由RILJ. processUnsolicited()处悝。我们已经知道processUnsolicited()对消息的处理基本上都是分两个步骤的:1解析出消息包;2,将详细包通知到其Registrant如下:

可以看到,对于不同类型的短信是作了区分处理GSM短信通知给了mGsmSmsRegistrant,而CDMA短信通知给了mCdmaSmsRegistrant在之前本博客对UICC卡的分析文章中:一张UICC卡是对应一个phone的,一个Phone对应一个RILJ那这里就囿点奇怪了,为什么一个RILJ会同时对GSM和CDMA短信作处理呢难道一个RILJ有可能管理两个RILD么?这块还有待研究

在之前的phone应用分析中其实也遇到过这樣的注册方式,通过这样的方式其实就是明确指出了只有一个注册者会接收此通知消息在SoureInsight中查找方法的调用者发现CdmaInboundSmsHandler在器构造方法中调用叻注册函数。

“状态”的构造和析构函数函数getName用于返回状态的名称,多用于调试目的

状态机有多少子状态,可在构建状态机时使用addState(State state, State parent)來添加所有的子状态,构建出一个层次状态关系初始状态可由setInitialState函数指定。 使用者应调用StateMachine的start函数让状态机进入工作状态:初始化状态堆栈调用初始状态(包括其父状态)的enter函数等。

其实说白了就是状态机会根据所处的不同状态调用不同的“HandleMessage()”(这里只是为了更好的说明其实准确的名字应该是processMessage(),其中的转换一想就明了了)并且状态机的各种状态之间是可以相互转换的。

dispatchMessageRadioSpecific(smsb)其实是过滤一些特殊的短信對于一些特殊的短信走的是特殊的处理,非特殊短信则直接放行让后面的函数处理dispatchMessageRadioSpecific为抽象方法,在子类中实现

首先需要指出的是本文所说的“系统SmsApp”只是短信接收后触发通知管理。本人查阅资料貌似说接收短信的有一个默认的App(可设置),这个App会第一时间接收到这个广播並且有最高的短信权限而其他app则权限较低。这里的系统SMSApp是在packages\apps\BasicSmsReceiver其配置文件配置监听了如下android.provider.Telephony.SMS_RECEIVED

我要回帖

更多关于 update where 的文章

 

随机推荐