Android 4.4 Kitkat Phone工作流程浅析(四)__RILJ工作流程简析

本文来自http://blog.csdn.net/yihongyuelan 转载请务必注明出处

       本文代码以MTK平台Android 4.4为分析对象，与Google原生AOSP有些许差异，请读者知悉。
前置文章：
《Android 4.4 Kitkat Phone工作流程浅析(一)__概要和学习计划》

《Android 4.4 Kitkat Phone工作流程浅析(二)__UI结构分析》

《Android 4.4 Kitkat Phone工作流程浅析(三)__MO(去电)流程分析》

       通过上一篇文章《Android 4.4 Kitkat Phone工作流程浅析(三)__MO(去电)流程分析》，我们知道在 Android 4.4 中，拨打电话最终调用到了RIL.java中，并使用send()方法继续向下传递。本文主要目的是简单介绍RILJ工作流程，为后续MT流程分析打下基础。

RIL概述

       RIL 即 Ridio Interface Layer缩写，无线通信接口层，Android 中的实现分为RILJ和RILC两部分。RILJ属于Framework层中的Java部分( 后文使用RILJ指代RIL.java )，RILC属于HAL层中的C/C++部分(也就是rild)。RIL负责将AP层用户的通话控制信息传递给BP层Modem端，同时Modem端也会将相关处理结果返回给AP层。另外Modem状态有改变时也会主动上报给RIL层，再逐步向上传递并最终通过界面显示出来。本文仅简单介绍RILJ部分，详细分析请参看其他大神的分析。

RILJ与RILC以及Modem之间关系如图1：

图1

MO/MT在RILJ中执行流程：

1. MO在RILJ中流程：

       当用户执行MO(去电)时，通过层层判断之后，系统会将相关信息传递到RILJ中，封装好后使用AT指令的方式发送到Modem端，最终由Modem端发起通话请求。在通话接通后Modem端会返回相关AT指令信息给RIL层，RIL层再向上反馈。

整个MO(去电)流程可以简单的归结为两个步骤：

(1). ( Request ,  Response) ，即向RILC发起Request，再由RILC向Modem发送相关AT指令，等待Modem处理并反馈结果，如DIAL操作；

(2). (Response)，即在对方接通之后，Modem会将状态信息反馈到RILJ中；

2. MT在RILJ中流程：

       当Modem端收到来电信息时，会将相关来电信息通过AT指令发送给RILC，再通过RILC使用socket发送给RILJ，逐层向上传递，最终显示来电响铃界面。

MT(来电)与MO(去电)的第二步相同，通过( Response )，即Modem端主动上报状态改变信息；

我们先来看一下RILJ 的基本组成以及主要功能，图2为RILJ核心类图：

图2

通过上图我们可以看到，RILJ继承自BaseCommands实现了CommandsInterface接口，RILJ包含了三个内部类：RILRequest、RILReceiver、RILSender，分别对应mRequestsList、mSender、mReceiver三个对象。

RILJ中涉及通话控制和消息处理的关键方法：

通话控制类：

dial()，负责创建拨号RILRequest对象；

acceptCall()，负责创建接听RILRequest对象；

rejectCall()，负责创建拒接RILRequest对象；

以上方法最终会通过RILSender并使用socket方式向RILC发起相关请求。

消息处理类：

processUnsolicited()，负责处理UnSolicited反馈信息；

processSolicited()，负责处理Solicited反馈信息；

       这些消息来自RILC的socket反馈，在上一篇MO(去电)流程分析中，dial最终会调用到RIL.java中的RILSender对象的相关方法，向RILC继续传递拨号信息，而MT(来电)时Modem会将相关信息发送到RILC，RILC再将信息通过socket反馈给RILJ，在RILJ中通过RILReceiver接收并开始处理。RILSender负责通过socket向RILC发送RILRequest信息，RILReceiver负责以socket方式从RILC接收Response信息。当RILJ从RILC接收到相关信息时，会逐步向上反馈，这些信息分为两类：

1. Solicited Response

        请求返回消息，这类消息是上层主动请求Modem再由其返回的消息，这些消息由RILC上报给RILJ。比如当我们执行MO(去电)时，会通过RILSender发送dial类型的Request给RILC，RILC再传递给Modem端，再由Modem端发起通话请求。待对方接通之后Modem将相关信息发送到RILC，RILC将结果消息反馈给RILJ，此时由RILReceiver来接收并处理消息，这种消息就是Solicited消息。

       可以简单的理解为( Request , Response )这样成对出现，此时RILC向RILJ返回的Respone就是Solicited消息。

2. UnSolicited Response

       主动返回消息，这类消息由Modem端主动上报。比如当有MT(来电)时，Modem会接收到信息并向RILC发送来电消息，RILC将来电信息再发送给RILJ，这类没有request但由Modem主动上报信息就是UnSolicited信息。

       可以简单的理解为Modem端主动给RILC，再由RIC上报给RILJ的( Response )消息，这类消息就是UnSolicited消息。

无论是 Solicited 还是UnSolicited Respone 消息，在RILJ中都是有RILReceiver来负责接收并处理，整个RILJ的工作可以简单的用图3来描述：

图3

RILJ包含了RILSender和RILReceiver，其中RILSender负责发送Request给RILC，RILReceiver负责接收Solicited和UnSolicited的Response信息。

RILJ工作流程

RILJ的工作内容主要是负责向RILC发起Request，以及从RILC接收Response。主要涉及三个内部类：RILRequest、RILSender、RILReceiver，主要工作包含以下三大内容：

1. RILRequest的构造；

       RILRequest是RILJ的内部类，我们可以把RILRequest看成一个打包类，将相关信息进行加工处理后打包成一个规范的RILRequest并使用RILSender发送给RILC。在RILRequest类中最重要的方法莫过于obtain了，该方法完成了打包工作。我们在MO(去电)流程分析中有看到调用RILJ中的dial方法，并在dial方法中看到了RILRequest的打包代码，如下：

RILRequest rr = RILRequest.obtain(RIL_REQUEST_DIAL, result, mySimId);

这里再去看一下obtain方法的实现：

    static RILRequest obtain(int request, Message result, int simId) {
        RILRequest rr = null;
        synchronized(sPoolSync) {
            if (sPool != null) {
                rr = sPool;
                sPool = rr.mNext;
                rr.mNext = null;
                sPoolSize--;
            }
        }
        if (rr == null) {
            rr = new RILRequest();
        }
        //这里跟Android原生不同，这里多了一个参数simId用于MTK双卡手机标识哪一张SIM卡
        //static int[] sNextSerial = {0, 0, 0, 0};这里后面会从log中看到如"[233]"的编号
        //serial是Request的编号并且是唯一的
        synchronized(sSerialMonitor) {
            rr.mSerial = sNextSerial[simId]++;
        }
        //请求类型
        rr.mRequest = request;
        rr.mResult = result;//请求结果 Message对象
        rr.mParcel = Parcel.obtain();
        if (result != null && result.getTarget() == null) {
            throw new NullPointerException("Message target must not be null");
        }
        // first elements in any RIL Parcel
        rr.mParcel.writeInt(request);
        rr.mParcel.writeInt(rr.mSerial);
        return rr;
    }

2. RILSender发送Request；

       在Request构造完成之后我们在dial方法中看到最终调用了send(rr)方法，这里就用到了RILSender，RILSender也是RILJ中的内部类，通过查看send方法可以知道：

    private void
    send(RILRequest rr) {
        Message msg;
        if (mSocket == null) {
            rr.onError(RADIO_NOT_AVAILABLE, null);
            rr.release();
            return;
        }
        //RILSender集成Handler因此会跳转到相应的handleMessage方法中
        msg = mSender.obtainMessage(EVENT_SEND, rr);
        acquireWakeLock();
        msg.sendToTarget();
    }

通过前面的核心类图我们可以知道，RILSender集成自Handler，因此这里会跳转到RILSender的handleMessage方法中，并执行case EVENT_SEND，代码如下：

case EVENT_SEND:
    boolean alreadySubtracted = false;
    try {
    LocalSocket s;
    //获取LocalSocket，并对socket进行判断是否正常
    s = mSocket;
    //... ...省略部分代码
    //将Request添加到链表中
    synchronized (mRequestList) {
            mRequestList.add(rr);
    }
    //... ...省略部分代码
    //定义socket发送需要的byte数组
    byte[] data;
    //获取数据
    data = rr.mParcel.marshall();
    //... ...省略部分代码
    //向socket写入数据
    s.getOutputStream().write(dataLength);
    s.getOutputStream().write(data);
    }
    //... ...省略部分代码
break;

这里使用了socket的方式将拨号请求发送给了RILC，最后又RILC向Modem端传递。在完成以上步骤之后dial流程就走到了RILC中，再由RILC向Modem端发出dial的AT指令。

3. RILReceiver接收Response；

       当MO(去电)接听以及MT(来电)时，Modem端会将相关信息通过RILC发送给RILJ，负责接收的正式RILReceiver，RILReceiver也是RILJ的内部类，该类实现了Runnable接口，因此实际启动是以Thread的方式启动的。RILReceiver在PhoneProxy的构造方法中通过调用startRilReceiver启动，这里是MTK改动过，原生是直接在RIL.java的构造方法中启动线程。

RILReceiver主要完成两项工作：

(1). 维护local socket的连接；

(2). 阻塞local socket并处理RILC的Response ( Solicited 和 UnSolicited )；

RILReceiver启动之后会建立local socket并阻塞，代码如下：

        @Override
        public void
        run() {
            //... ...省略部分代码
            try {
                for (;;) {
                //... ...省略部分代码
                //建立并维护 Local Socket
                try {
                    s = new LocalSocket();
                    l = new LocalSocketAddress(socketRil,
                            LocalSocketAddress.Namespace.RESERVED);
                    s.connect(l);
                } catch (IOException ex){
                //... ...省略部分代码
                //当连接失败后休眠4s并继续尝试连接
                }
                //... ...省略部分代码
                try {
                    InputStream is = mSocket.getInputStream();
                    for (;;) {//阻塞
                        Parcel p;
                        length = readRilMessage(is, buffer);
                        if (length < 0) {
                            // End-of-stream reached
                            break;
                        }
                        p = Parcel.obtain();
                        p.unmarshall(buffer, 0, length);
                        p.setDataPosition(0);
                        //处理Respone消息(Solicited和UnSolicited)
                        processResponse(p);
                        p.recycle();
                    }
                }
                //... ...省略部分代码
        }

那么通过以上分析我们可以简单的将RILJ的工作流程总结为：打包，发送，接收三个步骤。在RILReceiver中接收到RILC的socket信息之后，使用processResponse进行处理，进而分为processUnsolicited()和processSolicited()方法。

processSolicited()方法主要完成以下三件事：

(1). 根据Response中的request serial编号找到RequestList中的对象并移除；

       因为Solicited的Request是一一对应的，当处理完本次Response之后不再需要改Request对象，因此这里会移除，使用方法findAndRemoveRequestFromList()。

(2). 根据request的类型使用responseXXX方法处获取从RILC中返回的信息；

       这里会有很多request类型，对应的responseXXX方法也有很多，比如responseInts()、responseVoid()、responseString()、responseOperator()等等，通过这些方法取出Parcel对象中的内容，该对象中包含了Request需要查询的信息。

(3). 将第2步获取到的信息存储到Message中并触发回调；

执行代码如下：

if (rr.mResult != null) {
    AsyncResult.forMessage(rr.mResult, ret, null);
    rr.mResult.sendToTarget();
}

我们知道RILRequest类中有定义mResult为Message类型，在obtain方法执行的时候已经对mResult进行了赋值，这里的Message就是从GSMCallTracker中传递过来的，有兴趣的童鞋自己追踪一下吧，注意看清楚dial中的参与即可。也就是说通过分析我们知道processSolicited()处理完成会携带相关信息跳转到GSMCallTracker中继续执行。

processUnsolicited()方法主要以下两件事：

(1). 根据response消息的类型使用responseXXX方法处获取从RILC中返回的信息；

这一步和processSolicited()方法的第2步类似，并将从Parcel对象中获取到的数据保存到局部变量Object类型的对象ret中。

(2). 使用notifyRegistrants()方法将相关信息通知到订阅者( Subscribe )；

因为这里使用的是观察者模式( Publisher-Subscribe )，相关订阅者会根据获取到不同的信息作出与之对应的反应。

       对于MO(去电)而言，整个过程既包含了processSolicited()也包含了processUnsolicited()。为什么这么说呢？当我们执行dial操作后，会将相关信息发送到Modem端，此时执行的步骤是DIAL，Modem端发起DIAL成功后返回给RILJ，这个步骤就是( Request , Respone )。之后如果对方接通了那么Modem会将相关信息反馈给RILJ，这个步骤即( Respone )，通过Radio Log可以看到：

(a). 拨号Request和Respone

D/RILJ    (  966):  RIL(1) :[0253]> DIAL
D/RILJ    (  966):  RIL(1) :[0253]< DIAL 

(b). 返回MO接通的Respone

V/RILJ    (  966):  RIL(1) :[UNSL RIL]< UNSOL_CALL_PROGRESS_INFO {1, 6, 0, 1, 0, 0, 13800138000, 145, }

至于MO接通后返回信息里面的参数这里不详细解释，主要是AT指令中携带的信息，不同硬件平台会有一些自己的定制。对于Request和Respone并不一定是连续出现在Log中的，我们只需要查看其唯一的serial编号即可找到Request对应的Respone。另外，在RILJ的Log中我们可以根据大于(＞)符号和小于(＜)符号来判断是Request还是Response，即：

(I). 大于符号(＞)对应Request，表示RILJ向RILC发送请求；

(II). 小于符号(＜)对应Response，表示RILC向RILJ反馈信息；

       前面我们说过Solicited信息是成对出现的，通过log也能证明这一点，平时查看Log可以根据request的serial编号来找到对应的response。在完成以上拨号操作之后Solicited信息就执行完毕了，接下来是等待对方接通，若对方接通则Modem会收到相应的指令并向RILC传递接通信息。该信息由Modem主动上报，因此属于UnSolicited信息，由processUnsolicited()方法来处理。

总结

       RILJ的主要作用是将通话控制信息使用socket传递给RILC，RILC再使用AT指令传递给Modem端；RILC通过socket返回的Modem处理结果给RILJ并通知上层应用；可以说RILJ在Android Telephony结构中有着承上启下的作用。

RILJ的主要工作内容可以概括为以下三点：

1. 构造打包RILRequest；

2. RILSender通过socket向RILC发起request；

3. RILReceiver通过socket结构RILC反馈response；

RILReceiver接收到的消息分为两类：

1. Solicited Response，与之对应的处理方法是processSolicited()；

2. UnSolicited Response，与之对应的处理方法是processUnsolicited()；