文：GentlemanTsao
https://blog.csdn.net/GentelmanTsao

每篇一格言
纸上得来终觉浅，绝知此事要躬行
——陆游

前言

RSSI问题是移动终端常见的异常，例如信号格不刷新，或threshold不符合要求等。由于RSSI涉及较多module，所以分析的路径也比较长。
本篇先从framework部分入手。

RSSI上报的层次关系

先整体认识下RSSI上报的层次关系，如下图

RSSI上报流程依次为：
modem部分：L1物理层–>RRC–>CM–>QMI_NAS
AP和BP交互：QMI–>QCRIL
AP部分：RIL–>framework–>UI(application)
我们从framework开始分析

Framework部分RSSI上报路径

概况为下面的call flow：

不妨从左往右，用倒推的方式来分析上图的逻辑流程。

ANALYSIS 1：SimStatusDialogController

在android系统设置菜单的【关于手机】–>【SIM卡状态】菜单中，有【信号强度】一栏，显示当前网络下的RSSI，通常包括DBm和ASU值。其数据的刷新由SimStatusDialogController类负责。
该类监听PhoneStateListener.LISTEN_SIGNAL_STRENGTHS（如下code 1）并通过内部类复写PhoneStateListener的onSignalStrengthsChanged方法（如下code 2），得到SignalStrength对象，然后取出DBm和asu的值并刷新dialog。

code 1：

public void onResume() {
	if (mSubscriptionInfo == null) {
            return;
        }
        mTelephonyManager.createForSubscriptionId(mSubscriptionInfo.getSubscriptionId())
                .listen(mPhoneStateListener,
                PhoneStateListener.LISTEN_DATA_CONNECTION_STATE
                        | PhoneStateListener.LISTEN_SIGNAL_STRENGTHS  // 监听signalStrength
                        | PhoneStateListener.LISTEN_SERVICE_STATE);
                        。。。
  }

code 2：

PhoneStateListener getPhoneStateListener() {
	return new PhoneStateListener() {
	。。。
	//复写onSignalStrengthsChanged方法，获得signalStrength对象
	public void onSignalStrengthsChanged(SignalStrength signalStrength) { 
                updateSignalStrength(signalStrength);
            }
            。。。
 }

问题1.那得到SignalStrength有什么用呢？

ANALYSIS 2：SignalStrength

该类包含了所有信号相关的讯息：

上图中的所有讯息都可以通过SignalStrength的getxxx方法获取。

问题1答案：SignalStrength为application提供了RSSI的所有讯息。

于是就产生另一个疑问：

问题2：这些讯息是从哪里得到的呢?

ANALYSIS 3：PhoneStateListener

这是一个监听类，负责监听telephony特定状态的改变，例如service state，signal strength。
注意：监听某些telephony讯息需要在manifest中声明权限，例如READ_PHONE_STATE权限。

该类的使用方法是复写它的回调函数。对于signalStrength的监听，需要复写onSignalStrengthsChanged。
于是又一个疑问产生了：

问题3：onSignalStrengthsChanged在哪里回调？

ANALYSIS 4：TelephonyRegistry

这是一个集中处理telephony注册和回调的类。
该类设计了一个内部类Record，用于储存注册和回调讯息（如下）。

private static class Record {
	Context context;
	String callingPackage;
	IBinder binder;
	TelephonyRegistryDeathRecipient deathRecipient;
	
	//这里保存了一个PhoneStateListener对象
	IPhoneStateListener callback;  
	。。。
}

每注册一个监听事件，都生成一个对应的Record，这些record保存在一个arrayList中，名为mRecords。

看一下注册监听事件的实现（如下）：

private void listen(String callingPackage, IPhoneStateListener callback, int events,
            boolean notifyNow, int subId) {
            。。。
            synchronized (mRecords) {
            	IBinder b = callback.asBinder();
                Record r = add(b);
                r.context = mContext;
		//将callback，也就是上面提到的PhoneStateListener加到新的record中
                r.callback = callback;
                r.callingPackage = callingPackage;
                r.callerUid = Binder.getCallingUid();
                r.callerPid = Binder.getCallingPid();
                。。。
          }
          }

接下来，什么时候回调呢？

问题3的答案：notifySignalStrengthForPhoneId回调onSignalStrengthsChanged方法。

下面是notifySignalStrengthForPhoneId的实现，为了便于理解，以伪代码的形式给出（如下）。

public void notifySignalStrengthForPhoneId(int phoneId, int subId,
                SignalStrength signalStrength) {
                1. 遍历mRecords
                2. 匹配PhoneStateListener.LISTEN_SIGNAL_STRENGTHS
                3. 如果2满足则调用：r.callback.onSignalStrengthsChanged
                4. 发送广播ACTION_SIGNAL_STRENGTH_CHANGED
                }

ANALYSIS 5：DefaultPhoneNotifier

接下来，我们带着问题2，即signalStrength（也就是notifySignalStrengthForPhoneId传入的对象）是从哪里得到的，继续往右找到了DefaultPhoneNotifier的notifySignalStrength方法（如下）。

public void notifySignalStrength(Phone sender) {
    
	int phoneId = sender.getPhoneId();
        int subId = sender.getSubId();
        try {
    
            if (mRegistry != null) {
    
                mRegistry.notifySignalStrengthForPhoneId(phoneId, subId,
                        sender.getSignalStrength());
            }
        } catch (RemoteException ex) {
    
            // system process is dead
        }
    }

该方法传入的是一个phone的对象，并通过phone获得数据。
发现了重要线索，sender.getSignalStrength()得到的正是signalStrength对象。答案似乎不远了。

ANALYSIS 6：Phone

接上面，Phone调用DefaultPhoneNotifier的notifySignalStrength(Phone sender)，并传入自己（如下）。

public void notifySignalStrength() {
    
        mNotifier.notifySignalStrength(this);
    }

它还有getSignalStrength方法，获取的是ServiceStateTracker的SignalStrength（如下）

public SignalStrength getSignalStrength() {
    
        ServiceStateTracker sst = getServiceStateTracker();
        if (sst == null) {
    
            return new SignalStrength();
        } else {
    
            return sst.getSignalStrength();
        }
    }

ANALYSIS 7：ServiceStateTracker

历经关隘，我们遇到了第一个boss： ServiceStateTracker。
getSignalStrength（）方法返回了它的私有对象mSignalStrength。

public SignalStrength getSignalStrength() {
    
        return mSignalStrength;
    }

于是我们得到了问题2的答案。

问题2答案：SignalStrength讯息来自ServiceStateTracker的私有对象mSignalStrength。

紧接着又有了新的疑问：

问题4：mSignalStrength的数据如何得到的？

这需要从ServiceStateTracker的构造开始。

ANALYSIS 8：GsmCdmaPhone

GsmCdmaPhone是phone的一个子类（如下）。它还有一个公有对象ServiceStateTracker

public class GsmCdmaPhone extends Phone {
    
	public ServiceStateTracker mSST;
	
。。。
}

它的构造方法生成了ServiceStateTracker的实例（如下）：

public GsmCdmaPhone(Context context, CommandsInterface ci, PhoneNotifier notifier,
                        boolean unitTestMode, int phoneId, int precisePhoneType,
                        TelephonyComponentFactory telephonyComponentFactory) {
    
                        。。。
                        //构造方法生成ServiceStateTracker的实例。
                        mSST = mTelephonyComponentFactory.inject(ServiceStateTracker.class.getName())
                .makeServiceStateTracker(this, this.mCi);
                。。。
  }

这其中又用到了TelephonyComponentFactory。

ANALYSIS 9：TelephonyComponentFactory

该类造出一个ServiceStateTracker对象。（如下）

public ServiceStateTracker makeServiceStateTracker(GsmCdmaPhone phone, CommandsInterface ci) {
    
        Rlog.d(LOG_TAG, "makeServiceStateTracker");
        return new ServiceStateTracker(phone, ci);
    }

ANALYSIS 10：ServiceStateTracker之构造方法

接着看ServiceStateTracker的构造方法（如下）

public ServiceStateTracker(GsmCdmaPhone phone, CommandsInterface ci) {
    
        mNitzState = TelephonyComponentFactory.getInstance()
                .inject(NitzStateMachine.class.getName())
                .makeNitzStateMachine(phone);
                。。。
                //构造方法的最后call这个方法
                updatePhoneType();
}

看看updatePhoneType做了什么？

public void updatePhoneType() {
    
。。。
mCi.getSignalStrength(obtainMessage(EVENT_GET_SIGNAL_STRENGTH));
。。。
}

EVENT_GET_SIGNAL_STRENGTH是一个返回消息。
mCi是CommandsInterface的实例。需找到getSignalStrength的实现，才能知道做了什么。

ANALYSIS 11：CommandsInterface

这是一个接口类，提供了getSignalStrength 的声明。（如下）
这里的实现在RIL中。

void getSignalStrength (Message response);

ANALYSIS 12：RIL

public class RIL extends BaseCommands implements CommandsInterface {
    

RIL实现了getSignalStrength 方法，发送消息RIL_REQUEST_SIGNAL_STRENGTH（如下），对应的返回消息便是EVENT_GET_SIGNAL_STRENGTH。

public void getSignalStrength(Message result) {
    
	IRadio radioProxy = getRadioProxy(result);
	。。。
	RILRequest rr = obtainRequest(RIL_REQUEST_SIGNAL_STRENGTH, result,
                    mRILDefaultWorkSource);
        。。。            
        radioProxy.getSignalStrength(rr.mSerial);
}

ANALYSIS 13：ServiceStateTracker的消息返回处理

回到ServiceStateTracker，看下返回消息EVENT_GET_SIGNAL_STRENGTH的处理（如下）

case EVENT_GET_SIGNAL_STRENGTH:
	if (!(mCi.getRadioState() == TelephonyManager.RADIO_POWER_ON)) {
    
                    // Polling will continue when radio turns back on
                    return;
         }
	ar = (AsyncResult) msg.obj;
	//mark1.处理消息内容，发送给phone
        onSignalStrengthResult(ar);
        //mark2.延时一段时间再次获取signalStrength，反复这个过程从而使信号不断更新
        queueNextSignalStrengthPoll();
        。。。
}

mark1. 的实现如下：

protected boolean onSignalStrengthResult(AsyncResult ar) {
    
	。。。
	// 接收消息返回的SignalStrength
	mSignalStrength = (SignalStrength) ar.result;
	。。。
	// 更新SignalStrength
	mSignalStrength.updateLevel(config, mSS);
	。。
	// 发给phone通知SignalStrength状态改变
	boolean ssChanged = notifySignalStrength();
	。。。
}

这里得到了问题4的答案：

问题4答案：mSignalStrength是从RIL返回的消息EVENT_GET_SIGNAL_STRENGTH得到。

mark2.的实现如下：

private void queueNextSignalStrengthPoll() {
    
	。。。
	msg = obtainMessage();
        msg.what = EVENT_POLL_SIGNAL_STRENGTH;
        。。。
        //发送延时消息，再次获取signal
        sendMessageDelayed(msg, POLL_PERIOD_MILLIS);
}

ServiceStateTracker接收到EVENT_POLL_SIGNAL_STRENGTH后，又向RIL发送request请求SignalStrength（如下），如此，mSignalStrength的值便可以不断更新。

case EVENT_POLL_SIGNAL_STRENGTH:
	mCi.getSignalStrength(obtainMessage(EVENT_GET_SIGNAL_STRENGTH));
        break;

queueNextSignalStrengthPoll的停止与重启

Radio关闭时，Signal获取随之停止。当收到下面两个event时，重启poll过程：
EVENT_SIM_READY

case EVENT_SIM_READY:
                // Reset the mPreviousSubId so we treat a SIM power bounce
                // as a first boot.  See b/19194287
                mOnSubscriptionsChangedListener.mPreviousSubId.set(
                        SubscriptionManager.INVALID_SUBSCRIPTION_ID);
                mPrevSubId = SubscriptionManager.INVALID_SUBSCRIPTION_ID;
                mIsSimReady = true;
                pollState();
                // Signal strength polling stops when radio is off
                queueNextSignalStrengthPoll();
                break;

EVENT_RADIO_STATE_CHANGED
EVENT_PHONE_TYPE_SWITCHED

case EVENT_RADIO_STATE_CHANGED:
case EVENT_PHONE_TYPE_SWITCHED:
	if(!mPhone.isPhoneTypeGsm() &&
                        mCi.getRadioState() == TelephonyManager.RADIO_POWER_ON) {
    
                    handleCdmaSubscriptionSource(mCdmaSSM.getCdmaSubscriptionSource());
                    // Signal strength polling stops when radio is off.
                    queueNextSignalStrengthPoll();
                }
                。。。

总结

接下来我们继续分析RIL部分:
全面&详细解析android 10 RSSI信号格显示与刷新其二,RIL篇.

喜欢，别忘了点赞~