5.5 Captive Portal Check介绍
最后更新于：2022-04-02 06:03:57
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的。
* * * * *
>[info] 提示：那么，WifiStateMachine如何从CaptivePortalCheckState转为ConnectedState呢？
>
> 答案在ConnectivityService的handleCaptivePortalTrackerCheck函数中。在那里，WifiStateMachine的captivePortalCheckComplete函数最终会被调用。在那个函数中，CMD_CAPTIVE_CHECK_COMPLETE将被发送，故CaptivePortalCheckState才会转入ConnectedState状态。但是，在这个流程中，CaptivePortalTracker并未被真正触发以进行Captive Portal Check。
';