《深入理解Android：Wi-Fi，NFC和GPS》章节连载[节选]--第五章深入理解WifiService

最新推荐文章于 2021-10-26 20:18:04 发布

阿拉神农

最新推荐文章于 2021-10-26 20:18:04 发布

阅读量2w

点赞数 1

分类专栏： Android开发系列深入理解Android

本文链接：https://blog.csdn.net/innost/article/details/20863901

版权

Android开发系列同时被 2 个专栏收录

114 篇文章 163 订阅

订阅专栏

深入理解Android

81 篇文章 1108 订阅

订阅专栏

首先感谢各位兄弟姐妹们的耐心等待。本书预计在3月中旬上市发售。从今天开始，我将在博客中连载此书的一些内容。注意，此处连载的是未经出版社编辑的原始稿件，所以样子会有些非专业。

注意，如下是本章目录，本文节选5.4~5.5节。

为了方便读者深入学习，本系列连载都会将作者研究过

程中所学习的参考文献列出来

第5章深入理解WifiService

本章主要内容：

介绍Android Framework中的WifiService及相关知识；
介绍Android Framework中的WifiWatchdogStateMachine；
介绍Android Framework中和Captive Port Check相关知识

5.4 WifiWatchdogStateMachine和Captive Portal Check介绍

1 WifiWatchdogStateMachine介绍

WifiWatchdogStateMachine用于监控无线网络的信号质量，它在WifiService的checkAndStartWifi函数中被创建，其创建函数是makeWifiWatchdogStateMachine，代码如下所示：

[-->WifiWatchdogStateMachine.java::makeWifiWatchdogStateMachine]

public static WifiWatchdogStateMachine makeWifiWatchdogStateMachine(Context context) {

ContentResolver contentResolver = context.getContentResolver();

ConnectivityManager cm = (ConnectivityManager) context.getSystemService(

Context.CONNECTIVITY_SERVICE);

//判断手机是否只支持Wifi。很显然，对于大部分手机来说，sWifiOnly为false

sWifiOnly = (cm.isNetworkSupported(ConnectivityManager.TYPE_MOBILE) == false);

//WIFI_WATCHDOG_ON功能默认是打开的

putSettingsGlobalBoolean(contentResolver, Settings.Global.WIFI_WATCHDOG_ON, true);

//创建一个WifiWatchdogStateMachine对象，它也是一个HSM

WifiWatchdogStateMachine wwsm = new WifiWatchdogStateMachine(context);

wwsm.start();//启动HSM

return wwsm;

}

先来看WifiWatchdogStateMachine的初始化流程。

（1） WifiWatchdogStateMachine构造函数分析

[-->WifiWatchdogStateMachine.java::WifiWatchdogStateMachine]

private WifiWatchdogStateMachine(Context context) {

super(TAG);

mContext = context; mContentResolver = context.getContentResolver();

mWifiManager = (WifiManager) context.getSystemService(Context.WIFI_SERVICE);

//mWsmChannel用于和WifiStateMachine交互

mWsmChannel.connectSync(mContext, getHandler(),

mWifiManager.getWifiStateMachineMessenger());

//关键函数：setupNetworkReceiver将创建一个广播接收对象，用于接收NETWORK_STATE_CHANGED_ACTION、

// WIFI_STATE_CHANGED_ACTION、RSSI_CHANGED_ACTION、SUPPLICANT_STATE_CHANGED_ACTION等广播

setupNetworkReceiver();

//监控Wifi Watchdog设置的变化情况

registerForSettingsChanges();

registerForWatchdogToggle();

addState(mDefaultState);

......//添加状态，一共有9个状态。如图5-7所示

//Wifi Watchdog默认是开启的，故状态机转入NotConnectedState状态

if (isWatchdogEnabled()) setInitialState(mNotConnectedState);

else setInitialState(mWatchdogDisabledState);

updateSettings();

}

图5-7所示为WifiWatchdogStateMachine中的各个状态及层级关系：

图5-7 WifiWatchdogStateMachine状态及层级关系

上面代码中，WifiWatchdogStateMachine的初始状态是NotConnectedState。不过这个状态仅实现了enter函数，而且该函数中仅实现了一句打印输出的代码。所以NotConnectedState是一个象征意义远大于实际作用的类。

WifiWatchdogStateMachine完全靠广播事件来驱动。相关代码在setupNetworkReceiver函数中。

[-->WifiWatchdogStateMachine.java::setupNetworkReceiver]

private void setupNetworkReceiver() {

mBroadcastReceiver = new BroadcastReceiver() {

public void onReceive(Context context, Intent intent) {

String action = intent.getAction();

if (action.equals(WifiManager.RSSI_CHANGED_ACTION)) {

obtainMessage(EVENT_RSSI_CHANGE,

intent.getIntExtra(WifiManager.EXTRA_NEW_RSSI, -200), 0).sendToTarget();

} else if (action.equals(WifiManager.SUPPLICANT_STATE_CHANGED_ACTION)) {

sendMessage(EVENT_SUPPLICANT_STATE_CHANGE, intent);

} else if (action.equals(WifiManager.NETWORK_STATE_CHANGED_ACTION)) {

sendMessage(EVENT_NETWORK_STATE_CHANGE, intent);

} ......

else if (action.equals(WifiManager.WIFI_STATE_CHANGED_ACTION))

sendMessage(EVENT_WIFI_RADIO_STATE_CHANGE,intent.getIntExtra(

WifiManager.EXTRA_WIFI_STATE, WifiManager.WIFI_STATE_UNKNOWN));

}

};

mIntentFilter = new IntentFilter();

mIntentFilter.addAction(WifiManager.NETWORK_STATE_CHANGED_ACTION);

......//添加感兴趣的广播事件类型

mContext.registerReceiver(mBroadcastReceiver, mIntentFilter);

}

在前面介绍的WifiService工作流程中，SUPPLICANT_STATE_CHANGED_ACTION和NETWORK_STATE_CHANGED_ACTION广播发送的次数非常频繁。所以，WifiWatchdogStateMachine也不会太清闲。

下面，我们直接从WifiStateMachine在VerifyingLinkState的enter函数中发送的NETWORK_STATE_CHANGED_ACTION广播开始分析WifiWatchdogStateMachine的处理流程。

（2） EVENT_NETWORK_STATE_CHANGE处理流程分析

该消息被NotConnectedState的父状态WatchdogEnabledState处理，相关代码如下所示：

[-->WifiWatchdogStateMachine.java::WatchdogEnabledState:processMessage]

public boolean processMessage(Message msg) {

Intent intent;

switch (msg.what) {

......

case EVENT_NETWORK_STATE_CHANGE:

intent = (Intent) msg.obj;

NetworkInfo networkInfo = (NetworkInfo) intent.getParcelableExtra(

WifiManager.EXTRA_NETWORK_INFO);

mWifiInfo = (WifiInfo) intent.getParcelableExtra(WifiManager.EXTRA_WIFI_INFO);

//更新bssid信息

updateCurrentBssid(mWifiInfo != null ? mWifiInfo.getBSSID() : null);

switch (networkInfo.getDetailedState()) {

case VERIFYING_POOR_LINK://WifiStateMachine在VerifyingLinkState中设置的状态

mLinkProperties = (LinkProperties) intent.getParcelableExtra(

WifiManager.EXTRA_LINK_PROPERTIES);

//mPoorNetworkDetectionEnabled用于判断是否需要监控AP的信号质量

if (mPoorNetworkDetectionEnabled) {

if (mWifiInfo == null || mCurrentBssid == null) {

//下面这个函数将通过mWsmChannel向WifiStateMachine发送

//GOOD_LINK_DETECTED消息

sendLinkStatusNotification(true);

}

else transitionTo(mVerifyingLinkState);//进入VerifyingLinkState

} else sendLinkStatusNotification(true);

break;

case CONNECTED://WifiStateMachine在ConnectedState中设置的状态，请读者自行分析

//OnlineWatchState的处理流程

transitionTo(mOnlineWatchState);

}

.......

}

return HANDLED;

}

如果WifiWatchdogStateMachine开启了无线网络信号质量监控的话，它将转入VerifyingLinkState，其enter函数如下所示：

[-->WifiWatchdogStateMachine.java::VerifyingLinkState:enter]

public void enter() {

mSampleCount = 0;

mCurrentBssid.newLinkDetected();

//向自己发送CMD_RSSI_FETCH消息

sendMessage(obtainMessage(CMD_RSSI_FETCH, ++mRssiFetchToken, 0));

}

来看CMD_RSSI_FETCH消息的处理。

（3） CMD_RSSI_FETCH处理流程分析

[-->WifiWatchdogStateMachine.java::VerifyingLinkState:processMessage]

public boolean processMessage(Message msg) {

switch (msg.what) {

......

case CMD_RSSI_FETCH:

if (msg.arg1 == mRssiFetchToken) {

向WifiStateMachine发送RSSI_PKTCNT_FETCH消息，WifiStateMachine的处理过程

就是调用WifiNative的signalPoll和pktcntPoll以获取RSSI、LinkSpeed、发送

Packet的总个数、发送失败的Packet总个数。注意，4.2中的WPAS才支持pktcntPoll。

WifiStateMachine处理完RSSI_PKTCNT_FETCH后将回复RSSI_PKTCNT_FETCH_SUCCEEDED

消息给WifiWatchdogStateMachine

mWsmChannel.sendMessage(WifiManager.RSSI_PKTCNT_FETCH);

//LINK_SAMPLING_INTERVAL_MS值为1000ms

sendMessageDelayed(obtainMessage(CMD_RSSI_FETCH, ++mRssiFetchToken, 0),

LINK_SAMPLING_INTERVAL_MS);

}

break;

case WifiManager.RSSI_PKTCNT_FETCH_SUCCEEDED:

//WifiStateMachine回复的消息中携带一个RssiPacketCountInfo对象

RssiPacketCountInfo info = (RssiPacketCountInfo) msg.obj;

int rssi = info.rssi;

WifiWatchdog用了一个名为指数加权移动平均算法（Volume-weighted Exponential

Moving Average）的方法来辨别网络信号质量的好坏。本书不拟对它进行讨论，感兴趣的读者不妨

自行研究

long time = mCurrentBssid.mBssidAvoidTimeMax - SystemClock.elapsedRealtime();

//假设网络质量很好，则调用sendLinkStateNotification以发送GOOD_LINK_DETECT消息给

//WifiStateMachine

if (time <= 0) sendLinkStatusNotification(true);

else {

//此时的rssi好于某个阈值。mGoodLinkTargetRssi由算法计算得来

if (rssi >= mCurrentBssid.mGoodLinkTargetRssi) {

//当采样次数大于一定值时，才认为网络状态变好。mGoodLinkTargetCount也是通过

//相关方法计算得来

if (++mSampleCount >= mCurrentBssid.mGoodLinkTargetCount) {

mCurrentBssid.mBssidAvoidTimeMax = 0;

sendLinkStatusNotification(true);

}

} else mSampleCount = 0;

}

break;

......

}

return HANDLED;

}

当WifiWatchdogStateMachine检测到Pool link时，它将发送POOL_LINK_DETECT消息给WifiStateMachine去处理。相关流程请感兴趣的读者自行研究。

WifiWatchdogStateMachine是一个比较有趣的模块。其目的很简单，就是监测无线网络的信号质量，然后做相应动作。另外，WifiWatchdogStateMachine还使用了一些比较高级的算法来判断网络信号质量的好坏，感兴趣的读者不妨进行一番深入研究。

2. Captive Portal Check介绍

Android 4.2中，Captive Portal Check功能集中在CaptivePortalTracker类中，而且它也是一个HSM。CaptivePortalTracker的创建位于ConnectivityService构造函数中。在那里，它的makeCaptivePortalTracker函数被调用。相关代码如下所示：

[-->CaptivePortalTracker.java::makeCaptivePortalTracker]

public static CaptivePortalTracker makeCaptivePortalTracker(Context context,

IConnectivityManager cs) {

CaptivePortalTracker captivePortal = new CaptivePortalTracker(context, cs);

captivePortal.start();//启动HSM

return captivePortal;

}

马上来看CaptivePortalTracker的构造函数

（1） CaptivePortalTracker构造函数分析

[-->CaptivePortalTracker.java::CaptivePortalTracker]

private CaptivePortalTracker(Context context, IConnectivityManager cs) {

super(TAG);

mContext = context;mConnService = cs;

mTelephonyManager = (TelephonyManager) context.getSystemService(

Context.TELEPHONY_SERVICE);

//注册一个广播接收对象，用于处理CONNECTIVITY_ACTION消息

IntentFilter filter = new IntentFilter();

filter.addAction(ConnectivityManager.CONNECTIVITY_ACTION);

mContext.registerReceiver(mReceiver, filter);

//CAPTIVE_PORTAL_SERVER用于设置进行Captive Portal Check测试的服务器地址

mServer = Settings.Global.getString(mContext.getContentResolver(),

Settings.Global.CAPTIVE_PORTAL_SERVER);

//如果没有指明服务器地址的，则采用DEFAULT_SERVER，其地址是“clients3.google.com”

if (mServer == null) mServer = DEFAULT_SERVER;

//是否开启Captive Portal Check功能，默认是开始

mIsCaptivePortalCheckEnabled = Settings.Global.getInt(mContext.getContentResolver(),

Settings.Global.CAPTIVE_PORTAL_DETECTION_ENABLED, 1) == 1;

addState(mDefaultState);//CaptivePortalTracker只有4个状态

addState(mNoActiveNetworkState, mDefaultState);

addState(mActiveNetworkState, mDefaultState);

addState(mDelayedCaptiveCheckState, mActiveNetworkState);

setInitialState(mNoActiveNetworkState);

}

CaptivePortalTracker只监听CONNECTIVITY_ACTION广播，而WifiService相关模块并不会发送这个广播。那么，在前面介绍的流程中，哪一步会触发CaptivePortalTracker进行工作呢？来看下节。

（2） CMD_CONNECTIVITY_CHANGE处理流程分析

当Wifi网络连接成功时，ConnectivityService的handleConnect将被触发，该函数内部将发送一个CONNECTIVITY_ACTION消息。这个消息将被CaptivePortalTracker注册的广播接收对象处理。相关代码如下所示：

[-->CaptivePortalTracker.java::onReceive]

private final BroadcastReceiver mReceiver = new BroadcastReceiver() {

public void onReceive(Context context, Intent intent) {

String action = intent.getAction();

if (action.equals(ConnectivityManager.CONNECTIVITY_ACTION)) {

NetworkInfo info = intent.getParcelableExtra(

ConnectivityManager.EXTRA_NETWORK_INFO);

//向状态机发送CMD_CONNECTIVITY_CHANGE消息

sendMessage(obtainMessage(CMD_CONNECTIVITY_CHANGE, info));

}

};

CaptivePortalTracker的NoActiveNetworkState将处理该消息。相关代码如下所示：

[-->CaptivePortalTracker.java::NoActiveNetworkState:processMessage]

public boolean processMessage(Message message) {

InetAddress server; NetworkInfo info;

switch (message.what) {

case CMD_CONNECTIVITY_CHANGE:

info = (NetworkInfo) message.obj;

//无线网络已经连接成功，并且手机当前使用的就是Wifi。isActiveNetwork将查询

//ConnectivityService以获取当前活跃的数据链接类型

if (info.isConnected() && isActiveNetwork(info)) {

mNetworkInfo = info;

transitionTo(mDelayedCaptiveCheckState);//转移到DelayedCaptiveCheckState

}

......

}

return HANDLED;

}

来看DelayedCaptiveCheckState。

（3） CMD_DELAYED_CAPTIVE_CHECK处理流程分析

代码如下所示：

[-->CaptivePortalTracker.java::DelayedCaptiveCheckState]

private class DelayedCaptiveCheckState extends State {

public void enter() {

//发送一个延迟消息，延迟时间为10秒

sendMessageDelayed(obtainMessage(CMD_DELAYED_CAPTIVE_CHECK,

++mDelayedCheckToken, 0), DELAYED_CHECK_INTERVAL_MS);

}

public boolean processMessage(Message message) {

switch (message.what) {

case CMD_DELAYED_CAPTIVE_CHECK:

if (message.arg1 == mDelayedCheckToken) {

InetAddress server = lookupHost(mServer);//获取Server的ip地址

if (server != null) {

//AP是否需要Captive Portal Check。如果是的话，setNotificiationVisible

//将在状态栏中添加一个提醒信息

if (isCaptivePortal(server)) setNotificationVisible(true);

}

transitionTo(mActiveNetworkState);//转到ActiveNetworkState

}

break;

default:

return NOT_HANDLED;

}

return HANDLED;

}

上述代码中，isCaptivePortal用于判断server是否需要Captive Portal Check。其代码如下所示：

[-->CaptivePortalTracker.java::isCaptivePortal]

private boolean isCaptivePortal(InetAddress server) {

HttpURLConnection urlConnection = null;

if (!mIsCaptivePortalCheckEnabled) return false;

//mUrl实际访问的地址是：http://clients3.google.com/generate_204

mUrl = "http://" + server.getHostAddress() + "/generate_204";

Captive Portal的测试非常简单，就是向mUrl发送一个HTTP GET请求。如果无线网络提供商没有设置Portal

Check，则HTTP GET请求将返回204。204表示请求处理成功，但没有数据返回。如果无线网络提供商设置了

Portal Check，则它一定会重定向到某个特定网页。这样，HTTP GET的返回值就不是204

try {

URL url = new URL(mUrl);

urlConnection = (HttpURLConnection) url.openConnection();

urlConnection.setInstanceFollowRedirects(false);

urlConnection.setConnectTimeout(SOCKET_TIMEOUT_MS);

urlConnection.setReadTimeout(SOCKET_TIMEOUT_MS);

urlConnection.setUseCaches(false);

urlConnection.getInputStream();

return urlConnection.getResponseCode() != 204;

}......

}

处理完毕后，CaptivePortalTracker将转入ActiveNetworkState状态。该状态的内容非常简单，读者可自行阅读它。由于笔者家中所在小区宽带提供商使用了Capive Portal Check，所以笔者利用AirPcap截获了相关网络交换数据，如图5-8所示：

图5-8 Captive Portal Check示意图

测试时，笔者禁用了无线网络安全，所以AirPcap可以解析这些没有加密的数据包。由图5-8可知，当笔者的Note 2发起HTTP GET请求后，小区宽带服务器回复了HTTP 302，所以笔者手机状态栏才会显然如图5-9所示的提示项以提醒笔者该无线网络需要登录。

图5-9 Captive Portal Check提示示意图

（4） CaptivePortalTracker总结和讨论

和WifiWatchdogStateMachine一样，CaptivePortalTracker也比较有意思。CaptivePortalTracker类出现于4.2中。而4.1中的Captive Portacl Check功能则是由WifiWatchdogStateMachin来完成的。在4.1中，WifiWatchdogStateMachine定义了一个名为WalledGardenCheckState的类用于处理Captive Portal Check。

不过，笔者在研究4.1和4.2相关模块的代码后，发现4.2中的处理似乎有一些问题。此处先记下此问题，希望有兴趣的读者参与讨论。该问题如下：

4.2中，WifiStateMachine在ConnectedState前增加了一个CaptivePortalCheckState。很明显，CaptivePortalCheckState的目的是在WifiStateMachine转入ConnectedState之前完成Captive Portal Check。但根据本节对CaptivePortalTracker的介绍，只有WifiStateMachine进入ConnectedState后，ConnectivityService才会发送CONNECTIVITY_ACTION广播。而在4.1中，WifiWatchdogStateMachine也是在WifiStateMachine转入ConnectedState后进入WalledGardenCheckState的。

提示：那么，WifiStateMachine如何从CaptivePortalCheckState转为ConnectedState呢？答案在ConnectivityService的handleCaptivePortalTrackerCheck函数中。在那里，WifiStateMachine的captivePortalCheckComplete函数最终会被调用。在那个函数中，CMD_CAPTIVE_CHECK_COMPLETE将被发送，故CaptivePortalCheckState才会转入ConnectedState状态。但是，在这个流程中，CaptivePortalTracker并未被真正触发以进行Captive Portal Check。

5.5 本章总结和参考资料说明

5.5.1 本章总结

本章对WifiService相关模块、WifiWatchdogStateMachine以及CaptivePortalTracker进行了一番介绍。其中：

HSM和AsyncChannel是本章的重要基础知识。希望读者认真学习它们的用法。
WifiService中的WifiStateMachine是本章的核心。其定义的状态之多、处理之曲折在Android系统中算是非常突出的。如果条件允许的话，读者不妨通过Eclipse来调试它以加深认识。
WifiWatchdogStateMacine和CaptivePortalTracker内容比较简单，但其功能却比较有意思。对于这部分内容，读者做简单了解即可。

笔者一直觉得WifiService的实现过于复杂，而且其运行效率较低。不知道读者看完本章后是否有同感。

5.5.2 参考资料说明

Captive Portal Check

[1] https://en.wikipedia.org/wiki/Captive_portal

维基百科对Captive Portal的介绍。读者仅作简单了解即可。

阿拉神农

关注

1
点赞
踩
20

收藏

觉得还不错? 一键收藏
1
评论
《深入理解Android：Wi-Fi，NFC和GPS》章节连载[节选]--第五章深入理解WifiService

首先感谢各位兄弟姐妹们的耐心等待。本书预计在3月中旬上市发售。从今天开始，我将在博客中连载此书的一些内容。注意，此处连载的是未经出版社编辑的原始稿件，所以样子会有些非专业。注意，如下是本章目录，本文节选3.1-3.3.4 3.4~3.4.2 及3.5节。为了方便读者深入学习，本系列连载都会将作者研究过程中所学习的参考文献列出来
复制链接

扫一扫